A subscriber reports that some websites hang half-loaded, their office VPN connects but never passes traffic, and small requests work fine while anything with a larger payload just times out. Ping to the same host works perfectly. This is the signature of an MTU problem on a PPPoE link, and it almost never shows up as "the internet is down" — it shows up as "some things work and some don't," which is exactly why it gets misdiagnosed as a routing or DNS issue first.
Understand why PPPoE causes this in the first place
Ethernet carries up to 1500 bytes of payload. PPPoE adds its own 8-byte header inside that frame, leaving only 1492 bytes for everything above it — so a subscriber's device that still assumes a 1500-byte path MTU sends packets that are too big for the PPPoE link. Normally the router would reply with an ICMP "fragmentation needed" message so the sender adjusts, a mechanism called Path MTU Discovery. The problem is that plenty of firewalls, both on the subscriber's end and out on the internet, block ICMP outright — so that correction message never arrives, and the oversized packet just gets silently dropped over and over.
See why this hits TCP-heavy traffic hardest
Small requests — a DNS lookup, a ping, the start of a TCP handshake — fit under 1492 bytes without a problem, which is why basic connectivity looks fine. It's only once a TCP session tries to push a full-size segment, which is exactly what happens loading a page with any real content or pushing data through a VPN tunnel, that the oversized packet hits the PPPoE link and vanishes with no error reported back. That mismatch — "ping works, browsing doesn't" — is the tell.
Add an MSS clamping rule in mangle
Instead of waiting on Path MTU Discovery to work (which requires cooperation from networks you don't control), clamp the TCP MSS on the way out so every SYN packet already advertises a segment size that fits inside the PPPoE MTU:
/ip firewall mangle add chain=forward tcp-flags=syn protocol=tcp \
action=change-mss new-mss=clamp-to-pmtuclamp-to-pmtu is preferred over a hardcoded number like new-mss=1400 — RouterOS calculates the correct value per-interface automatically, which matters once you have subscribers on different encapsulations (PPPoE, plain Ethernet, WireGuard) behind the same router.
Apply it on the interface that actually needs it
The rule above runs on every forwarded connection, which is fine for a small deployment, but on an access concentrator with hundreds of PPPoE sessions it's worth scoping it to just the PPPoE interface list so it isn't doing unnecessary work on subscriber traffic that was never going to have the problem:
/interface list add name=pppoe-clients
/ip firewall mangle add chain=forward tcp-flags=syn protocol=tcp \
out-interface-list=pppoe-clients action=change-mss new-mss=clamp-to-pmtuConfirm the fix with a real transfer, not just a ping
Ping was never going to show this problem, so it can't confirm the fix either. Load a page with real content, or run /tool traceroute combined with a large-payload test — the affected VPN client or the previously half-loading site is the real test. If it now loads cleanly and the VPN passes traffic, the clamp rule is doing its job.
Why do it this way
The alternative to MSS clamping is telling every subscriber to manually lower their device's MTU to 1492, which doesn't scale, doesn't survive a device reset, and does nothing for subscriber-owned equipment you don't control. MSS clamping fixes it at the one point you do control — your own router — by making sure TCP sessions never negotiate a segment size that's too big for the path in the first place, so there's nothing left for a blocked ICMP message to have to fix. It's a five-minute mangle rule that eliminates an entire category of "some things don't work" tickets that are genuinely painful to diagnose from the symptom alone.
How MoniTik helps
This kind of problem is invisible to basic ping-based monitoring precisely because ping still works — the link looks up while subscribers are actually stuck. MoniTik's per-interface traffic graphs make it easier to spot the real signature: a connection that's reachable but shows unusually low throughput or erratic transfer patterns compared to its baseline, which is a much better lead into an MTU issue than waiting for a support call about a VPN that "just doesn't work."
Valentina has spent the last decade deploying and troubleshooting MikroTik networks for ISPs across Latin America.