Skip to main content

MikroTik WireGuard VPN MTU & MSS Calculator

Deploy site-to-site WireGuard VPN on RouterOS v7 with automatic TCP MSS Clamping to prevent tunnel web page freezes and PMTUD black holes.

Input Parameters

Try Example:

Calculation Results

linkType
pppoe
mtu
1480
ipVersion
ipv4
ipHeaderBytes
20
tcpHeaderBytes
20
icmpHeaderBytes
8
tcpMss
1440
pingDfPayload
1452
overheadBytes
20
overheadDesc
PPPoE Standar ISP Fiber / DSL (8–20 Byte Header)
windowsPingCmd
ping 1.1.1.1 -f -l 1452
linuxPingCmd
ping -M do -s 1452 1.1.1.1
macosPingCmd
ping -D -s 1452 1.1.1.1
wanIface
pppoe-out1
wgPort
13231
wgNet
10.200.200.1/24
peerIp
10.200.200.2/32
remoteLan
192.168.90.0/24
RouterOS Script
# =====================================================================
# InfraCalc.id - MikroTik RouterOS v7 MTU/TCP MSS Clamping & WireGuard VPN
# Jenis Link: PPPOE | MTU Optimal: 1480 | TCP MSS: 1440
# =====================================================================

# 1. Perbaikan Website Sering Loading Lama / Gagal Buka di PPPoE & VPN (TCP MSS Clamping)
/ip firewall mangle
add action=change-mss chain=forward in-interface=pppoe-out1 new-mss=1440 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1441-65535 comment="Clamp TCP MSS Inbound (pppoe-out1 -> 1440)"
add action=change-mss chain=forward out-interface=pppoe-out1 new-mss=1440 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1441-65535 comment="Clamp TCP MSS Outbound (pppoe-out1 -> 1440)"
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn comment="Auto Clamp PMTU All Tunnels"

# 2. Setup Interface WireGuard VPN (RouterOS v7 Native)
/interface wireguard
add listen-port=13231 mtu=1420 name=wg-infracalc comment="WireGuard VPN Site-to-Site / Remote"

/ip address
add address=10.200.200.1/24 interface=wg-infracalc comment="IP Gateway Tunnel WireGuard"

/interface wireguard peers
# Ganti PUBLIC_KEY_CABANG dengan Public Key dari router cabang / client
add allowed-address=10.200.200.2/32,192.168.90.0/24 interface=wg-infracalc public-key="ISI_PUBLIC_KEY_PEER_DISINI=" persistent-keepalive=25s comment="Peer Cabang / Remote Admin"

/ip firewall filter
add action=accept chain=input dst-port=13231 protocol=udp place-before=0 comment="Allow WireGuard Handshake UDP 13231"

/ip route
add dst-address=192.168.90.0/24 gateway=wg-infracalc comment="Route ke LAN Cabang via WireGuard"

# Cara Test Fragmentasi Paket dari CMD Windows: ping 1.1.1.1 -f -l 1452

How to Use This Tool

  1. Select your underlying WAN connection type (PPPoE 1480, Ethernet 1500, or LTE 1428) and specify your WAN interface name.
  2. Specify your WireGuard UDP listen port (default 13231), local tunnel gateway IP, remote peer IP, and remote branch LAN subnet CIDR.
  3. Review the comprehensive RouterOS v7 script featuring TCP MSS Clamping, WireGuard interface setup, UDP handshake firewall rules, and static route generation, then copy it to your terminal.

Worked Example: PPPoE Fiber WAN (MTU 1480 → WireGuard 1420)

Computed example: An underlying PPPOE WAN link (MTU 1480) with TCP MSS 1440. Configures a WireGuard interface on UDP port 13231 with tunnel IP 10.200.200.1/24, peer 10.200.200.2/32, and static route to remote LAN 192.168.90.0/24 alongside automated MSS Clamping.

