Recently, I moved a site from its old WAN circuit to an IPVPN connection. Cutover went fine, almost everything worked. Internet, intranet, wifi, email, file shares, all good...except an incident the next day about a print server's web interface that stopped loading in a browser.

Everything else on the site worked, which made this confusing at first. I checked the print server's web service, certificate, dev tools, ACLs, and firewall in the path. None of that was the problem. Then I decided to dive into the last resort, the Wireshark PCAP.

What the Capture Showed

The trace had duplicate ACKs stacked three deep, fast retransmissions, out-of-order segments, and spurious retransmissions. That pattern, right after the migration, points to MTU/MSS immediately.

MTU and MSS

MTU (Maximum Transmission Unit) is the largest packet size a link can carry before it has to fragment. Standard Ethernet is 1500 bytes. Every device in the path (switches, routers, VPN concentrators) has its own MTU, and the smallest one in the chain sets the ceiling for the whole path.

MSS (Maximum Segment Size) is the TCP-layer version of the same limit. It's the largest chunk of data a TCP segment will carry after IP/TCP headers. Hosts announce their MSS during the handshake based on their own interface MTU, not the MTU of everything in between.

That's the problem. Both ends can agree on an MSS based on a 1500 byte MTU while the actual path, after additional encapsulation or other provider overhead, supports less. Sometimes packets just get dropped instead of fragmented, which is what happened in my case.

Why Only One App Broke

Most traffic never gets close to the real limit. DNS queries, small API calls, short HTTPS handshakes, none of these come near 1400+ bytes in a single segment. They go through fine regardless of the MTU problem.

The traffic that breaks is the traffic that tries to send full-size segments. The print server's web UI was sending larger chunks (images, JS) that consistently hit the limit smaller protocols never reached. One app failing while the rest of the site works is a fairly reliable signature of an MTU/MSS issue.

How to Confirm It

Use a DF-bit ping to force a fail instead of letting it silently fragment:

ping 10.10.10.10 size 1472 df-bit

That sends a 1500 byte packet (1472 payload + 28 bytes IP/ICMP overhead) with Don't Fragment set. If it fails, step the size down until one succeeds. That size tells you your real usable MTU.

Binary search is faster than walking down by 1. Start at 1200 and 1472, split the difference each round. Took about six pings to land on the real number.

In this case, 1420 worked and 1440 didn't. That was enough to calculate a safe MSS without chasing the exact byte.

One thing worth knowing if you're running Cisco TrustSec or any inline SGT tagging: ICMP echo doesn't carry SGT metadata, so a DF-bit ping can come back slightly optimistic if your actual TCP traffic gets tagged inline on that path. Worth checking your CTS on anything in the path before locking in a number, even if it turns out not to matter.

The Fix

The interface to clamp is the one facing the affected path, the WAN-facing interface that actually touches the IPVPN circuit, not the inside-facing interface. Adjust MSS there so TCP never negotiates a size that doesn't fit:

interface GigabitEthernet0/0/0.10
 ip tcp adjust-mss 1420

Math: usable MTU (1460) minus 40 bytes for IP/TCP headers. This forces every TCP session on that interface to negotiate a size that actually survives the path instead of relying on PMTUD (Path MTU Discovery), the mechanism that's supposed to figure out the largest packet size a path supports without fragmentation, but often gets blocked by providers filtering the ICMP messages it depends on.

The Other Issue: Leftover Config

While troubleshooting, I found an ip mtu 1480 statement on a VLAN interface in the path between the core switches and the router. Nobody could explain why it was there. Probably a leftover from a previous WAN design that never got cleaned up, likely tied to legacy tunnels.

It wasn't the actual bottleneck here, since the IPVPN ceiling was already lower than 1480. The rule that matters: the smallest MTU anywhere in the path wins. A higher cap sitting upstream of an already-smaller constraint does nothing, good or bad, it's just dead weight until some future change moves the real ceiling above it. Then it becomes the new bottleneck without anyone touching it.

Takeaways

One app breaking after a network change doesn't mean the app is the problem. It often means the new path has a smaller ceiling and only the heavier traffic is hitting it.

Test the path directly with DF-bit pings instead of guessing. Two minutes to test, don't be lazy.

Audit old interface configs after any network change. Settings like a manually pinned MTU can outlive their original reason by years, maybe longer.

Document why a setting exists, not just what it does. Probably the hardest part of any engineer's job, but it prevents so much pain for whoever comes after you.

One line of config fixed it. Finding that line took more troubleshooting than I'm proud of, a packet capture, and a few rounds of DF-bit testing.