nm-vpnc and vpnc-connect produce different routing tables

[Matthew Tighe]

Logging into the same cisco concentrator produces different results depending how you connect.

From network manager the default route is pointed at tun0.

Destination Gateway Genmask Flags Metric Ref Use Iface
<cisco-cocentrator-ip> 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default * 0.0.0.0 U 0 0 0 tun0

However, vpnc-connect produces a list of routes (provided by the concentrator) and a default route to eth0:

Destination Gateway Genmask Flags Metric Ref Use Iface
<cisco-cocentrator-ip> 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
<fqdn-host> * 255.255.255.255 UH 0 0 0 tun0
<fqdn-host> * 255.255.255.255 UH 0 0 0 tun0
<internal-ip> * 255.255.255.255 UH 0 0 0 tun0
<internal-ip> * 255.255.255.255 UH 0 0 0 tun0
<internal-ip> * 255.255.255.224 U 0 0 0 tun0
<internal-ip> * 255.255.255.192 U 0 0 0 tun0
<internal-ip> * 255.255.255.128 U 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
<internal-ip> * 255.255.254.0 U 0 0 0 tun0
<internal-ip> * 255.255.248.0 U 0 0 0 tun0
<internal-ip> * 255.255.192.0 U 0 0 0 tun0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

The net effect is I can do my normal Internet related stuff with vpnc-connect. With network-manager-vpnc I cannot unless I specify the addresses in my network-manager-vpnc config.

[Chris Pratt (pratt70)]

Having exact same issue-- vpnc-connect and network-manager-vpnc both authenticate and bring up tun0, but vpnc-connect sets up routes properly and network-manager-vpnc does not:

Default Boot

cpratt@ubuntu_8.0.4:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

Started VPN via network-manager-vpnc (0.6.4svn2422-0ubuntu5)

cpratt@ubuntu_8.0.4:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
72.14.253.83 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

Disconnected network-manager-vpnc (0.6.4svn2422-0ubuntu5)

cpratt@ubuntu_8.0.4:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

Started VPN via vpnc-connect (0.5.1r275-1)

cpratt@ubuntu_8.0.4:~$ sudo vpnc-connect
Enter IPSec gateway address: 72.14.253.83
Enter IPSec ID for 72.14.253.83: grokauth
Enter IPSec secret for grokauth@72.14.253.83:
Enter username for 72.14.253.83: cpratt
Enter password for cpratt@72.14.253.83:
VPNC started in background (pid: 15577)...
cpratt@ubuntu_8.0.4:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
72.14.253.83 192.168.1.1 255.255.255.255 UGH 1500 0 0 wlan0
172.20.0.81 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.20.0.80 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.21.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.10.0.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
cpratt@ubuntu_8.0.4:~$

[Matthew Tighe (tighem)]

Marking as confirmed

[Janne Hyötylä (janne-hyotyla)]

Could this have something to do with the fact that nm-vpnc lacks support for different settings that vpnc-connect uses (eg. through a config file)? See for example Bug #165237 for one such problem.

[Chris Pratt (pratt70)]

Don't think that is it. My vpnc etc is still default. I have never created a vpnc config file but have only entered the parameters at the cli:

With nm-vpnc connection--

user@laptop:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<VPN-IP> 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0

With vpnc-connect connection--

user@laptop:~$ sudo vpnc-connect
Enter IPSec gateway address: <VPN-IP>
Enter IPSec ID for <VPN-IP>: <ID>
Enter IPSec secret for <ID>@<VPN-IP>:
Enter username for <VPN-IP>: user
Enter password for user@<VPN-IP>:
VPNC started in background (pid: 23513)...
user@laptop:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<VPN-IP> 192.168.1.1 255.255.255.255 UGH 1500 0 0 wlan0
172.20.0.81 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.20.0.80 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
172.21.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.20.0.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

Does nm-vpnc call same vpnc-script?

[Matthew Tighe (tighem)]

Same here. Minimal VPNC config on my end.

[Matt Brubeck (mbrubeck)]

This apparently happens because NM uses its own vpnc-script:
http://osdir.com/ml/network.networkmanager.devel/2006-03/msg00084.html

[Anthony Brock (anthony-brock)]

I am also encountering this issue. Unfortunately, this is also affected several of my customers. I tried to follow the instructions listed at the above link and the results are attached.

