Various workstations behind the client side Network Address Translation (NAT) firewall are sending timestamp information on the TCP packet to our server. The packets from many workstations arrive with out-of-sequence time-stamps from behind the NAT device. When they arrive at our server – in some cases on the same port – the server cannot differentiate these packets from others arriving on the same port and from the same client IP (the NAT device).
The server interprets the packets with out of sequence time-stamps as belonging to a connection that has already been completed, and the packet is then ignored – but in this case it should not be. Theses are legitimate packets from workstations behind the NAT device. Dropping packets with old time stamp values is a by-design feature of TCP called PAWS (http://www.ietf.org/rfc/rfc1323.txt, Protect Against Wrapped Sequences) – the server simply assumes the packet is old and it has already dealt with the connection.
To work around for this we disabled the timestamp settings on our servers. BUT – what is the best practice for this situation? Should all servers have timestamp support disabled? Or should all NAT devices remove or rewrite timestamp values? Or?
Best Answer
The source port is an additional identifying feature to the TCP connection, and no two connections behind the NAT device should be assigned the same source port - clients will never interfere with each other's connections unless they get given the same source port by a bad NAT device.
PAWS shouldn't be discarding needed packets, just duplicates from resending - out of order delivery doesn't update the timestamp floor. The time value is copied from the last in-sequence segment; a packet with a higher sequence number (ie, one that is needed) should always have a higher timestamp than one with a lower sequence number.
If it's in proper sequence but has a lower timestamp, then it's the TCP client misbehaving - and if by some oddity PAWS is throwing away good, in-sequence packets, then the client should be re-sending with a new timestamp, recovering from any issues that were caused by the discard.
What behavior are you seeing that's led you to this issue?