MTU Configuration and Troubleshooting¶

MTU (Maximum Transmission Unit) mismatches are a common cause of network connectivity issues, especially in complex SD-WAN topologies with multiple tunnel layers. This guide explains MTU concepts, shows how MTU is automatically discovered and maintained across tunnel layers, and provides troubleshooting steps for the few cases that still need manual attention.

Note

RansNet routers automatically discover the live path MTU for every IPsec, VXLAN, and GRE tunnel and keep TCP MSS clamps in sync with it — including across WAN failover, VRF reassignment, and PBR changes. There is no VPN MTU value to calculate or configure for these tunnel layers. See TCPMSS Clamp to PMTU and Configuration below for what this covers and what still requires manual attention (mainly WWAN modem MTU).

Overview¶

What is MTU?¶

MTU (Maximum Transmission Unit) is the largest IP packet size (in bytes) that can be transmitted on a network link without fragmentation. Standard Ethernet uses 1500 bytes MTU, but ISPs, mobile networks, and tunneling protocols may impose different limits.

Common MTU sizes:

Standard Ethernet: 1500 bytes
PPPoE links: 1492 bytes (reduced due to PPPoE overhead)
Mobile networks (WWAN): Auto-negotiated, often 1420–1500 bytes
Jumbo frames: 9000 bytes (datacenter networks)

Protocol Overhead¶

Each tunnel protocol's encapsulation reduces the usable MTU below the base WAN link's MTU. The router accounts for this automatically (see Configuration); the table below is background for understanding why, not a value to configure by hand.

Protocol	Typical Overhead	Illustrative Tunnel MTU*	Notes
WireGuard	~60 bytes	1420	Add 16 bytes if running over IPv6
IPSec	~60 bytes (textbook minimum)	1420	The router's own live calculation is typically more conservative — closer to ~140 bytes once NAT-T and worst-case padding are included, e.g. ~1358 on a 1500-byte WAN link — to leave headroom against PMTU black holes
SSL/TLS VPN	~20–50 bytes	1450–1480	Depends on cipher suite and certificate size
VXLAN	~50 bytes	1450	Adds VXLAN header + inner Ethernet header; layer 2 topologies stack additional overhead beneath it
GRE	~20 bytes	1470	Minimal overhead; often combined with other tunnels

* Illustrative figures assume a 1500-byte base WAN MTU. These are for understanding the order of magnitude of each protocol's overhead — the router computes the exact figure for your actual WAN MTU and cipher suite live, and re-computes it automatically if the active WAN link changes.

MTU in SD-WAN Tunnels¶

When you overlay multiple tunnel layers (VPN, VXLAN, IPSec, WireGuard, etc.), each layer adds protocol headers that reduce the effective MTU. For example, on a 1500-byte Ethernet WAN link with an IPsec tunnel:

Base WAN MTU: 1500 bytes
IPsec/ESP overhead (as computed live by the router): ~142 bytes (ESP header, NAT-T, worst-case padding, and integrity trailer)
Effective tunnel MTU: 1500 − 142 = 1358 bytes

Depending on the topology in use, there could be multiple tunnel overlays (e.g., VXLAN over IPSec, VXLAN over GRE over WireGuard). The corresponding tunnel MTU must be reduced to account for additional encapsulation overhead.

If packets larger than the effective tunnel MTU arrive, they either fragment (slowing throughput) or are dropped silently (causing connectivity issues). RansNet routers avoid this automatically: each tunnel layer discovers its own underlying path MTU live and derives its interface MTU and TCP MSS clamp from it, rather than relying on a fixed value you configure. See TCPMSS Clamp to PMTU below.

TCPMSS Clamp to PMTU¶

RansNet routers automatically maintain TCP Maximum Segment Size (MSS) clamping for every IPsec peer and every VXLAN/GRE overlay interface, adjusting the maximum data payload in TCP packets to match each tunnel's actual, currently-measured path MTU. This prevents fragmentation for TCP traffic without requiring manual MTU adjustments on any device.

