MTU and CGNAT test

How the test works

An MTU problem rarely looks like one. Small requests work, so websites half-load, VPNs connect but stall, and large downloads or uploads hang. The cause is usually a link in the path that carries smaller packets than the ends expect, for example PPPoE (1,492 bytes) or a tunnel, together with a firewall that drops the ICMP "packet too big" messages that would tell the sender to slow down. That combination is called a path MTU discovery (PMTUD) black hole.

• What your router advertises. When your device opens a connection it states the largest TCP segment it can receive (the MSS). Our server reads it from your connection's opening packet. 1,460 bytes on IPv4 or 1,440 on IPv6 means a standard 1,500-byte link; a smaller figure usually means the router is clamping it to fit PPPoE or a tunnel, which is the fix, not the fault.
• Whether full-size packets arrive. The server then sends you full-size packets and watches what happens to them. If a smaller link lies in the path and ICMP gets back, the server's kernel learns the smaller size and carries on: discovery works. If packets are lost and nothing comes back, the transfer stalls: a possible black hole.
• A control that always works. Starting the test and reading the results go to a second port that only ever sends small packets, so the test can still report a black hole that stops the full-size test dead.
• Carrier-grade NAT. The test shows the public IPv4 address our server saw. If the WAN address on your router's status page is different, and in particular if it lies between 100.64.0.0 and 100.127.255.255, your provider shares one public address between customers, so you cannot accept incoming connections on IPv4.

The test measures delivery from our server to you, on this route. It cannot see upload problems or paths to other destinations, and an inconclusive result is reported as inconclusive. For background, read how we bring SIMs onto private networks, where MTU across tunnels matters most.