Jtdylktuy

Everyday I access a 3rd party website either via my browser directly or requesting files via a javascript application I developed. This morning, my connection to that site has been so slow that the majority of my requests timeout.

I did some testing and I can access the site just fine via my WIFI network, but it doesn't work via LAN. My WIFI network is simply a WIFI access point connected to my LAN so both are using the same subnet and gateway. I've had the same issues on multiple computers and it only seems to be related to this one website. The rest of the sites I have visited are problem-free.

I'm completely baffled. We've called technical support for the site and they said it must be a problem on our end because all their diagnostics check out.

Any ideas why a particular domain would only work on a WIFI access point and not on the LAN itself?

If the Wi-Fi AP is acting as a NAT gateway (which assumes its WAN port is plugged into the upstream router's LAN port), it may be doing DNS differently, or it may be doing a better job of TCP MSS Clamping than your upstream NAT gateway is doing.

As for DNS, suppose your upstream NAT gateway, when giving out DHCP leases to wired Ethernet client, tells clients to use DNS Server A. Support your Wi-Fi AP, when giving out DHCP leases to Wi-Fi clients, tells clients to use DNS Server B. Now suppose DNS Server A has a bug where it chokes on DNS responses for one website's domain name. All of your Ethernet clients would fail to find the IP address they need to use to connect to that website, so they'd all fail to connect. But your Wi-Fi clients would be asking DNS Server B, which doesn't have that bug, so they'd get the answers they were looking for and would be able to connect.

To test if DNS is the problem, make sure your Ethernet and Wi-Fi clients are all getting the same DNS server addresses.

TCP MSS Clamping is a method where a NAT gateway thinks it knows more about upstream MTUs (MTU = Maximum Transmission Unit; think of it as a maximum IP packet size) than its clients do, so if it ever sees a client try to negotiate a TCP MSS (an MSS is a TCP-layer Maximum Segment Size, which is the TCP-layer equivalent of the IP-layer's "MTU" concept) that's bigger than will fit in the upstream pipe, the NAT gateway rewrites those TCP MSS negotiation fields in the TCP SYN packets to trick the TCP endpoints into agreeing to a smaller MSS which should actually work given what the NAT gateway knows about MTU restrictions on the other network hops.

To test if MTU stuff is the problem, trying pinging the problem website with both a normal ~64-byte ICMP echo request, and then try again with an ICMP echo request that fills the whole 1500 byte frame:

# Normal small pings first, just to see if pings work

ping badwebsite.example.com

# Now pad the pings out to 1472 so that, after headers are added, it's a full 1500 byte frame.

ping -s 1472 badwebsite.example.com

(I suppose I shouldn't have to say this, but just in case, make sure you did those ping tests from an Ethernet client, not a Wi-Fi client.)

If small pings work but large pings fail, it indicates an MTU problem. Try different values after -s to see what's the maximum value that works for you. Add 28 to it to find out what MTU you can safely set on your Ethernet clients. Actually, better than manually setting a smaller MTU on your Ethernet clients, fix your upstream NAT to do proper MSS clamping or something.