1

The client cannot connect to our web server. I sniffed the client and web server only to found out that the client sees the TCP connection to be successful while the server see it as a failure. What are the probable cause for this problem? Did the ACK packet sent by the client to the server corrupted as it goes through the network.

The screenshot for both are displayed in the link below.

Client enter image description here

Server http://postimg.org/image/c089q8hrt/

HBruijn
  • 77,029
  • 24
  • 135
  • 201
Xegara
  • 123
  • 2

2 Answers2

3

You definitely have something between these two devices that is rewriting packets. The client opens a connection to TCP/80 from its own TCP/58055 port. The server sees the SYN packet coming from TCP/5822. That can only happen if some network device is rewriting packets, such as a NAT device or some firewalls.

This is further supported by the presence of "SACK_PERM=1" present in the client's view of things. That is selective-acknowledgments, and is a TCP Option. The SYN packet seen by the server has had that stripped off somewhere. This is a classic firewall setting, as SACKs were seen as insecure or able to be DDoSed.

You have a device somewhere between these two that is getting in the way. You can't fix this at the end-points.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • Just want to rule the possibility: is it possible that the ISP rewrites the packets? – Xegara Sep 09 '15 at 13:06
  • @Xegara Possible, yes. Likely, no. – sysadmin1138 Sep 09 '15 at 14:26
  • Is there a way to diagnose and solve the problem? – Xegara Sep 09 '15 at 15:45
  • @Xegara I believe pehrs requested a network map because that's where your problem will be found. Once you know how packets flow through your network, your list of places to troubleshoot will narrow. Once you know what devices are in between, specific steps can be taken to further isolate where the problem actually is. Pehrs mentioned NAT gateways as a possible problem, I've seen similar problems with hardware load-balancers. – sysadmin1138 Sep 09 '15 at 17:06
  • Is it possible to bypass any potential rewriting of packets using networking technology like SSL, VPN, HTTPS? – Xegara Sep 10 '15 at 05:01
  • @Xegara The rewriting I'm seeing, redoing of port-numbers and modification of TCP option headers, happens during the TCP connection negotiation. A higher level protocol like SSL would be subjected to it too. That said, that would take place over different ports so the firewall rules may behave differently. – sysadmin1138 Sep 10 '15 at 11:57
0

My first guess would be a statefull firewall somewhere between the two systems which is misbehaving. It could also be a local firewall. Note that none of the ACK packets seem to get through.

pehrs
  • 8,789
  • 1
  • 30
  • 46
  • Is it possible that the TCP/IP stack or winsock is corrupted and needs to be reset? – Xegara Sep 09 '15 at 11:27
  • Both firewalls in the client and server PCs are switched off. – Xegara Sep 09 '15 at 11:36
  • Unlikely. It is much more likely that the NAT systems are the culprit. Multiple layers of NAT is a common source of headaches. – pehrs Sep 09 '15 at 11:36
  • What can you suggest on what steps should I take to troubleshoot this problem? Because, I am already literally out of networking ideas. Haha. – Xegara Sep 09 '15 at 12:39