Working with various PIX devices but mostly 525s running 6.3.5 IOS and using static translates from outside to inside interface.
1. When a perfectly good Syn packet arrives from a remote machine, the PIX passes the Syn packet to the inside interface and target device.
2. The target device responds with a Syn,ACk packet on the inside interface.
3. The PIX passes the Syn Ack packet to the outside interface and the Internet at large.
4. Device that made the initial connection does not receive the Syn Ack packet (for whatever reason, dropped in the path).
5. Initiating Device sends a 2nd Syn packet using the same ip/port combination.
6. PIX receives 2nd Syn packet, does not respond to it and does not pass it into the internal inteface.
7. Initiating device sends 3rd Syn packet.
8. PIX does same thing, does not respond and does not pass along.
This is not a DOS attack, it appears to be the way the TCP/IP handshake deals with packet loss prior to the actual connection establishment and the sequence counters used to track actual data.
Other sites behind non PIX firewalls respond to all 3 syn packets in an attempt to establish a connection. Cisco routers will also respond to all 3 attempts.
We have tried floodguard, embryonic connection counters, to no success.
Interesting that once you see this seqeunce, the PIX will respond to a new connection request and if the Syn packet is repeated, the PIX will respond to the 2nd and 3rd Syns with a Syn Ack where the Windowsize = 0. This is Intercept mode, not sure how the initiating device would respond but with a window of 0, expect it to shut up.
This is similar to a known DOS attack that requres a malformed Syn packet to trigger the issue of not responding to subsequent Syn Packets. The difference is, the initial syn packet is normal in all respects, the answer was just lost in transit and the retry is being ignored.
Any ideas on how we can get the PIX to respond to the 2nd or 3rd syn or at least pass them inside to allow the host to respond? A less than perfect network causes intermittent errors.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...