How it works:

Discovers the live underlying path MTU for each IPsec peer (accounting for the active WAN link's MTU and IPsec/ESP overhead) and for each VXLAN/GRE overlay riding on it (accounting for the overlay's own encapsulation overhead)
Applies a matching TCP MSS clamp scoped to that specific peer, subnet pair, or overlay interface — not one blanket rule for all traffic
Re-evaluates and re-applies these values automatically whenever the underlying path changes: WAN failover between links with different MTUs (e.g., Ethernet to WWAN), VRF reassignment, or a PBR policy change that redirects a tunnel's egress path
Inspects TCP SYN/SYN-ACK packets during connection setup; application and OS layers automatically adapt to the clamped segment size
Works transparently — no configuration required, and no manual re-tuning needed after a failover

Limitations:

Applies only to TCP traffic, not UDP
Requires devices to support MSS clamping (most modern OSes do)
Cannot fix UDP-based protocols that ignore PMTU hints — see Best Practices for handling UDP/real-time traffic
The WWAN interface's own negotiated MTU (set by the carrier/modem) is outside this automation and may still need manual verification — see WWAN Interface MTU below

Configuration¶

Via mfusion Orchestrator¶

mfusion pushes VPN topologies (WireGuard, IPSec, SSL, VXLAN, GRE) with no MTU field to fill in — there is nothing to calculate or set. Once a tunnel is up, the router itself discovers the live underlying path MTU and derives every layer's interface MTU and TCP MSS clamp from it automatically.

What happens automatically after you push a topology:

The router determines the active WAN link's MTU (Ethernet, PPPoE, or WWAN — whichever is currently carrying the tunnel's traffic)
It computes the tunnel's usable MTU by subtracting that protocol's real encapsulation overhead (IPsec/ESP, WireGuard, VXLAN, or GRE — see Protocol Overhead for typical figures)
It applies that MTU to the tunnel interface and installs a matching TCP MSS clamp
For layered topologies (e.g., VXLAN over IPsec), each layer repeats this using the layer beneath it as its own "WAN," so the reduction cascades automatically
If the active WAN link changes (failover), or the tunnel is reassigned to a different VRF or redirected by a PBR policy, the router re-discovers the path and re-applies steps 2–3 without any action from you

No CLI configuration is required for this. See MTU Across Tunnel Topologies below for what the resulting per-layer values typically look like.

MTU Across Tunnel Topologies¶

The table below shows, for common RansNet topologies, which layer's MTU the router derives from which — for reference only, since these values are computed and applied automatically, not configured. Here, $mtu represents the live MTU the router discovers for the outer (WAN-facing) layer at any given moment, not a value you set — it changes on its own if the active WAN link changes.

Topology	Inner Layer 2	Inner Layer 1	Outer Layer
HS-WG-L3	—	—	`interface wgx` `mtu $mtu`
HS-IPSec-L3	—	—	`ipsec peer $peer` `mtu $mtu`
HS-SSL-L3	—	—	`security sslxxx`
HS-WG-L2	—	`interface vxlanx` `mtu ($mtu - 50)`	`interface wgx` `mtu $mtu`
HS-IPSec-L2	—	`interface vxlanx` `mtu ($mtu - 50)`	`ipsec peer $peer` `mtu $mtu`
HS-SSL-L2	—	—	`security sslxxx`
SS-WG-L3	—	`interface vxlanx` `mtu ($mtu - 50)`	`interface wgx` `mtu $mtu`
SS-IPSec-L3	—	`interface vxlanx` `mtu ($mtu - 50)`	`ipsec peer $peer` `mtu $mtu`
SS-SSL-L3	—	—	`security sslxxx`
SS-WG-L2	`interface vxlanx` `mtu ($mtu - 20 - 50)`	`interface gre1` `mtu ($mtu - 20)`	`interface wgx` `mtu $mtu`
SS-IPSec-L2	`interface vxlanx` `mtu ($mtu - 20 - 50)`	`interface gre1` `mtu ($mtu - 20)`	`ipsec peer $peer` `mtu $mtu`

