Why your private network has a different MTU than your public one
Quick answer
MTU (Maximum Transmission Unit) is the largest packet a network link will carry without fragmenting it. The public internet's long-standing default is 1500 bytes. Private and overlay networks are usually built by wrapping your traffic inside another packet (a technique like VXLAN), and that extra wrapper takes up some of the space, which is why a private interface commonly needs a slightly smaller MTU, 1450 bytes is a typical example, than the public interface's 1500. Get the mismatch wrong and you don't get an error, you get connections that hang or crawl for no obvious reason.
What MTU actually controls
Every network link has a ceiling on how large a single packet can be before it has to be split up. That ceiling is the MTU, measured in bytes. Anything a system tries to send larger than the link's MTU either gets broken into smaller fragments, if fragmentation is allowed, or gets dropped outright, if it isn't. The public internet has settled on 1500 bytes as its practical default, inherited from Ethernet, and most systems assume that number unless something tells them otherwise.
Why a private network's MTU is often smaller
A private or overlay network on shared infrastructure usually isn't a physically separate set of wires per customer. It's built by encapsulation: your traffic is wrapped inside another packet, tagged so the underlying network can keep each customer's private traffic isolated from everyone else's, using a tunnelling technique such as VXLAN. That wrapper is real data. It adds its own header to every packet, on top of whatever your own traffic already carries.
That added header has to fit inside the same underlying link's MTU as everything else. So the space actually available to your payload, after the encapsulation header takes its share, is smaller than the full 1500 bytes the public interface can use. In practice this is why a private network interface commonly runs a slightly reduced MTU, 1450 bytes is a common example figure, to leave enough headroom for the tunnelling overhead without silently breaking anything.
What an MTU mismatch actually looks like
This is the part that catches people out: an MTU mismatch rarely produces a clean error message. What it produces is inconsistency. Small packets, a ping, a short request, go through fine, because they're well under any MTU involved. Larger packets are the ones that hit the ceiling, and what happens next depends on whether fragmentation is allowed on that path:
- If fragmentation is allowed, oversized packets get split, which works but adds overhead and can quietly slow throughput without ever throwing an error.
- If fragmentation is disabled, which some protocols do deliberately for performance reasons, oversized packets are simply dropped. No error comes back to explain why, the connection just stalls, times out, or behaves as if the network is broken.
The practical symptom is usually: small requests work, larger transfers or specific protocols hang or fail, and it's worse over the private link than over the public one, because the private link is the one running the smaller effective MTU. That pattern, working fine for small traffic and breaking specifically on larger payloads over the private interface, is one of the more reliable signs to check MTU settings on both ends of a private network connection.