Some signatures from our IPS are tuned to send a TCP Reset when triggered. When this happens, the PIX denies each and every one of the 200 TCP Reset packets (per instance) from the IPS device (reference error %PIX-6-106015 in syslog). Apparently, the PIX sees all of these resets as a "hijacked" session (rightfully so) and discards them. As this occurs, it seems the original traffic that the IPS intended to dissuade (by the use of the TCP Reset) still makes it to rest of the network/intended target. Any ideas on how to tell the PIX to allow these IPS TCP Resets to take place?
I read thru the post a couple times and have a few questions...
Where is the ips in relation to the attacker and the victim and the pix (inside/outside interface).
The pix-6-106015 syslog messages just tell me that the packet was dropped because there isn't a connection that exists in the pix's connection table that that relates too. Makes me think that maybe the connection was already reset/removed from the pix for some reason.
And even then, if the connection was reset, the traffic may still have made it to the host since the issuing of tcp-resets is a reaction to an alert (and are considered best effort). The sensor saw the traffic, and then the RSTs were issued... which pretty much means that some of the traffic would have made it to the end host anyway.
Now if the sensor is running in inline mode, the packet would be dropped and never make it to the end host.
Outside interface, in promiscuous mode. My thinking is that since the IPS literally hijacks the session, imitates the attacker, and sends the 100 resets onward to the intended target (via the PIX), the PIX detects that a connection doesn't exist, because there isn't one. I'm not educated on the exact mechanics of these TCP Resets issued by the IPS in these cases, but it seems that they aren't fooling the PIX.
Having the same issue here with a web filtering product that issues TCP resets to traffic to disallowed web sites. The setup involves a three-armed firewall, with the client on one arm, the web filter on another, and the Internet on the third. I see %PIX-6-106015 errors that are stemming from the web filter when I'm testing sites that aren't allowed. I understand that the PIX is doing what it's supposed to, but is there any way to explicitly permit TCP Resets in this case?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...