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/

  • Neither of those URIs work.
    – Jenny D
    Sep 9 '15 at 10:54
  • Do you have a network map? What kind of systems are between the two?
    – pehrs
    Sep 9 '15 at 10:57
  • @JennyD, the webserver can be access by other devices.
    – Xegara
    Sep 9 '15 at 11:23
  • @pehrs, both systems are behind NAT. The web server is properly port forwarded.
    – Xegara
    Sep 9 '15 at 11:24

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.

  • Just want to rule the possibility: is it possible that the ISP rewrites the packets?
    – Xegara
    Sep 9 '15 at 13:06
  • @Xegara Possible, yes. Likely, no.
    – sysadmin1138
    Sep 9 '15 at 14:26
  • Is there a way to diagnose and solve the problem?
    – Xegara
    Sep 9 '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 9 '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 5:01

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.

  • Is it possible that the TCP/IP stack or winsock is corrupted and needs to be reset?
    – Xegara
    Sep 9 '15 at 11:27
  • Both firewalls in the client and server PCs are switched off.
    – Xegara
    Sep 9 '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 9 '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 9 '15 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.