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 |
2 Answers:
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 ♦♦ |
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 |
