Skip to content

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 cascades through tunnel layers, and provides troubleshooting steps.

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

When setting the VPN MTU in mfusion, account for the tunnel protocol's encapsulation overhead. The VPN MTU should be lower than the base Ethernet MTU to accommodate protocol headers.

Protocol Typical Overhead Recommended VPN MTU* Notes
WireGuard ~60 bytes 1420 Add 16 bytes if running over IPv6
IPSec ~60 bytes 1420 Varies with encryption algorithm; includes ESP header + IV
SSL/TLS VPN ~20–50 bytes 1450–1480 Depends on cipher suite and certificate size
VXLAN ~50 bytes 1450 Adds VXLAN header; layer 2 topologies have additional overhead
GRE ~20 bytes 1470 Minimal overhead; often combined with other tunnels

* Recommended VPN MTU assumes base Ethernet MTU of 1500 bytes and accounts for total encapsulation overhead including protocol headers and packet framing. Adjust for your ISP/WAN MTU.

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:

  • Base WAN MTU: 1500 bytes
  • IPSec tunnel overhead: ~60 bytes (encryption, headers)
  • Effective tunnel MTU: 1500 − 80 = 1420 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).

TCPMSS Clamp to PMTU

RansNet routers automatically enable TCP Maximum Segment Size (MSS) clamping, which adjusts the maximum data payload in TCP packets to match the path MTU. This prevents fragmentation for TCP traffic without requiring manual MTU adjustments on all devices.

How it works:

  • Inspects TCP SYN packets during connection setup
  • Reduces MSS to account for tunnel overhead
  • Application and OS layers automatically adapt to smaller segment sizes
  • Works transparently without configuration

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

Due to the complexity and default setting limitations, you may still need to tune MTU settings to adapt to actual situations.

Configuration

Via mfusion Orchestrator

mfusion provides a VPN MTU setting that automatically configures MTU values across all tunnel layers based on the topology and protocol in use. The VPN MTU should be reduced by the protocol overhead, not set to the base Ethernet MTU.

Steps:

  1. Identify the tunnel protocol (WireGuard, IPSec, SSL, etc.) from your VPN topology
  2. Check the protocol overhead table above
  3. Calculate VPN MTU = Base Ethernet MTU − Protocol Overhead (e.g., 1500 − 80 = 1420 for IPSec)
  4. Navigate to SD-WAN → VPN Instance
  5. Set the MTU field to the calculated value (e.g., 1420 for IPSec)
  6. Apply configuration — mfusion automatically adjusts per-layer MTU values based on the topology

MTU Across Tunnel Topologies

When configuring VPN tunnels via mfusion orchestrator, the MTU value cascades through tunnel layers, and mfusion automatically pushes the corresponding CLI configuration to each tunnel. No manual configuration is required.

For reference, the table below shows how MTU changes at each layer for common RansNet topologies ($mtu = MTU value set in mfusion VPN settings):

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 - 60)		 interface wgx
mtu $mtu
HS-IPSec-L2 — interface vxlanx
mtu ($mtu - 60)		 ipsec peer $peer
mtu $mtu
HS-SSL-L2 — — security sslxxx
SS-WG-L3 — interface vxlanx
mtu ($mtu - 60)		 interface wgx
mtu $mtu
SS-IPSec-L3 — interface vxlanx
mtu ($mtu - 60)		 ipsec peer $peer
mtu $mtu
SS-SSL-L3 — — security sslxxx
SS-WG-L2 interface vxlanx
mtu ($mtu - 30 - 60)		 interface gre1
mtu ($mtu - 30)		 interface wgx
mtu $mtu
SS-IPSec-L2 interface vxlanx
mtu ($mtu - 30 - 60)		 interface gre1
mtu ($mtu - 30)		 ipsec peer $peer
mtu $mtu

Key observations:

  • $mtu = MTU value configured in mfusion VPN settings
  • Layer 2 topologies (L2) reduce MTU at each inner layer to account for encapsulation overhead
  • VXLANx interfaces reduce by 60 bytes (typical VXLAN encapsulation)
  • GRE tunnels reduce by 30 bytes
  • Outer layer (WireGuard, IPSec) uses the configured $mtu value directly

Manual CLI Configuration

For specific interfaces or to override mfusion settings:

Adjust WWAN interface MTU (if auto-negotiated to a lower value):

interface wwan0
 mtu 1500

Verify TCPMSS clamp is enabled (should show by default):

show firewall set-list all

Expected output shows TCP traffic clamped to PMTU: 

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

Verification

Verify that MTU is correctly configured and 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 ISP)
VXLAN tunnel MTU show interface vxlan1 MTU shows expected value accounting for layer overhead
WireGuard tunnel MTU show interface wg1 MTU matches mfusion VPN setting minus encapsulation overhead
TCP MSS clamping show firewall set-list all FORWARD chain shows TCPMSS clamp to PMTU rule
Path MTU discovery ping -M do -s 1472 <remote-host> Packets succeed without fragmentation (MTU 1500 - IP header 20 - ICMP 8 = 1472 max payload)

Troubleshooting

Symptom Likely Cause Solution
Tunnel connectivity drops intermittently MTU mismatch causing silent packet drops; fragmentation not handled Verify mfusion VPN MTU matches WAN link MTU. Check show interface wwan0 for auto-negotiated MTU. If lower than expected, manually set to 1500.
TCP connections work but UDP services fail UDP traffic exceeds effective tunnel MTU; no MSS clamping on UDP TCP MSS clamping cannot help UDP. Use mfusion VPN MTU setting to reduce packet size for all protocols. Monitor UDP application behavior.
Large file transfers slow or timeout Excessive fragmentation causing retransmission overhead Verify TCPMSS clamping is enabled (show firewall set-list all). Check MTU values across all tunnel layers match configuration table. Reduce packet size on client applications if needed.
WWAN interface shows lower MTU than expected ISP or mobile network auto-negotiated smaller MTU Check WWAN modem capability with show interface wwan0. If actual network supports 1500, manually configure interface wwan0 mtu 1500. Verify with ISP that 1500 is supported.
VPN tunnel shows DOWN after MTU change Configuration was not properly applied; tunnel overhead not accounted for Verify mfusion configuration was saved and applied. Check CLI tunnel configuration matches table (e.g., IPSec peer MTU = mfusion setting, VXLAN MTU = mfusion setting - 60). Reapply mfusion config.

Best Practices

MTU Planning

  • Start with 1500 — Use 1500 bytes MTU as the baseline for standard Ethernet links
  • Account for PPPoE — Reduce to 1492 if using PPPoE WAN links
  • Test before deploying — Use ping -M do to verify MTU along the entire path before rolling out production tunnels
  • Document topology MTU — Record the effective MTU for each tunnel layer in your topology for future troubleshooting

MTU and Performance

  • TCP benefits most from MSS clamping — Automatic MSS adjustment works well for TCP and HTTP/HTTPS traffic with no configuration needed

  • UDP and real-time traffic — Monitor UDP-based services (DNS, SIP, gaming, video streaming). If packets exceed tunnel MTU, consider:

  • Reducing application packet size (buffer settings, codec quality)

  • Increasing mfusion VPN MTU if the WAN link supports jumbo frames (9000 bytes)

  • Using TCP-based alternatives if available

  • Multi-layer topologies — L2 tunnels with multiple encapsulation layers have larger overhead. Allocate sufficient MTU (typically 1400–1500 minimum) to avoid frequent fragmentation

Security and MTU

  • Encrypted tunnels add overhead — IPSec adds ~60 bytes, WireGuard ~60 bytes. Reduce MTU accordingly or ensure WAN MTU is large enough
  • 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