OpenVPN Support Forum

For about 15 years, probably more, I am now running openVPN, but I never figured how these --tun-mtu, --link-mtu, --mssfix etc.etc. are actually meant to work. I could read the documentation, and web resources, a dozen times, and not get a real clue.

So yesterday, in the process of doing more IPv6 (where headers are a different size and what currently works does no longer) I gave it a real hard sitdown and experiment, and finally figured it out:

The answer is 61 (no, not 42).

61 is the only information one needs, and it is the only information that is nowhere documented. It is the encapsulation overhead bytes, so from this you can calculate everything else - and specifically and most important, the MTU for the next-inner nested tunnel.(*)

The 61 is likely configuration-dependent, but then also it is obtainable only deeply hidden in the debug output, if you already know what to look for and how the things do interplay.

(*) Fragmentation is not a solution, because fragmentation does not really work in IPv6, because firewalls usually cannot process it, because inflight de/refragmentation is shunned in IPv6 (for reasons I have not yet figured out).

PMc wrote: ↑

Sat Jun 18, 2022 11:45 pm

I never figured how these --tun-mtu, --link-mtu, --mssfix etc.etc. are actually meant to work.

Nobody knows for sure .. we live in hope.

Me too, for many years.
Actually. I had this in the first tunnel (1500 - 8 PPPoE - 20 hdr - 8 udp)
and this in the next-inner tunnels: But with IP6 the math for outer tunnel is 1500 - 20 gif - 40 hdr - 8 udp, and the next-inner will then also get smaller, and hit the minimum requirement of 1280. So it was not an option anymore.