Wireguard MTU Size - derivation

Hi …

I’m trying to arrive at an optimal MTU size for a Wireguard tunnel I have running, over a 4G CGNAT connection, from Spain (RUTX50) to my fibre linked house in the UK (tp-link Omada ER605). The technique I have so far used is:

  1. From a Windows PC, attached to the RUTX50 with Wireguard DISABLED - used ping 8.8.8.8 -f -l [packet size] to determine the largest packet sized allowed through without returning a ‘fragmentation’ response.

  2. The largest packet size discovered was 1402 bytes and to this, I added 28 bytes, which is the ping overhead when performed from a Windows PC. This gives me an MTU size of 1430.

My questions are …

Is it the 1430 figure that I insert into the Wireguard Interface > Advance Settings > MTU Size field, or do I have to subtract the Wireguard IPv4 overhead of 60 bytes, to give an MTU size of 1370?

Is my assumption of 60 bytes overhead, for a Wireguard IPv4 tunnel, correct?

Is all or any of the above, nonsense that I’ve constructed in my head?

All advice welcome … Mike

Hello,
You need to subtract 80 bytes not 60 from the MTU you have “discovered”. And unfortunately the end value will still depend on how the mobile operator has configured his network (with IPv6 nodes in the path and so on). Of course the configuration may change over time…
I have given up trying to use MTU values above 1280 bytes for wireguard interfaces.
Regards.

Thanks for a quick reply … my current tunnel is set to 1280, so I’ll set up a second one with an MTU size of 1430 - 80 = 1350 and compare the difference.

As the 1280 tunnel still gets dropouts, I was wondering if there were issues with the MTU size.

We’re in the mountains in Spain and the throughput degrades as we get further into night-time. I guess atmospherics are playing a large part in this. Hence me going off on this MTU path.

Thank you … Mike

One way to test this is to have identical http and https servers (same large enough pages).
If it works with http but fails with https then you still have a MTU issue.
Do you use carrier aggregation ? If so, do you have the same MTU on each carrier ? Check with:

gsmctl -A 'AT+QMTUINFO'

AT command result is …

+QMTUINFO: 1,1430,-
+QMTUINFO: 2,1500,1500-

Not that I fully understand what I’m looking at … thx, Mike

This command gives the MTU of the different sub-carriers.
Carrier 1: MTU IPv4 = 1430 bytes, no IPv6
Carrier 2: both IPv4 and IPv6 have a 1500 bytes MTU.
This gives an absolute maximum of 1430 - 80 bytes for the wg MTU. Unfortunately the command doesn’t tell if there is smaller values inside the network.

Thank you, I haven’t touched the AT command set since the 1990’s.

By understanding the return from the AT command, I now have a starting point to work down from.

I’ll get around to finding a couple of web pages for http & https to add to a test case.

Cheers … Mike

This topic was automatically closed after 15 days. New replies are no longer allowed.