I have a wierd issue that I've found the workaround to, but I'm not sure I like it. I was having problems doing large file transfers over a l2l VPN between two PIX 515e's.
After way too much troubleshooting, I noticed that the "TCP packet failed PAWS test" was incrementing fast when doing a file transfer. On my linux box, I did an 'echo 0 > /proc/sys/net/ipv4/tcp_timestamps' and the problem went away - I could transfer files no problem. Just to ensure this was the issue, I turned back on tcp_timestamps in the linux kernel, then I created a tcp-map that cleared the timestamp field. This works as well.
Does anyone know why my PIX is dropping packets with the timestamp field set? I'm running PIX 7.0(6.4). I've verified this issue on PIX 7.0(1), 7.0(4), and 7.0(6.4).
PAWS is an algorithm that protects again wrapped sequence numbers. What *can* happen is that in the course of a connection, a segment could be lost and then retransmitted - but when it retransmitsthat segment, the sequence number window is being re-used because the sequence number has wrapped due to the large amount of data being sent. You could then get data corruption
Basically the pix was doing it's job, dropping the old segments coming in with sequence numbers that were in the current window but whose timestamp was less than what it was supposed to be.
From the RFC (so you don't have to read the entire thingg) :
"An especially serious kind of error may result from an accidental
reuse of TCP sequence numbers in data segments. Suppose that an
"old duplicate segment", e.g., a duplicate data segment that was
delayed in Internet queues, is delivered to the receiver at the
wrong moment, so that its sequence numbers falls somewhere within
the current window. There would be no checksum failure to warn of
the error, and the result could be an undetected corruption of the
data. Reception of an old duplicate ACK segment at the
transmitter could be only slightly less serious: it is likely to lock up the connection so that no further progress can be made,forcing an RST on the connection."
An interesting test might be to take linux out of the equation - try transfering from windows machines without the tcp-map on and see if you still see the issue. My guess is that linux install is interpreting how to implement the RFC differently than how the pix is enforcing it - hence the issue.
Please rate this message if it helped resolve some or all of your issue.
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...