TCP sequence number

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?

If this happens after the SSL connection has been negotiated, it is possible that the intermediate device considers encrypted traffic on port 2000 as a potential security threat (or in some way "unwanted") and makes two things:

• intercepts the "ACK" sent by the server so they do not reach the client that will consider the server as not responding
• sends a reset to the server so that it will not keep the connection open waiting for traffic that will never come from the client