Reason for Decreased MTU from 1420 to 1320

[reversevpn 9]

Why is the MTU on files generated from AirVPN's config generator just 1320 instead of the normal 1420 for Wireguard? Not saying that this is a bad thing, but just curious.

[Staff 10448]

On 1/30/2026 at 11:16 PM, reversevpn said:

Why is the MTU on files generated from AirVPN's config generator just 1320 instead of the normal 1420 for Wireguard? Not saying that this is a bad thing, but just curious.

Hello!

It's a compromise to avoid fragmentation on most networks.
https://blog.silvio.cloud/2_WireGuard_and_MTU_MSS
 

Quote

 

WireGuard's encapsulation adds overhead to packets. If the resulting packet size exceeds the MTU of any link (including the tunnel itself), fragmentation occurs. This can cause:

• Reduced performance: Fragmentation and reassembly add processing overhead.
• Increased packet loss: Fragmented packets are more likely to be lost.

 

You may test different MTU to find the optimal value for your network (the one that can provide you with the best performance).

Kind regards

 

[reversevpn 9]

But if I select a bigger MTU than what you have server-side, won't the effective MTU of the applications running in the tunnel still be constrained to the server MTU?

[Staff 10448]

6 hours ago, reversevpn said:

But if I select a bigger MTU than what you have server-side, won't the effective MTU of the applications running in the tunnel still be constrained to the server MTU?

Hello!

Yes. Server side it is 1420 bytes, so this is your upper limit too. Thus you can test up to 1420 bytes to find the MTU that can provide you with the best performance. 

Kind regards
 

[Tommie 8]

Related to this, when selecting Wireguard in Eddie, is the MSS set to 1320 by default? If not is it recommended to add it to OVPN directives?

[Staff 10448]

On 1/31/2026 at 11:45 PM, Tommie said:

Related to this, when selecting Wireguard in Eddie, is the MSS set to 1320 by default? If not is it recommended to add it to OVPN directives?

Hello!

No need for MSS clamping when using WireGuard, just modify the MTU if necessary. Since MSS clamping 1. becomes necessary only when you can't modify MTU, 2. needs packet mangling (WireGuard does not expose any option for it) and 3. requires anyway a server side modification, just operate through MTU. (*)

In OpenVPN (only when working over UDP), where networking management is a bit different, you can seriously consider the mssfix directive if you have any "fragmentation" problem that causes packet loss and poor performance. mssfix announces to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. See also OpenVPN manual: https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html

In Eddie you can add custom directives for OpenVPN in "Preferences" > "OVPN Directives" window.

(*) EDIT: there is a special case where MSS clamping becomes necessary with WireGuard too, although it is a consequence of bad PMTUD handling. If an intermediate link doesn’t correctly handle PMTUD (Path MTU Discovery), TCP packets larger than the tunnel MTU may be dropped, and the client will observe hanging connections or stalled downloads, possibly only for certain destination. In this case MSS clamping helps for sure.

Kind regards
 

[Wolf666 17]

Hello,
just to share my experience, I am on PPPoE, MTU 1492 since my ISP doesn't support baby jumbo frames. I have 4 WG tunnels managed by my pfSense appliance. WG interfaces have MTU 1432 (only ipv4 traffic) and I don't see any fragmentation when I ping test from those WG interface. I had in the past MTU 1412 but recently I wanted to test exactly the MTU before fragmatation accurs and that value is 1432.

[Staff 10448]

the effective MTU of the tunnel is limited by the smallest MTU anywhere along the path

11 minutes ago, Wolf666 said:

WG interfaces have MTU 1432 (only ipv4 traffic) and I don't see any fragmentation when I ping test from those WG interface.

Hello!

On our servers the MTU limit is 1420 bytes on a standard Ethernet frame because of IPv6 over IPv4. For PPPoE see also https://www.hitoha.moe/wireguard-mtu-over-pppoe/ 

So, if you set 1432 bytes MTU for your WireGuard interface, the fragmentation will occur on our servers, not on your side. The upper, actual limit is the lowest MTU in the path, in other words the smallest MTU on the path silently limits the tunnel. The 12 bytes difference may be negligible and most packets will not be fragmented, and you will not see fragmentation on your side, but you could notice a performance hit on upload (upload from you to the server we mean).

Kind regards
 

[Wolf666 17]

Hello Staff,
thank you for heads up! I will revert to MTU 1420.
Regards