This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

HTTP POST command not received and MSS value changed in transit

0

Hello,

I am debugging a connection reset issue with the following symptoms. The network admins say all firewalls and routers are wide-open between the IP's, no blocking of any sort. I'm running tcpdump on two systems while they attempt to communicate with each other and using wireshark to look at the traces.

Setup:

SYS1: Private IP NAT'd to public IP, one-to one. SYS2: Public IP. Idea is SYS1 will communicate with SYS2 over the internet. Here is the problem.

SYS1 sends ping, SYS2 replies

SYS1 sends SYN, SYS2 sees SYN, replies with SYN, ACK

SYS1 sees ACK, replies with ACK which SYS2 sees.

SYS1 sends HTTP POST command and SYS2 never sees it, it is not in the SYS2 trace.

Both systems then log a RST from the other: Acknowledgement number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set

The only odd thing I see in the traces is that both systems send an MSS of 1460 with the SYN frame and both receive an MSS of 1380 when they get those SYN frames, so something in the path is changing that. I don't think that should cause the problem above but it does point to some sort of frame manipulation going on somewhere. I am trying to utilize other setups to eliminate parts of the picture but if this sounds familiar to anyone I'd be interested in your thoughts.

Thanks

asked 01 Apr '11, 16:49

jgg's gravatar image

jgg
1111
accept rate: 0%


2 Answers:

1

The TCP MSS value stands for Maximum Segment Size, the maximum amount of TCP payload accepted in each TCP segment (and thus packet). The TCP MSS value is changed by intermediate devices when they know there will be some tunneling (IPsec, MPLS, PPPoE, etc) that will add a header to each packet. That way, they prevent IP fragmentation when full-sizes frames are sent later on.

Some devices do even change the MSS any way, just to be sure. I know the Cisco FWSM (firewall module in a 65XX) changes the MSS to 1380 by default.

That said, this is not a problem if both systems adhere to the lower MSS value. It would be useful to know the size of the HTTP POST packet, including the sizes of the IP header, the TCP header and the TCP length.

If both systems see a TCP RST from the other, without them sending them to each other, this means there is some device in between that is causing them. The most logical conclusion would be that there is some device having IDP (Intrusion Detection and Prevention) functionality, maybe the FW, maybe a separate device, that is not liking the HTTP POST and is rejecting it with the TCP RST packets.

answered 01 Apr '11, 23:17

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

0

Check to see IP ID's are the same. It's possible that only TCP's MSS is being adjusted (Cisco routers, for example can do this). Also, I think you meant "SYS1 sees SYN+ACK and replies with ACK" You didn't mention what your packet size was for the HTTP POST. Is it 1380? You can also use ping packets with "do not fragment" bits set (-f for Windows, or using advanced options for cisco routers). If using windows, don't forget that Windows doesn't account for 8 byte ICMP header. So "ping -f 1472..." will really send 1480 byte IP packets.

answered 01 Apr '11, 17:17

hansangb's gravatar image

hansangb
7912619
accept rate: 12%