Key observations:

$mtu = the live MTU the router discovers for the outer, WAN-facing layer — recomputed automatically, not configured
Layer 2 topologies (L2) reduce MTU at each inner layer to account for that layer's own encapsulation overhead, cascading down from whatever the outer layer currently measures
VXLAN interfaces reduce by ~50 bytes (VXLAN + inner Ethernet header)
GRE tunnels reduce by ~20 bytes
Every value in this table is re-derived automatically whenever the outer layer's own MTU changes (WAN failover, VRF/PBR change) — nothing here needs to be reapplied by hand

WWAN Interface MTU¶

Every other layer in the table above is derived automatically from whatever the WAN interface itself reports. The WWAN interface's own MTU is the one input to that chain the router doesn't control — it's negotiated by the carrier/modem — so it's worth checking directly if a tunnel's computed MTU looks lower than expected.

Check the WWAN interface's negotiated MTU:

show interface wwan0

If it shows a lower value than your carrier supports (e.g., 1420 instead of 1500), you can override it:

interface wwan0
 mtu 1500

To see the TCP MSS clamps the router currently has in place (one rule per IPsec peer, subnet pair, and overlay interface — not a single blanket rule):

show firewall set-list all

Example output for a router running an IPsec peer plus a VXLAN overlay on top of it:

Chain FORWARD (policy ACCEPT)
  TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS clamp to PMTU
  TCPMSS     tcp  --  *      *       0.0.0.0/0            203.0.113.10         tcp flags:0x06/0x02 TCPMSS set 1358
  TCPMSS     tcp  --  *      *       203.0.113.10         0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS set 1358
  TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS set 1308

The first line is the generic PMTU-clamp fallback; the two 1358 lines are the IPsec peer's own clamp (WAN MTU minus IPsec/ESP overhead); the 1308 line is the VXLAN overlay's own clamp (the IPsec-adjusted value minus VXLAN overhead). All three update automatically if the underlying path changes.

Verification¶

Verify that MTU has been correctly discovered and is functioning across all tunnel layers.

Items to Test	Command	Expected Outcome
WWAN interface MTU	`show interface wwan0`	MTU field shows 1500 (or value appropriate for your carrier)
IPsec peer MTU	`show ipsec status`	Peer shows `ESTABLISHED`; Tx/Rx counters increase once traffic flows, confirming packets aren't being silently dropped
VXLAN/GRE overlay MTU	`show interface vxlan1` (or `gre1`)	MTU shows the underlying tunnel's MTU minus that overlay's own overhead — see MTU Across Tunnel Topologies
TCP MSS clamping	`show firewall set-list all`	FORWARD chain shows a `TCPMSS` rule per active IPsec peer and overlay interface, in addition to the generic `TCPMSS clamp to PMTU` fallback
Path MTU discovery	`ping -M do -s 1472 <remote-host>`	Packets succeed without fragmentation (MTU 1500 − IP header 20 − ICMP 8 = 1472 max payload); lower the `-s` value to match a tunnel's own reduced MTU when testing through it
MTU survives a WAN failover	Trigger a failover, then repeat the `show interface`/`show firewall set-list all` checks above	Values update automatically to match the new active WAN link within a few seconds — no manual reconfiguration needed

Troubleshooting¶

