desktop-packages team mailing list archive

[Richard Merren <1110787@xxxxxxxxxxxxxxxxxx>]

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}

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1110787

Title:
  VPN tunnel connections are not properly setting MTU values

Status in NetworkManager:
  New
Status in network-manager package in Ubuntu:
  Confirmed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1110787/+subscriptions