VPN tunnel connections are not properly setting MTU values

Bug #1110787 reported by Richard Merren
54
This bug affects 11 people
Affects Status Importance Assigned to Milestone
NetworkManager
New
Undecided
Unassigned
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I regularly connect to a cisco anyconnect vpn using vpnc through the network manager. I am often at various different location using wifi, including connecting via wifi to a cellular hotspot. Usually, when connecting to a WIFI connection the MTU value (on the wifi connection) is 1500. When connecting to the vpn, the MTU value of the tun0 connection is set automatically and it usually sets itself to something like 1412. This works with no problem.

When the wifi connection has a lower MTU value (and the cellular hotspot usually has an MTU of 1430, as do connections in various coffee shops), the tun0 connection still sets itself to 1412. For read-intensive operations (e.g. accessing websites and downloading pages, pulling from a subversion repository) there is no apparent problem. But when attempting to post to a web page (for instance, writing a bug report in bugzilla) or commit to a repository over the VPN, the connection will fail. The MTU value for a VPN connections seems to want to be 78 less than the MTU value of the connection that it is working over, and having MTU greater than this causes the upload failures.

I use the VPN via the network manager (using network-manager-vpnc and network-manager-vpnc-gnome). I am able to work around the issue by setting the MTU value of the VPN connection manually from the command line after connecting with the following command:

sudo ifconfig tun0 mtu 1330

It is tedious to do this each time, but it does allow me to successfully upload or commit when connected. (I also find that RDP connections fail much less often when the MTU is set correctly.) I should note that I pick an MTU value that is 100 less than the MTU value of the WIFI connection--it should be 78 but I opt for the easier math and don't really notice the difference.

And for those that don't know, you can find the current MTU value of your connections by issuing the "ifconfig" command.

If you do not have access to a cellular hotspot or other wifi connection that has a low MTU value, it is likely you can replicate this issue by manually setting the primary network connection's MTU value to 1430 (using the above command) though I have not tried to replicate it under these conditions.

Ideally, the VPN connection would properly calculate an appropriate MTU value to use with the network adapter it will be communicating over. Perhaps it is trying that and simply cannot identify the proper connection--while writing this it occurs to me that the eth0 connection has an MTU value of 1500 even though I don't have a network cable plugged in, but lowering the eth0 MTU value had no effect on the tun0 MTU value chosen when I connected to VPN over the WIFI connection.

To replicate the error:
* connect to a wifi connection that gives you an MTU value of 1430
* connect to VPN using vpnc via network manager
* verify that the MTU value of your tun0 connection was set to 1412
* Attempt a large upload (a large file, a large bugzilla comment or other html form submission, or a sizeable svn commit) and it should fail

Important version info requested:
Ubuntu 12.10
vpnc is 0.5.3r512-2ubuntu1
network-manager, network-manager-vpnc, and network-manager-vpnc-gnome are all 0.9.6.0-ubuntu1

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1110787/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
affects: ubuntu → network-manager (Ubuntu)
tags: added: quantal
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Bartłomiej Żogała (nusch) wrote :

also affects network-manager 0.9.8.8-0ubuntu7 with network-manager-vpnc 0.9.8.6-1ubuntu2

Revision history for this message
Richard Merren (richard-merren) wrote :

I am still seeing this problem in 14.10, even installed fresh on a new laptop. I have found a workaround that takes care of the problem automatically, though. There is a 1412 mtu hardcoded in /etc/vpnc/vpnc-script, but that may not be relevant to network manager so I didn't mess with that script. The NetworkManager man page notes that any scripts placed in /etc/NetworkManager/dispatcher.d will run when network connections go up and down, and that they will receive the name of the interface and the action as parameters to the script. So I placed the following script in that directory under the name "70vpnMtuCorrection" (the scripts run in alpha order, and there was already one more there so I wanted this one to run later...but you can call it anything else you like and it should still work). The script needs to be owned by root and executable by all (so use sudo to save it and execute a "chmod a+x" on the file"). The script determines if the tun0 interface is coming up, if we have a wlan0 connection, calculates the necessary mtu value, and resets it if the MTU value needs to be decreased. This seems to be handling my issue, but I would still prefer to see that it is handled properly by network manager in the first place. But if you are having the same problem, this should remove a pesky annoyance like it is doing for me:

/etc/vpnc/vpnc-script/70vpnMtuCorrection:

#!/bin/bash
TUN0_INTERFACE_NAME="tun0"
WLAN0_INTERFACE_NAME="wlan0"
VPN_UP_ACTION_NAME="vpn-up"
MTU_DIFFERENCE=78

INTERFACE_NAME=${1}
ACTION=${2}

if [ "${INTERFACE_NAME}" != "${TUN0_INTERFACE_NAME}" ]
then
    exit 0
fi

if [ "${ACTION}" != "${VPN_UP_ACTION_NAME}"]
then
    exit 0
fi

#Make sure we have a current TUN0 entry before we continue.
CURRENT_TUN0_MTU=`sudo ip link list | grep "${TUN0_INTERFACE_NAME}:" | sed -r "s/.*mtu ([0-9]+).*/\1/"`
if [ "${WLAN_MTU}" == "" }
then
    exit 0
fi

#Also make sure we have a current WLAN0 entry
WLAN_MTU=`sudo ip link list | grep "${WLAN0_INTERFACE_NAME}:" | sed -r "s/.*mtu ([0-9]+).*/\1/"`
if [ "${WLAN_MTU}" == "" }
then
    exit 0
fi

NEW_TUN0_MTU=$((${WLAN_MTU} - ${MTU_DIFFERENCE}))

if [ ${NEW_TUN0_MTU} >= ${CURRENT_TUN0_MTU} ]
then
    exit 0
fi

ip link set ${TUN0_INTERFACE_NAME} mtu ${NEW_TUN0_MTU}

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.