Symptom	Likely Cause	Solution
WWAN interface shows lower MTU than expected	Carrier or mobile network auto-negotiated a smaller MTU	Check with `show interface wwan0`. If your carrier confirms 1500 is supported, manually configure `interface wwan0 mtu 1500`. Every dependent tunnel/overlay MTU value recalculates automatically once the WWAN MTU changes.
Tunnel connectivity drops or stalls right after a WAN failover	The new path's MTU is still being (re-)discovered, or the WWAN link itself is reporting an incorrect MTU	Wait a few seconds and recheck `show ipsec status` / `show firewall set-list all` — values should settle automatically. If they don't, verify the WWAN interface's own MTU first, since every other layer derives from it.
TCP connections work but UDP services fail	UDP traffic exceeds the tunnel's effective MTU; MSS clamping only applies to TCP	Reduce the application's own packet/payload size (buffer settings, codec quality), or use a TCP-based alternative if available. See MTU and Performance.
Large file transfers slow or timeout	Excessive fragmentation causing retransmission overhead, often from a WWAN link with a smaller-than-assumed negotiated MTU	Confirm the WWAN interface's actual MTU with `show interface wwan0`. Confirm the expected per-layer TCPMSS rules are present with `show firewall set-list all` — if a rule is missing or shows an unexpectedly large value, check `show ipsec status` to confirm the affected peer is `ESTABLISHED` and not stuck negotiating.
A TCPMSS rule shows a value that seems too large or too small	The underlying path MTU it was computed from doesn't match what you'd expect for the active WAN link	Confirm which WAN interface the tunnel is actually using right now (`show ip route`, or `show ipsec status` for the peer's local address) — an active PBR policy or a recent failover may have moved it to a link with a different MTU than the one you were expecting.

Best Practices¶

MTU Planning¶

Trust the automation for tunnel layers — IPsec, VXLAN, and GRE MTU/TCPMSS values are discovered and maintained automatically; don't hand-configure them, and don't assume a static value will survive a WAN failover
Get the WWAN MTU right first — every dependent tunnel/overlay layer derives its own MTU from the WAN interface beneath it, so confirm show interface wwan0 reports the value your carrier actually supports
Account for PPPoE — a PPPoE WAN link reduces the base Ethernet MTU to 1492, which the automation accounts for automatically, the same as any other WAN MTU
Test before relying on a new topology — use ping -M do to verify MTU along the full path once a tunnel is up, and repeat it after a deliberate WAN failover test

MTU and Performance¶

TCP benefits most from MSS clamping — automatic MSS adjustment works well for TCP and HTTP/HTTPS traffic with no configuration needed, and re-adjusts on its own after a failover
UDP and real-time traffic — monitor UDP-based services (DNS, SIP, gaming, video streaming), since MSS clamping doesn't help them. If packets exceed the tunnel's MTU, consider:
Reducing application packet size (buffer settings, codec quality)
Using a TCP-based alternative if available
Confirming the WAN link isn't unnecessarily constrained (e.g., a WWAN interface auto-negotiated below what the carrier actually supports)
Multi-layer topologies — L2 tunnels with multiple encapsulation layers have more combined overhead, so their resulting MTU is naturally smaller. This is computed correctly by the automation; it isn't something to plan around manually

Security and MTU¶

Encrypted tunnels add overhead — IPsec typically reduces usable MTU by roughly 140 bytes once ESP, NAT-T, and padding are accounted for; the router computes the exact figure live rather than using a fixed estimate
Firewall rules and MSS clamping — ensure firewall rules do not disable or interfere with TCPMSS processing. Verify with show firewall set-list all

Example: MTU Verification on WAN Interface¶

Below is example output from show interface wwan0 showing WWAN link MTU:

HSA-520# show interface wwan0
================================================================================
  Interface : wwan0
================================================================================

  Network Information
  ----------------------------------------
  Admin State            : UP
  Link State             : UP
  MTU                    : 1500 bytes
  IPv4 Address           : 10.157.176.183/28
  IPv4 Broadcast         : 10.157.176.191

  Mobile Connection
  ----------------------------------------
  Modem IMEI             : 869814061357111
  Provider               : Zero1
  Network                : LTE
  RSSI                   : -65 dBm (excellent)

  Physical Information
  ----------------------------------------
  Link Detected          : yes

================================================================================
HSA-520#

The MTU: 1500 bytes line confirms the interface supports standard 1500-byte packets. If this shows a lower value (e.g., 1420), and your WAN provider supports 1500, manually adjust with

interface wwan0
 mtu 1500