Invalid tun MTU if link-mtu is in use

[vmspike]

When trying to use link-mtu option instead of mssfix on both client and server sides it leads to MTU problems because tun adapter mtu is higher than should be.
I use dual tcp+udp openvpn server but it doesn't matter, let's consider udp (default) one. You can see configs and client log in attachment.
On server side udp log I can see:

WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1298)
Control Channel MTU parms [ L:1420 D:1172 EF:78 EB:0 ET:0 EL:3 ]

and corresponding MTU value for udp tun0 adapter:

6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1298 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 172.16.16.1/24 brd 172.16.16.255 scope global tun0
       valid_lft forever preferred_lft forever
7: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1296 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 172.16.16.1/24 brd 172.16.16.255 scope global tun1
       valid_lft forever preferred_lft forever

While on client side tun adapter mtu is different with server (1295 vs 1298, which is also weird for me) one and different from the value shown in log:

OPTIONS IMPORT: WARNING: peer-id set, but link-mtu fixed by config - reducing tun-mtu to 1295, expect MTU problems
/sbin/ip link set dev tun0 up mtu 1367

tun0 adapter has corresponding value:

5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1367 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 172.16.16.2/24 brd 172.16.16.255 scope global tun0
       valid_lft forever preferred_lft forever

After this I cannot reach some sites (like beta.speedtest.net) because of MTU problems. When I manually changed (after connection via: ip link set dev tun0 mtu 1295) tun0 MTU to the one have seen in log MTU issue fixed and I can reach the site.

I imagine that openvpn should set tun adapter mtu to the one shown in log WARNING message (if it has rights - I've not drop privileges because of dual tcp/udp config).
Also can you please tell me why client and server tun-mtu value differs (1295 on client, 1298 on server) while openvpn version (2.4.3) and OS type (Ubuntu Xenial) are the same?

[Gert Döring]

+3 bytes hints at the correction needed to support peer-id - and the difference might be due to initialization sequence, like, the client adjusting the MTU value *if* peer-id is set, while the server doesn't adjust it as peer-id is a per-client thing and not a global one.

In general, use of --mssfix is considered more robust than trying to get cross-platform interface MTU right - nevertheless, on those platforms where we can set the interface MTU, it should better work.

[vmspike]

I know about openvpn developers recommendation to use mssfix instead of tun-mtu/link-mtu specifically for cross-platform setup (Windows TAP driver still can't change MTU on the fly, have to change in adapter settings, right?).
Both ways has their own advantages and disadvantages. Here I report about incorrect tun adapter mtu setup if link-mtu is set on linux, and log entries and real behavior mismatch.
OpenVPN process has all rights to set/change it but it use higher value than required for stable work (proper value shown in log).

[tct]

CC