Cisco PIX and CipherTrust Ironmail...

[jpeter]

I usually try to avoid vendor issues but I wanted to run this by the forum to see if by chance anyone has run into this...

We have a PIX 515 with 6.3(5), and are using a CipherTrust IM Mail Filtering Appliance. For whatever reason, outbound connections from the IM will fail after a certain period of time.

Now in case you're thinking the obvious (ACLs, equipment) I've already addressed it, swapping out the switch, network cable, allowing full IP to and from the IM. Still for whatever reason, outbound connections are dropped. I traced packets and the SYN packet is sent, but that's it. No response. No indication of a Denied ACL. The end result is a SYN timeout. Now when I resart the PIX, it will work fine for a few hours and then connections from the IM to the internet will be dropped again.

Odd. Any help would be greatly appreciated.

[thomas.chen]

By sending a TCP SYN packet with an incorrect checksum through a PIX firewall, the PIX will block new TCP connections using the same source and destination TCP ports and IP addresses. Connections will remain blocked for approximately two minutes after which connections will be allowed. This behavior may be seen on all firewall interfaces but can be expected to have the most impact on TCP connections originating from higher security level interfaces to lower security level interfaces.

Since the spoofed packets have an incorrect checksum, they are silently discarded by the destination and the firewall will not see a RST packet from either the destination or the legitimate source and will hold the embryonic connection open until the embryonic connection timeout which is 2 minutes by default.

The root cause is due to the spoofed packet creating an embryonic connection which sets up the TCP sliding window. A valid packet from a real host using the same connection as the spoofed packet sends a SYN over the same connection. The sequence number of the valid packet is out-of-window and rejected by the firewall's TCP sequence number check. Any subsequent retransmissions of the valid packet are also out-of-window and are rejected by TCP sequence number check.

Other spoofed TCP SYN packets that create embryonic connections can also cause this behavior, blocking legitimate TCP connections until the embryonic connection times out