Sequence number different on both sides of conversation 2

[pvande01]

I am trying to troubleshoot a dropping network connection between 2 Windows servers on different sides of a WAN connection.
I took wireshark traces on both ends of the conversation and then reproduced the problem.
I'm analyzing the wireshark output, and see different sequence and acknowledge numbers for the same packet on the different servers. I'm wondering if this is always the case, or if not, what could be the cause.

Here's what I did:
* I found a corresponding packet in both wireshark traces.
* I disabled "relative sequence numbers" in both wireshark traces.

On one end the TCP SEQ and ACK numbers are as follows:
SEQ: 2207178090
ACK: 2972727704

On the other end, when I look at the same (corresponding) packet I see:
SEQ: 823723793
ACK: 3848818219

Again, my question is: when you takes traces on both ends of a conversation, will you always see different SEQ/ACK numbers when you're looking at the same packet on both ends. If you're not always supposed to see this, what could be some of the reasons why this would happen in our case.

 

[kr9]

pvande01

Both sides of the TCP connection track the "reliability" using the sequence numbers. These must remain the same so that sender knows which segments the receiver has received correctly.
There is nothing that modifies sequence numbers after they are sent unless , of course there is some sort of Proxy in the path? Are the src/dest IP addresses the same at both ends of the connection? What makes you believe that you have captured the packet that was transmitted and received?

Cheers
Ken

 

[pvande01]

kr9,

Thanks for your reply.
The source and destination addresses are indeed the same in the WireShark traces on both ends.
I ran a continuous ping between both sides during the test and based on the location of the ping packets I was able to match the other packets between both wireshark traces. Anyway, the SEQ/ACK numbers in the once trace don't appear at all in the other trace, so even if I'm off a few packets, the SEQ and ACK numbers don't appear to be the same in both traces.

The customer I'm troubleshooting this for swares there is only a router and some switches in the path. Nothing else. No firewalls, no proxies.

I was also of the understanding that SEQ and ACK are supposed to be the same on both ends unless something is in the path but wanted to get the opinion of some real experts.

Am I still missing something?

If there really is something in the path, I suspect it is responsible for "forcibly closing" (winsock error 10054) the connection after about 2 hours.

 

[pvande01]

One extra remark. The WAN link is actually a VPN connection. Could that explain things?

It was my understanding a VPN would just encapsulate the TCP/IP packets - or could it modify SEQ/ACK numbers?

 

[dcss00]

I did a quick read through and did not see mention of TCP port numbers, the same IP source/destination addresses are good but it is also about the TCP port numbers.

Do the packets have the same TCP port numbers on both sides?

If so then something in the middle is possibly changing or creating a new TCP session.

 

[pvande01]

dcss00, yes the port numbers are the same on both sides of the conversation as well.

Someone else suggested TCP Offload may be to blame. I can't check right now, but believe at least one end of the conversation may have TOE enabled.

Anyone else's thoughts on TOE as a possible cause of what we see in WireShark?

 

[pvande01]

After finding the wireshark evidence and backed by your comments, the customer now confirms there is a firewall in the path after all.
Moral of the story - never trust someone's word when troubleshooting.

Just for further reference, the answer is yes: seq/ack numbers should match on both ends of the conversation. If not, the only other explanation is firewalls, proxies or something similar along the path.