Hi folks,

 I just finished a self-made lab with ASA HTTP inspection . The only doubts
that  I   got are concerned with policy-map actions in HTTP inspection. For
example, i made a policy where all Internet Explorer HTTP connections were
dropped, and it works fine. At ASA logging level I saw the next output:

ASA-5-415008: HTTP - matched Class 22: BIN in policy-map BIN, header matched
- Dropping connection from INSIDE:1.1.1.2/54826 to WEBSERVER: 4.2.2.2/80
%ASA-4-507003: tcp flow from INSIDE:1.1.1.2/54826 to
WEBSERVER:4.2.2.2/80terminated by inspection engine,
*reason - disconnected, dropped packet.*

  At wireshark level I saw the TCP handshake, the HTTP request and the TCP
reset.

 Then, i change the action to reset and i got  these:

 %ASA-5-415008: HTTP - matched Class 22: BIN in policy-map BIN, header
matched - Resetting connection from INSIDE:1.1.1.2/54827 to WEBSERVER:
4.2.2.2/80
  %ASA-4-507003: tcp flow from INSIDE:1.1.1.2/54827 to
WEBSERVER:4.2.2.2/80terminated by inspection engine,
* reason - reset unconditionally*

  At wireshark level, same as before... The rest of the logs in ASA, the
same too


About the actions in HTTP Inspection in cisco.com:

The *drop-connection* keyword drops the packet and closes the connection.

The *reset* keyword drops the packet, closes the connection, *and sends a
TCP reset to the server and/or client. *


  In both cases i see the same behavior at host level, including the reset
at the end of the TCP trasmision. Is there a real difference between both
actions? The same applies with IPS reset connection and drop connection
inline action, but with the sensor i saw some TCP retransmisions before the
reset was send, working  with drop connection line.


Regards.
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to