As with everyone above, launching vpnc-connect from the command line works perfectly. Here is the routing table before connecting to the VPN:

$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.192.126.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0
0.0.0.0 10.192.126.1 0.0.0.0 UG 0 0 0 eth0
$

Here is the routing table after connecting to the VPN:

$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
128.193.10.189 10.192.126.1 255.255.255.255 UGH 0 0 0 eth0
10.192.126.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
$

Any ideas if a fix is in the works? My customers have discovered that the official Linux VPN from Cisco has stopped functioning and are trying to shift to vpnc. However, the default "full tunnel" configuration is causing some issues. Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

This appears to be fixed in the current network-manager (0.7~~svn20080928t225540-0ubuntu1) in intrepid. This issue seems to me like it comes from network-manager-vpnc's lack of support for importing the routes (which are handed to nm-vpnc from vpnc) into the network-manager system. Not sure where to go from there... Should the bug be marked as Invalid because it pertains to an older release, or Fix Released since it's in Intrepid and will be officially released soon?

[Simon Schaak (sschaak)]

This seems to exist still in the intrepid release version.
Nm-vpnc connects correctly, but the routing tables aren't changed so the vpn-tunnel is used as default-route.
Via vpnc(-connect) this works fine. I experienced this on 2 new installations of ubuntu 8.10 final.
With nm-vpnc 0.6.4svn2422-0ubuntu5 (on hardy) everything is working fine, only the new version is affected.

[Doug Schaapveld (djschaap)]

I had the "default route only" issue when using Hardy. nm-vpnc has been working perfectly for me since upgrading to Intrepid (months ago). It now installs the correct routes and behaves pretty much exactly as vpnc does. Currently using network-manager-vpnc 0.7~~svn20081015t024626-0ubuntu1.

[Michael DePaulo (mikedep333)]

I can confirm this bug is present in Jaunty.

[Michael DePaulo (mikedep333)]

Here's my sample NM output from var/log/daemon.
Note that the first time it failed to connect and I do not know why.

Apr 6 09:45:06 emissary NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Apr 6 09:45:06 emissary NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 6910
Apr 6 09:45:06 emissary NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
Apr 6 09:45:17 emissary NetworkManager: <info> VPN plugin state changed: 3
Apr 6 09:45:17 emissary NetworkManager: <info> VPN connection 'PSU from ISP' (Connect) reply received.
Apr 6 09:45:18 emissary NetworkManager: <info> VPN plugin failed: 1
Apr 6 09:45:18 emissary NetworkManager: <info> VPN plugin state changed: 6
Apr 6 09:45:18 emissary NetworkManager: <info> VPN plugin state change reason: 0
Apr 6 09:45:18 emissary NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Apr 6 09:45:18 emissary NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Apr 6 09:45:18 emissary NetworkManager: <info> Policy set 'Auto zorp' (wlan0) as default for routing and DNS.
Apr 6 09:45:31 emissary NetworkManager: <debug> [1239025531.000973] ensure_killed(): waiting for vpn service pid 6910 to exit
Apr 6 09:45:31 emissary NetworkManager: <debug> [1239025531.001158] ensure_killed(): vpn service pid 6910 cleaned up
Apr 6 09:46:26 emissary NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Apr 6 09:46:26 emissary NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 6938
Apr 6 09:46:27 emissary NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
Apr 6 09:46:27 emissary NetworkManager: <info> VPN plugin state changed: 1
Apr 6 09:46:33 emissary NetworkManager: <info> VPN plugin state changed: 3
Apr 6 09:46:33 emissary NetworkManager: <info> VPN connection 'PSU from ISP' (Connect) reply received.
Apr 6 09:46:34 emissary NetworkManager: <info> VPN connection 'PSU from ISP' (IP Config Get) reply received.
Apr 6 09:46:34 emissary NetworkManager: <info> VPN Gateway: 128.118.97.125
Apr 6 09:46:34 emissary NetworkManager: <info> Tunnel Device: tun0
Apr 6 09:46:34 emissary NetworkManager: <info> Internal IP4 Address: 172.25.1.141
Apr 6 09:46:34 emissary NetworkManager: <info> Internal IP4 Prefix: 24
Apr 6 09:46:34 emissary NetworkManager: <info> Internal IP4 Point-to-Point Address: 172.25.1.141
Apr 6 09:46:34 emissary NetworkManager: <info> Maximum Segment Size (MSS): 0
Apr 6 09:46:34 emissary NetworkManager: <info> Static Route: 128.118.0.0/16 Next Hop: 128.118.0.0
Apr 6 09:46:34 emissary NetworkManager: <info> Static Route: 146.186.0.0/16 Next Hop: 146.186.0.0
Apr 6 09:46:34 emissary NetworkManager: <info> Static Route: 130.203.0.0/16 Next Hop: 130.203.0.0
Apr 6 09:46:34 emissary NetworkManager: <info> Static Route: 150.231.0.0/16 ...

