Inconsistent tun-mtu calculated between client and server

[toine512]

I have a Linux server (QNAP NAS) and a Windows 10 client both running OpenVPN 2.4.3 with subnet topology. The server is connected via fiber and the cilent via ADSL (PPP). Link MTU is 1492 bytes.

Therefore I set link-mtu to 1464. Then a value of tun-mtu is calculated by OpenVPN and applied to the tun interface on Linux while this needs to be done manually on Windows. I wrote an up script that sets the MTU associated with TAP-Windows interface.

On Linux (server), tun-mtu set with ifconfig and passed to the up script (I checked) is the same : 1342.
On Windows (client) two values coexist:

Sat Aug 26 19:14:37 2017 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1342)

here computed tun-mtu appears to be 1342 (same value applied by OpenVPN on server side)
while 1411 (second argument) is passed to the up script:

Sat Aug 26 19:14:39 2017 set-mtu.bat OpenVPN 1411 1464 10.31.0.2 255.255.255.0 init

However by ping testing from the client with no MTU constraints on TAP-Windows (MTU=1500) and "do not fragment" flag set, 1411 seems to be the right working limit: request goes through the tunnel and response comes back properly fragmented.

[toine512]

Might be related to #926.

[toine512]

Further investigation shows that ​extra_frame size allocated in the packet structure differs:

• Server (Linux)

  Data Channel MTU parms [ L:1464 D:1450 EF:122 EB:380 ET:0 EL:3 ]
  

tun_mtu = link_mtu - (extra_frame + extra_tun) = 1464 - 122 - 0 = 1342

• Client (Windows)

  Data Channel MTU parms [ L:1464 D:1450 EF:53 EB:380 ET:0 EL:3 ]
  

1464 - 53 - 0 = 1411

Looking at frame_add_to_extra_frame() calls, I believe the only part in the source where the value added to extra_frame isn't derived from a fixed-size integer size is in crypto.c: ​https://github.com/OpenVPN/openvpn/blob/4a05f15c9aafe314ae4d3642813ebf234c09276e/src/openvpn/crypto.c#L727

Are the crypto functions used to calculate "crypto_overhead" OS or client/server dependent?

[tct]

CC

[toine512]

Title should be changed to "Inconsistent calculated tun-mtu values on Windows" as it is not a cosmetic defect.

[Gert Döring]

Actually, this is not an "on Windows" problem but client/server tend to disagree on MTU values if NCP gets involved.

This is still not perfect in 2.5 or master, but is a known issue.

To work around this, scenarios where a smaller-than-1500 MTU is desired and should be consistent, using --tun-mtu 1400 (or such) should yield proper results.

I'm bumping the milestone on this to 2.5.3 as it's still not fixed.