GNOME Bugzilla – Bug 584200
support additional options (using custom mtu, mss)
Last modified: 2020-11-12 14:32:14 UTC
Please describe the problem: NetworkManager VPNC plugin currently doesn't support arbitrarily setting a MTU (or MSS value) for the VPN connection, although one can be set for an Wired or Wireless interface. Steps to reproduce: 1. connect to a VPN while on an interface that requires an MTU < 1500. Actual results: Packets are blocked, VPN doesn't work. Expected results: A working VPN connection. Does this happen every time? Yes Other information: A workaround exists: the MTU can be then manually set on the tun interface created by vpnc.
This also appears to affect the OpenVPN and PPTP plugins. Additionally, it seems to me (from looking at the code in the Cisco VPN client for linux), that they are setting the MTU to an arbirary value too, although it is substancially lower, more around 1300, than the current 1412. This is done to support all the different levels of encapsulation of packets; so IP, UDP and ESP headers and the like.
from ./src/nm-vpnc-service-vpnc-helper.c: /* Set MTU to 1412 */ val = uint_to_gvalue (1412); if (val) g_hash_table_insert (config, NM_VPN_PLUGIN_IP4_CONFIG_MTU, val); it seems we are harcoding this. Unfortunately, this leads to weird issue, as I use a 3G connection with (ppp0) MTU:1400, and a vpn connection with MTU:1412 . As a result, I have issues browsing certain website, and sending emails.
(In reply to comment #1) > This also appears to affect the OpenVPN and PPTP plugins. > > Additionally, it seems to me (from looking at the code in the Cisco VPN client > for linux), that they are setting the MTU to an arbirary value too, although it > is substancially lower, more around 1300, than the current 1412. This is done > to support all the different levels of encapsulation of packets; so IP, UDP and > ESP headers and the like. Matt, any idea what an ideal MTU would be? vpnc apparently now pushes some server-specified (or calculated) MTU down to the helper script for which I just committed a patch to respect the other day. Not sure if that's going to be good enough. I guess ideally NM should re-adjust the MTU of the tun/tap device to always be less than the MTU of it's parent physical device (ie the device over which the route to the VPN gateway goes).
I wish I'd spotted this before I submitted bug 603575 -- this is exactly the problem (with the fix) that is described there.
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/112248 Please see the above Ubuntu bug for updated patches to fix this. We'd strongly urge upstream to get around committing this. Thanks!
That patch is for openvpn and doesn't do what bug 603575 does (calculate the correct MTU). However, I've suggested that we do need a way of overriding the calculated MTU for those cases where the path mtu can't be discovered.
This seems fixed in 0.8.1 or at least the version packaged in Fedora 14. The additional options for MTU, UDP fragment size and MSS fix my OpenVPN connection, which previously I could only set up via the command line.
I suggest expanding this bug to other VPN plugins. Setting MTU can be vital. I have to apply NM dispatcher workaround to connect to PPTP server over wimax provider which has MTU 1400, so I have to lower the value of PPTP MTU beyond hardcoded 1400. Please add options to VPN plugins!
Created attachment 350273 [details] [review] custom mtu support I've created a patch which implements custom MTU for vpnc. However I'm not quite understand why this option didn't appear in network-manager GUI when you edit connection. When you edit /etc/NetworkManager/system-connections/vpnc file directly - this option works fine. I'd appreciate any help regarding the GUI. Here is my git https://github.com/kayrus/network-manager-vpnc/commit/456f1db75c2905e524e88346818b83f949858eea
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).