I host an e-commerce website for a client who suddenly is unable to access it from his computer. He can ping the server, he can SSH in, but cannot load the website in any browser we've tried: IE, Firefox, Chrome, Opera. Other machines at this location can connect ok. DNS resolves fine, accessing direct with IP address does not work. Using Wireshark on the server side I can see the requests come in, and the responses leave our switch. Wireshark on the client end sees no reply.

Tried so far:

I find nothing in the client's router settings that would block the site for this one computer. He's had his public IP reassigned, and he's tried a different private IP to no avail.

This all seems to point to malware or an otherwise busted Windows 7 install.

The kicker: carry the machine off-site to a different Internet connection, and it works fine. I have never heard of malware that would deny only return responses from one specific server and only while working from a certain public IP address specific physical location (public IP changed, no difference).

In my experience when some sort of filter is the cause, either all the machines behind a single connection would be blocked, or a single machine would be blocked behind all connections. Here it seems neither applies.

What could be the problem? What do we test next?


I noticed the initial redirect to www. was working before the hang, and that the favicon was coming through. Sure enough, both these requests were under 1k and it lead us to check the MTU values on the client and server. But why were they changed?

  • client's ISP is Comcast if that should matter (but since other computers work there, I doubt it) (but since this same computer works elsewhere... maybe?)
    – rymo
    Mar 6, 2012 at 3:13
  • Am I correct in assuming you've tried this computer in an Ethernet port that a known-working computer is using? Mar 6, 2012 at 3:14

2 Answers 2


if client's router is linux-based, please check that:

1) ICMP blocked by site or ISP

2) client used PPPOE connection

man iptables:

TCPMSS This target allows to alter the MSS value of TCP SYN packets, to con‐ trol the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40 for IPv4 or 60 for IPv6, respec‐ tively). Of course, it can only be used in conjunction with -p tcp.

   This target is used to overcome criminally braindead  ISPs  or  servers
   which  block  "ICMP  Fragmentation  Needed"  or "ICMPv6 Packet Too Big"
   packets.  The symptoms of this problem are that everything  works  fine
   from  your  Linux  firewall/router,  but  machines  behind it can never
   exchange large packets:

   1.  Web browsers connect, then hang with no data received.

   2.  Small mail works fine, but large emails hang.

   3.  ssh works fine, but scp hangs after initial handshaking.

   Workaround: activate this option and add a rule to your  firewall  con‐
   figuration like:

           iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN
                       -j TCPMSS --clamp-mss-to-pmtu
  • client's router is a combination cable modem/gateway that's been factory reset. replacement might be on the table if we can narrow it down to that.
    – rymo
    Mar 6, 2012 at 13:48
  • how can I test to be sure my Linux server isn't "criminally braindead"?
    – rymo
    Mar 6, 2012 at 13:49
  • 1) try ping site 2) check mtu on client side router. 1492 is norlmally value for PPPOE 3) use low level checking with tcpdump tool.
    – dzift
    Mar 6, 2012 at 17:52
  • 1
    this isn't a PPPOE connection, but we did investigate MTU values and found that the Windows 7 machine was set to 1504 and the Linux server was set to 1514. putting either of these back to 1500 fixed the problem, now we have to figure out how/when they got this way
    – rymo
    Mar 14, 2012 at 17:10

I once had a similar issue with the Electronic Arts account website (Could ping, could access via FTP, couldn't access via HTTP, other machines on the network were fine), and it turned out something along the route didn't like RFC1323 timestamps I'd enabled at some point.

Try netsh int tcp set global timestamps default. If that doesn't work, just take a look at netsh int tcp show global or, if you want the nuclear option, netsh int ip reset, netsh int tcp reset, followed by a netsh winsock reset and a reboot [you may need to reinstall any third-party firewalls or network inspection software at this point].

You might also try http://www.microsoft.com/windows/using/tools/igd/default.mspx , if this seems to be an issue solely with Win7.

You might also try a LiveCD - easier than reinstalling as a troubleshooting step.

  • +1 for the LiveCD - we used Ubuntu to verify it wasn't a hardware problem
    – rymo
    Mar 14, 2012 at 17:07

You must log in to answer this question.

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