Example Input
{
  "linkType": "pppoe",
  "wanIface": "pppoe-out1",
  "wgPort": 13231,
  "wgNet": "10.200.200.1/24",
  "peerIp": "10.200.200.2/32",
  "remoteLan": "192.168.90.0/24"
}
Calculated Output
linkType:
pppoe
mtu:
1480
ipVersion:
ipv4
ipHeaderBytes:
20
tcpHeaderBytes:
20
icmpHeaderBytes:
8
tcpMss:
1440
pingDfPayload:
1452
overheadBytes:
20
overheadDesc:
PPPoE Standar ISP Fiber / DSL (8–20 Byte Header)
windowsPingCmd:
ping 1.1.1.1 -f -l 1452
linuxPingCmd:
ping -M do -s 1452 1.1.1.1
macosPingCmd:
ping -D -s 1452 1.1.1.1
wanIface:
pppoe-out1
wgPort:
13231
wgNet:
10.200.200.1/24
peerIp:
10.200.200.2/32
remoteLan:
192.168.90.0/24

Core Concept & Engineering Notes

WireGuard is a state-of-the-art, high-performance VPN protocol implemented natively in MikroTik RouterOS v7. Because WireGuard encapsulates IP datagrams inside UDP packets, it introduces unavoidable overhead: 20 to 40 bytes for the outer IP header, 8 bytes for the outer UDP header, 16 bytes for the WireGuard transport header, and a 16-byte Poly1305 authentication tag (totaling 60 to 80 bytes of crypto overhead). Consequently, WireGuard interfaces running over standard IPv4 networks default to an optimal MTU of 1420 bytes rather than 1500 bytes. The primary operational obstacle encountered in site-to-site WireGuard deployments is the sudden stall or freeze of large TLS handshakes, HTTPS portal logins, or SMB file transfers between office locations. This occurs because internal workstations on 1500-byte Ethernet segments send maximum-sized packets with the Don't Fragment (DF) bit set into the 1420-byte WireGuard tunnel. If Path MTU Discovery is broken by upstream firewalls discarding ICMP 'Fragmentation Needed' packets, intermediate routers silently drop the frames, generating a debilitating PMTUD black hole. This calculator generates an end-to-end RouterOS v7 deployment script that resolves MTU negotiation errors permanently. In addition to creating the WireGuard interface, tunnel IP addressing, peer configuration, and static routing to remote branch subnets, it embeds active TCP MSS Clamping rules on both the WAN and tunnel interfaces. Clamping MSS during the TCP SYN handshake forces endpoints to negotiate segment sizes that fit seamlessly into the encapsulation envelope without packet fragmentation.

How It Was Calculated (Formulas & Steps)

Frequently Asked Questions (FAQ)

Why is the default WireGuard MTU 1420 bytes in RouterOS v7?

Standard Ethernet supports a 1500-byte MTU. WireGuard encapsulation adds up to 80 bytes of overhead (20/40-byte outer IP, 8-byte UDP, 32-byte WireGuard header & Poly1305 MAC). Subtracting 80 from 1500 yields 1420 bytes, guaranteeing zero fragmentation even over IPv6 backbones.

What is the difference between setting a specific `new-mss=1440` versus `new-mss=clamp-to-pmtu`?

Setting an explicit numeric MSS (e.g. 1440 on PPPoE) hardcodes a safe ceiling for traffic crossing that specific interface. The `clamp-to-pmtu` parameter dynamically derives the MSS from the router's egress interface MTU, acting as an optimal universal fallback.

Why is persistent-keepalive=25s essential for WireGuard peers?

When a branch peer is behind an ISP NAT or carrier CGNAT, upstream stateful firewalls flush inactive UDP mappings after 30 seconds. A 25-second keepalive sends a periodic ping to keep the NAT port binding alive, allowing the central office to initiate contact at any time.

References & Notes

Last updated: Content Status: Draft (Pending Editorial Review)

Note: Results above are mathematical estimates based on standard formulas. Always verify against official vendor documentation and site conditions before production deployment.