One machine blocked from a single server, and only when it's at this physical location?

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?

Update

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?

Solution 1:

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

Solution 2:

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.