Opened 7 years ago

Last modified 3 years ago

#930 new Bug / Defect

Inconsistent tun-mtu calculated between client and server

Reported by: toine512 Owned by:
Priority: major Milestone: release 2.5.3
Component: Networking Version: OpenVPN 2.4.3 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: tun-mtu, Windows
Cc: plaisthos

Description

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.

Attachments (4)

client.ovpn (532 bytes) - added by toine512 7 years ago.
client.log (6.7 KB) - added by toine512 7 years ago.
set-mtu.bat (247 bytes) - added by toine512 7 years ago.
server.ovpn (553 bytes) - added by toine512 7 years ago.

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by toine512

Attachment: client.ovpn added

Changed 7 years ago by toine512

Attachment: client.log added

Changed 7 years ago by toine512

Attachment: set-mtu.bat added

Changed 7 years ago by toine512

Attachment: server.ovpn added

comment:1 Changed 7 years ago by toine512

Seems related to #926 and might be related to #911.

Version 0, edited 7 years ago by toine512 (next)

comment:2 Changed 7 years ago by 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?

Last edited 7 years ago by toine512 (previous) (diff)

comment:3 Changed 7 years ago by tct

CC

comment:4 in reply to:  2 Changed 7 years ago by toine512

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

comment:5 Changed 3 years ago by Gert Döring

Cc: plaisthos added
Milestone: release 2.4.4release 2.5.3
Summary: Inconsistent tun-mtu passed to up script on WindowsInconsistent tun-mtu calculated between client and server

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.

Note: See TracTickets for help on using tickets.