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/

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

2 Answers 2

Reset to default
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.

Improve this answer
6
  • Just want to rule the possibility: is it possible that the ISP rewrites the packets?
    – Xegara
    Sep 9, 2015 at 13:06
  • @Xegara Possible, yes. Likely, no.
    – sysadmin1138 ♦
    Sep 9, 2015 at 14:26
  • Is there a way to diagnose and solve the problem?
    – Xegara
    Sep 9, 2015 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, 2015 at 17:06
  • Is it possible to bypass any potential rewriting of packets using networking technology like SSL, VPN, HTTPS?
    – Xegara
    Sep 10, 2015 at 5:01
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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .