ACK advances while SEQ does not

asked 2022-07-05 17:58:20 +0000

OpenVPN Tunnel traffic over TCP.

Typical two way traffic, Client data sent, Server ACK received followed by Server PSH, ACK, and vise versa. Window size is ~64000 bytes, so plenty of buffer. Sequence and ACK numbers adjust accordingly with network traffic during normal operation. There is never any indication of any delayed traffic in the time stamps.

Random failure case:

Client sends data. Server ACKs with new sequence number, but no Server PSH,ACK record after Server ACK record.

From this point on, there are 18 to 20 sets of Client/Server pairs where the server ACK number is increased by the segment length, but the sequence number is never updated/changed. The client continues to send data and the server continues to ACK until the server issues a RST and the tunnel is closed.

It looks to me like the Server has detected that the sequence number is not changing, and kills the connection.

I'm looking for insights into how this situation could arise, and what to look for.



edit retag flag offensive close merge delete


That's a lot of words. Can you sanitize a pcap, share it somewhere and update the question with a link to it?

Chuckc gravatar imageChuckc ( 2022-07-05 20:17:40 +0000 )edit

Good plan! Hope this works.

Wireshark window

doug80638 gravatar imagedoug80638 ( 2022-07-05 21:12:40 +0000 )edit