Finally found the magic 61

PMc

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).

TinCanTech

PMc wrote 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.

PMc

Me too, for many years.
Actually. I had this in the first tunnel

link-mtu 1464
mssfix 1464

(1500 - 8 PPPoE - 20 hdr - 8 udp)
and this in the next-inner tunnels:

mssfix 1375
tun-mtu 1280

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.