[Doug Schaapveld (djschaap)]

Solution found in (pre-release) Jaunty!

From the VPN tab of the Network Connections window, select a VPN connection and click Edit. From the IPv4 Settings tab, click the Routes... button near the bottom of the window. The "Use this connection only for resources on its network" checkbox will prevent NM from changing the default route. (This appears to be new in Jaunty -- Intrepid does NOT have this option.)

Personally, I would prefer this checkbox defaulted to ON (do not automatically tunnel all traffic) to match the behavior of other VPN clients I've used (including Cisco VPN client, vpnc and older versions of NM). Ideally, this would still allow the VPN concentrator to pull all traffic to it (by including 0.0.0.0/0 in its split tunnel list) but I haven't tested this.

[Evan Wies (evan-athenacr)]

This problem presented itself to me during the upgrade from Intrepid to Jaunty, with no other changes to the network or VPN setup. On Intrepid, everything worked fine. On Jaunty (beta as of 4/18/2009), all traffic was going to the VPN which was not properly resolving Internet domains (e.g., yahoo.com).

Applying Doug's fix (https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/207506/comments/13) by checking "Use this connection for resources on its network" fixed the problem.

[Jens Janssen (jayjay)]

Never had this problem on Intrepid or Hardy when connecting the network of my university via nm-vpnc. Problem occurred on jaunty for the first time (fresh install).

I can confirm that Doug's hint solved my problem (https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/207506/comments/13). This checkbox should be disabled by default.

[Toby Murray (toby-murray)]

Had this problem since upgrading to Jaunty. The checkbox did indeed fix it and I agree that the default should be changed. I believe this is how most people expect a VPN to work.

[Mathieu Trudel-Lapierre (cyphermox)]

I'd have to respectfully disagree -- although I ran into the same problem and also find it annoying to have to go so far to fix such a simple issue -- AFAIK, checking this effectively enables what is called "Split-tunnelling", and is considered a potential security issue in many environments.

On the other hand, it is true that in many cases the tunnels are specified in a list, and 0.0.0.0 usually isn't part of it (because otherwise, why use a list?).

Personally, I'd bring the issue upstream on the NetworkManager mailing list, or create a specific bug, since it seems to me like it's a different issue.

[Ruben Verhack (ruben-verhack)]

I can confirm that Doug's hint solved my problem (https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/207506/comments/13). This checkbox should be disabled by default.

I agree to this.

[MaGoo (ubuntu-one-infomails)]

The bug always exist:
I connect my computer with cable on eth0. The default route was the gateway on eth0
I connect my openVPN tunnel for split tunneling. When it connected, the default gateway was the IP of end tunneling. At this time, it is missing a route for the tunnel connexion. I need to had manualy a route command like:
route add 1.2.3.4/32 dev eth0 with 1.2.3.4 is the vpn host address.
If i connect manualy with openvpn script, the problem doesn't occor.

[Mathieu Trudel-Lapierre (cyphermox)]

MaGoo, please open a separate bug for your issue, as it is related to the openvpn plugin and not the VPNC plugin.

It appears to me like this bug has really been fixed since Intrepid or Jaunty, following the initial description from the bug reporter: routes now being imported by the plugin from vpnc, they are now "the same", depending on whether or not split-tunnelling is expected in your environment, which is another issue entirely.

I'm closing this bug since the initial issue has been resolved a long time ago. If you feel the default setting for "Use this connection only for resources on its network" should be changed, please open a separate bug on the issue (which should also be filed upstream and discussed on the NM mailing list).