Your internet feels slow. Pages stall halfway through loading. Your SSH session connects fine, but the moment you run ls minus la, it freezes like a deer in headlights. And somewhere, some guy on Reddit told you to set your MTU to fourteen ninety-two. So you did. And maybe it helped, maybe it didn't, maybe you just believed it did because you wanted to be done thinking about it.
Wait, I have definitely set fourteen ninety-two before. Someone on a forum said "fiber MTU fourteen ninety-two" and I just... Didn't ask questions.
That's the thing. Thousands of people are running fourteen ninety-two on fiber connections that should be running fifteen hundred. Because the forum advice hasn't caught up to the technology.
The number everyone throws around for fiber might be wrong for actual fiber.
Here's what's happening. FTTH is rolling out globally, replacing old DSL and VDSL connections that used PPPoE authentication. PPPoE adds eight bytes of overhead — that's where fourteen ninety-two comes from. But a lot of modern fiber deployments don't use PPPoE at all. They use DHCP, plain IPoE. Fifteen hundred is correct. If you blindly set fourteen ninety-two, you're leaving performance on the table for no reason.
The real question isn't "should I set fourteen ninety-two or fifteen hundred." It's "how do I figure out which one my actual connection needs.
And that's what we're going to walk through today. Specifically for someone running OPNsense on an Israeli fiber connection, but the method applies anywhere. We'll cover what MTU actually means, where fourteen ninety-two came from, how to test your own link empirically, and what settings like MSS clamping actually do.
Daniel sent us this one. He's in Israel on FTTH, running OPNsense, and he wants the diagnostic method, not the cargo-cult answer.
This is one of those topics where the cargo cult is everywhere. Fourteen ninety-two has become a magic incantation people recite without knowing what it means or whether it applies to them.
I was literally one of those people. I set fourteen ninety-two because the internet told me to. Now I'm wondering if I've been wrong for years.
You probably have been. So let's start with the basics. MTU stands for maximum transmission unit. It's the largest single IP packet, measured in bytes, that can traverse a network link without being chopped into smaller pieces — fragmentation. Think of it as the height clearance on a bridge. If your truck is under the bar, you sail through. If it's over, you unload half the cargo, send it in two trips, and reassemble at the other end.
The bar is set at fifteen hundred by default.
The Ethernet payload default of fifteen hundred bytes comes from the DIX standard — DEC, Intel, Xerox — published in nineteen eighty. They were balancing throughput against error recovery. Smaller packets meant more overhead but faster retransmission if something got corrupted. Fifteen hundred was the sweet spot for the hardware of the era, and it stuck. Every Ethernet frame can carry up to fifteen hundred bytes of IP payload. That's been the norm for over forty years.
If fifteen hundred is the universal default, where does fourteen ninety-two come from?
Point-to-Point Protocol over Ethernet. It's an authentication and encapsulation layer ISPs used heavily during the DSL era. When you wrap an IP packet inside a PPPoE session, you add exactly eight bytes of overhead — two bytes for the PPP protocol ID, six bytes for the PPPoE session header, defined in RFC twenty-five sixteen. Your fifteen-hundred-byte packet now needs fifteen hundred and eight bytes. But Ethernet still only gives you fifteen hundred.
The packet gets squeezed. Fifteen hundred minus eight equals fourteen ninety-two.
For decades, that was the right answer for most home connections. The forum advice was good. It just hasn't aged well.
Fiber changed the game.
Fiber changed the authentication model. Many modern FTTH deployments use DHCP — plain IPoE. No PPP layer, no eight-byte header. The packet that leaves your router is the packet that hits the ISP's edge. Fifteen hundred bytes fits perfectly. If you set fourteen ninety-two on a DHCP fiber link, you're voluntarily shrinking every packet by eight bytes, adding roughly half a percent of unnecessary overhead to everything you do online.
Half a percent doesn't sound catastrophic.
It's not catastrophic, but it's pure waste. In edge cases — large file transfers, high-throughput VPNs — it adds up. More importantly, it means you configured your router based on a cargo cult instead of what's actually on the wire.
How do I know which one I've got? I'm staring at my OPNsense dashboard.
Interfaces, then WAN. If it says PPPoE, fourteen ninety-two is correct. If it says DHCP, you're on IPoE, and fifteen hundred is correct. That's the first check.
The Israeli fiber providers — Bezeq, HOT, Cellcom, Partner — where do they land?
On older xDSL and VDSL, PPPoE was standard. On modern fiber, many deployments have moved to DHCP. But ISP behavior varies by region, by neighborhood, sometimes by which generation of ONT is installed. I've seen two apartments in the same building get different authentication methods because one was provisioned earlier. You cannot assume.
Even in Israel in twenty twenty-six, you might still be on PPPoE depending on your specific install.
Partner fiber still has legacy PPPoE configs on some lines. The only way to know is to check your own WAN interface type in OPNsense. If PPPoE, use fourteen ninety-two. If DHCP, start with fifteen hundred. Then verify empirically, which we'll get to.
If fifteen hundred is the standard and fiber mostly uses DHCP, why does every forum still scream fourteen ninety-two?
Because internet advice has a half-life, and this one's expired. The people writing those posts learned networking during the DSL era. They internalized fourteen ninety-two as the "safe" number and never updated their mental model. Forums reward repetition — the same answer gets copied for fifteen years until it becomes received wisdom, disconnected from the original reason.
The telephone game, but for router configuration.
The stakes are low enough that nobody notices they're wrong. Setting fourteen ninety-two on a fifteen-hundred link won't break your internet. It'll just be slightly slower in ways you'll never isolate to the MTU setting. So the myth survives.
Until some donkey reads an RFC and ruins everyone's comfortable assumptions.
That's what I'm here for. So let's bust some myths. First one: lower MTU is safer.
I've heard this. "Just set it to fourteen hundred and stop worrying.
It sounds reasonable and it's completely backwards. Lower MTU increases per-packet overhead. Every packet has headers — Ethernet, IP, TCP — a fixed cost regardless of payload size. If you drop your MTU from fifteen hundred to fourteen hundred, you're sending more packets to move the same data, which means more total header bytes, more processing on your router, and lower effective throughput.
You're paying the header tax more often.
Here's the less obvious part. Lower MTU can actually cause more fragmentation, not less. If your local MTU is fourteen hundred but some intermediate link has an MTU of fourteen fifty, your router thinks everything's fine. But a router further down the path might be fragmenting those packets, and if ICMP is blocked, you get the same black-hole problems at a different layer. The goal is always the highest MTU the entire path supports, not the lowest common denominator you can guess at.
"set it low and forget it" is paying a performance tax for no safety benefit.
Misconception number two: "I'll just set the exact same MTU on every device and the problem is solved.
I have tried this. Felt very responsible.
It doesn't fix the real problem, because the real mechanism isn't local MTU matching. It's Path MTU Discovery — PMTUD.
Break that down.
Path MTU Discovery lets two endpoints dynamically figure out the largest packet that can traverse the entire path without fragmentation. It exploits a flag in the IP header called the Don't Fragment bit. When a packet has DF set, no router along the path is allowed to fragment it. If a router encounters a packet too big for the next link with DF set, it drops the packet and sends back ICMP type three, code four — "Fragmentation Needed and Don't Fragment was Set.
The router says "I can't forward this and I'm not allowed to chop it up, here's your rejection notice.
That rejection notice includes the MTU of the next-hop link. The sending host receives it, says "okay, let me try a smaller packet," and resends. This happens transparently. TCP connections just work, adapting to whatever the path supports.
This depends on that ICMP message getting back to the sender.
That's where it falls apart. Many consumer routers, and even some ISP edge equipment, block ICMP entirely. Some administrator decided ICMP is a security risk and blocked all of it. When that happens, the "Fragmentation Needed" message never reaches the sender. The sender keeps retransmitting the oversized packet. The router keeps dropping it silently. The connection just hangs.
The black-hole router problem.
Matching MTU on every device in your house does nothing to fix this, because the black hole is somewhere out on the internet, beyond your control. Your router sends correctly-sized packets for your local link, but the path between some intermediate router and the destination has a lower MTU, and the ICMP response is blocked.
If some random router between me and a server blocks ICMP, PMTUD breaks, and I get pages that partially load, SSH that freezes on large output.
That's exactly the failure mode. It's one of the most underdiagnosed networking problems out there. People blame their VPN, their DNS, their browser. They never suspect PMTUD black holes.
If PMTUD is broken and ICMP is blocked somewhere I can't control, am I just screwed?
There's a workaround called MSS clamping. But first, misconception number three: jumbo frames.
Nine thousand MTU. I've wondered if I should crank it up.
You should not. Jumbo frames are a LAN-side optimization for high-throughput local transfers, like moving files between a NAS and a desktop over a ten-gigabit switch. They only work when every device on the Layer two segment supports them.
The internet definitely does not.
Consumer ISPs will fragment or drop jumbo frames at their edge. If you set your WAN interface to nine thousand, your router sends a nine-thousand-byte packet toward your ISP, and their equipment either fragments it into six or seven smaller packets — defeating the purpose — or just drops it. Your internet gets worse, not better.
Jumbo frames are completely useless for anything that leaves the house.
Laptop to NAS over your local switch? Laptop to a server in Amsterdam? The jumbo frame never makes it past your ONT.
Misconception number four: MTU and MSS are the same thing.
They're related but operate at different layers. MTU is the maximum IP packet at Layer three. MSS — Maximum Segment Size — is the maximum TCP payload at Layer four. For a standard fifteen-hundred-byte MTU, MSS is typically fourteen sixty. That's fifteen hundred minus twenty bytes for the IP header and twenty for TCP.
MTU is the whole envelope. MSS is just the letter inside.
Here's why the distinction matters. MSS clamping works at the TCP layer. When your router sees a TCP SYN packet leaving your network, it can rewrite the MSS option to a lower value. If your WAN MTU is fourteen ninety-two, the correct MSS is fourteen fifty-two. By clamping the MSS in the SYN packet, you're telling the remote server "please don't send me TCP segments larger than fourteen fifty-two bytes." The remote server complies, and your packets never exceed the path MTU, even if PMTUD is broken. It sidesteps the whole ICMP black-hole problem.
MSS clamping is preemptive obedience. You tell the other end "don't send me anything bigger than this" before the conversation starts.
And it's why MSS clamping is such a useful safety net. But let's get practical. How do you actually know if your MTU is wrong? The symptoms are maddeningly inconsistent.
I've had the SSH thing. Connect fine, run ls minus la in a big directory, and the session freezes mid-output. I spent two hours convinced it was a firewall rule.
Classic PMTUD failure. The SSH handshake uses small packets — they sail through. Then the server tries to push a fifteen-hundred-byte packet. It hits a link with a lower MTU, DF is set, the router drops it and sends ICMP type three code four back. Except some firewall blocks ICMP. The server never gets the message. It waits for an ACK that never comes. Your terminal stares at you.
I'm blaming my SSH config, my keys, my terminal emulator. Everything except the actual problem.
The other telltale sign is partial page loads. Images appear but text doesn't. Or HTML loads but CSS and JavaScript hang. Small assets fit within the real path MTU, but larger assets trigger the black hole.
VPN tunnels that work for pings but die on file transfers. I've seen that too.
WireGuard's default MTU is fourteen twenty, which accounts for its encapsulation overhead. But if your WAN link is PPPoE at fourteen ninety-two, the inner TCP packet inside the tunnel might be fourteen sixty, plus WireGuard's overhead, pushing the outer packet above fourteen ninety-two. Now you're back in fragmentation territory.
The symptoms are: pages that half-load, SSH that freezes on big output, VPNs that ping but don't transfer, large uploads stalling. And the root cause might be the same thing — a path MTU mismatch with ICMP blocked somewhere.
The fix is empirical. You don't guess.
Walk me through it. I'm at my OPNsense console.
Open a shell on the OPNsense box. Run: ping space minus M space do space minus s space fourteen seventy two space eight dot eight dot eight dot eight.
Break that down. What's fourteen seventy two?
That's the ICMP payload size. The full packet will be fourteen seventy two plus twenty eight bytes of headers — twenty for IP, eight for ICMP. Total: fifteen hundred bytes. The minus M do flag sets the Don't Fragment bit. You're saying "send a fifteen-hundred-byte ping with DF set and tell me if it makes it.
If it works?
Your path supports MTU fifteen hundred. Set your WAN MTU to fifteen hundred and move on.
What does a failure look like?
"ping: sendmsg: Message too long," or the ping hangs with no response. A router along the path couldn't handle fifteen hundred bytes with DF set.
Then I drop the payload by eight bytes.
Run ping space minus M do space minus s space fourteen sixty four space eight dot eight dot eight dot eight. That's fourteen sixty four plus twenty eight equals fourteen ninety two total. If that works, your path MTU is fourteen ninety two. Set your WAN MTU accordingly.
If fourteen sixty four still fails?
Keep dropping by eight. Fourteen fifty six gives fourteen eighty four. Fourteen forty eight gives fourteen seventy six. Eventually you'll find the number that works. Add twenty eight to whatever payload size succeeds — that's your real path MTU.
What if I end up at some weird number like fourteen eighty four?
Then something exotic is happening — double-NAT, a GRE tunnel, IPsec encapsulation, or a misconfigured intermediate router. Fourteen eighty four is fifteen hundred minus sixteen, which could be a VLAN tag plus something else. The number itself is a clue. But the principle is the same — test, find the ceiling, set it, verify.
What about diagnosing from Windows instead of the router?
Same logic, different flag. ping space minus f space minus l space fourteen seventy two space eight dot eight dot eight dot eight. Minus f sets Don't Fragment, minus l specifies payload size. Drop by eight the same way.
Once I've found my MTU, where do I set it in OPNsense?
Interfaces, WAN, scroll down to MTU. If you're on DHCP it probably shows fifteen hundred already. If PPPoE it might show fourteen ninety two. Change it if your test says otherwise. But there's one more thing you should do regardless.
On OPNsense, if your WAN is PPPoE, MSS clamping is usually applied automatically. For DHCP WAN interfaces, you may need to add it manually under Firewall, Settings, Normalization. Or add a firewall rule on the WAN interface that clamps MSS in TCP SYN packets.
Should I just enable MSS clamping on everything as a safety net?
It's low-risk for most home users. The CPU overhead of rewriting the MSS field in SYN packets is negligible on modern hardware. If you're routing ten gigabit with deep packet inspection and VPN termination, you want proper PMTUD working. For the typical home OPNsense box on a gigabit fiber connection? Clamp it and forget it.
The ideal setup is correct MTU plus MSS clamping as a backstop.
The MTU handles your side. MSS clamping protects you from every ICMP-blocking firewall between you and the servers you're talking to. Belt and suspenders.
Let's run through a real example. Someone on Bezeq FTTH, OPNsense WAN set to DHCP, MTU fifteen hundred. They run the ping test — fourteen seventy two works. They're good. But they read some forum post and set MSS clamp to fourteen fifty two "just in case.
That's actually fine. It's unnecessary, but it won't break anything. The MSS clamp at fourteen fifty-two is correct for a fourteen ninety-two link, but they're running fifteen hundred. They're telling remote servers to send slightly smaller segments than the link can handle. No harm, just a tiny bit of throughput left on the table — about half a percent. You'll never notice. But here's the real takeaway: test, don't guess.
That's the through-line. Never blindly set MTU to fourteen ninety-two. First, check your WAN interface type in OPNsense. If DHCP, start with fifteen hundred. If PPPoE, start with fourteen ninety-two. Then verify with the ping test — it takes thirty seconds.
Run ping space minus M do space minus s space fourteen seventy two space eight dot eight dot eight dot eight from the OPNsense shell. If it works, you're done. If not, drop the payload by eight until it works, add twenty eight, and set that as your WAN MTU. Write the result down — you'll thank yourself in two years when troubleshooting something else.
Step three: enable MSS clamping on your WAN interface. OPNsense does this automatically for PPPoE. For DHCP WAN, add it under Firewall, Settings, Normalization. It's your safety net against ICMP black holes you can't control.
Step four: if you run VPNs, check their interface MTU settings. WireGuard defaults to fourteen twenty, which is usually fine. But if you're behind a PPPoE link at fourteen ninety-two, you might need to drop WireGuard to fourteen twelve to keep the outer packet from exceeding the path MTU. Test through the tunnel the same way — ping with DF set to a host on the other side.
The whole method boils down to: look at your WAN type, run one ping command, do the math, set the number, clamp MSS, and for VPNs, test through the tunnel. That's the checklist.
This works anywhere. Israeli fiber, American cable, European VDSL, a Starlink terminal in the middle of nowhere. The ping test doesn't care about your ISP's marketing materials. It tells you what the network actually supports.
Test, don't guess. And MSS clamp is your friend.
MSS clamping is your friend, but it's a band-aid. Proper MTU configuration is the actual fix. Clamping protects you when PMTUD fails, but you still want PMTUD working correctly on your side. The two work together.
In five years, will anyone still be talking about fourteen ninety-two?
Only in history lessons about the PPPoE era. As ISPs move to IPoE and DHCP on fiber, the eight-byte overhead vanishes. But MTU diagnosis as a skill isn't going anywhere.
Because new encapsulation technologies will bring their own overhead.
VXLAN adds fifty bytes of header. GENEVE is variable-length but typically even more. If you're running virtualized networking or overlay tunnels, you'll be doing the same ping test, just with different numbers. The fourteen ninety-two magic number will fade, but the method — test, don't guess — that's permanent.
Then there's IPv6.
IPv6 changes the game entirely. In IPv4, intermediate routers can fragment packets as a fallback. IPv6 eliminates that — routers cannot fragment. Fragmentation happens only at the endpoints. So Path MTU Discovery isn't optional in IPv6, it's mandatory. And the ICMPv6 Packet Too Big message is the only way a router can tell you "this packet won't fit.
Which means if your ISP blocks ICMPv6, you're in real trouble.
You're completely dead in the water. In IPv4, blocking ICMP creates black-hole connections that are often survivable because of MSS clamping. In IPv6, blocking ICMPv6 Packet Too Big means any connection trying to send a full fifteen-hundred-byte packet over a link with a smaller MTU simply never works. No fallback, no clamping workaround — TCP handshake completes, data starts flowing, then silence.
ISPs do block ICMPv6?
Some do, through misguided security policies or negligence. It's a growing concern as IPv6 deployment increases. The good news is major providers are getting better — Google, Cloudflare, and the big CDNs have been loud about ICMPv6 being essential. But the protocol design assumes a well-behaved network, and reality doesn't always cooperate.
The skill of empirical MTU diagnosis — the ping test, the methodical drop-by-eight — that's going to be more valuable, not less.
The tools will evolve, but the diagnostic mindset won't. You'll be running the same logic, just with IPv6 addresses and ICMPv6 types. The network doesn't lie to you if you know how to ask it the right question.
Here's what I'd tell anyone listening: tonight, open a shell on your router, run that ping test, and find out what your connection actually supports. Don't copy a number from a forum. Don't assume fourteen ninety-two because someone on Reddit said so.
If you do, share your results on the My Weird Prompts community forum. I'm genuinely curious what people find — especially on the Israeli fiber providers. We have a theory about what the numbers should be, but real-world data is always more interesting.
Next episode we're digging into DNS — why your queries are slower than they should be, resolver selection, EDNS, DNSSEC overhead. If you thought MTU was an invisible performance killer, wait until you see what your DNS resolver is doing to you.
That's going to be a fun one. I've already got a stack of RFCs on my desk.
Of course you do. This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping this ship pointed vaguely forward. You can find us at myweirdprompts dot com, on Spotify, or wherever you get your podcasts. If you enjoyed this, leave us a review — it helps.
I'm Herman Poppleberry.
I'm Corn. Go run that ping test.
Hilbert: Now: Hilbert's daily fun fact. During the Cold War, Equatorial Guinea's first national oil wrestling tournament was inadvertently seeded by a Turkish petroleum engineer who taught the sport to his local drilling crew — meaning the country's entire yagli gures tradition descends from a single expat's weekend hobby.
I have so many follow-up questions I know I'll never get answers to.
