NetworkManager always overwrites default route when connecting to OpenVPN network

Bug #330833 reported by Gabriel Bauman on 2009-02-18
166
This bug affects 25 people
Affects Status Importance Assigned to Milestone
NetworkManager-OpenVPN
Invalid
High
network-manager (Debian)
New
Unknown
network-manager (Fedora)
Invalid
Medium
network-manager (Ubuntu)
Undecided
Unassigned
Nominated for Jaunty by Jonathan Ernst
network-manager-openvpn (Ubuntu)
Medium
Unassigned
Nominated for Jaunty by Jonathan Ernst

Bug Description

Binary package hint: network-manager

My office VPN has IMAP, (forwarding) DNS services and not much else. It doesn't forward client traffic to the Internet. This means I can't use the VPN server as a default gateway.

Every time I connect to the VPN using NetworkManager/OpenVPN, my routing table gets a default route to the VPN. I've tried everything to avoid this in both the Intrepid package and the version from the network manager PPA with no success. Even telling NetworkManager to ignore routes from the server doesn't work.

As it is right now, I have to connect to the VPN, delete the default route, and re-add my wireless router as the default gateway before I can have both email and web access.

See attached routing table details.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: network-manager 0.7-0ubuntu1~nm1~intrepid1
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
Uname: Linux 2.6.27-11-generic i686

Gabriel Bauman (gabrielbauman) wrote :
Gabriel Bauman (gabrielbauman) wrote :
description: updated
Steve Langasek (vorlon) wrote :

I'm confirming this bug. It is a general problem that when network-manager brings up two interfaces and each provides a default route, the latter interface's route clobbers the former's instead of both routes being made available (the classic, sensible behavior).

Upstream fixed bug #288409, which makes it possible to disable configuration of default routes for an interface, but this is not really what you want in the general case - in general, if you have two networks both active and both provide default routes, both of these routes should be made available, not just one or the other. So this is still a bug, even if there's now a way to forcibly disable the default route on a given interface.

This is also related to bug #199140, which is that NM shouldn't be meddling with openvpn connections at all by default.

Changed in network-manager:
importance: Undecided → Medium
status: New → Triaged
Jonathan Ernst (jonathan.ernst) wrote :

@Steve

The problem here is that our VPNs don't push a new _default_ route, but routes to certain destinations only. It worked fine some weeks ago and still works fine if you are not using Network Manager but the normal openvpn service.

This is a major network-manager-openvpn regression currently affecting both Intrepid and Jaunty.

Description of problem:
When connecting to VPN with NetworkManager-vpnc, it sets the default route to the VPN device. When I connect with "vpnc" it leaves the default route alone.

There are also a couple of other routes missing when I use NetworkManager to connect.

Version-Release number of selected component (if applicable):
NetworkManager-vpnc-0.7.0.99-1.fc10.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Connect to vpn
2.Check route with "route"
3.

Actual results:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

Expected results:
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

Additional info:
The diff between the vpnc routing and the NetworkManager-vpnc routing is:
--- vpnc 2009-03-25 14:38:59.629563747 -0700
+++ nwman 2009-03-25 14:39:25.283537596 -0700
@@ -1,7 +1,5 @@
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric Ref Use Iface
-10.yy.yy.yy 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
-10.zz.zz.zz 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
 xx.xx.xx.xx 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 2 0 0 wlan0
 10.69.148.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
@@ -32,4 +30,4 @@
 10.224.0.0 0.0.0.0 255.224.0.0 U 0 0 0 tun0
 10.0.0.0 0.0.0.0 255.192.0.0 U 0 0 0 tun0
 10.128.0.0 0.0.0.0 255.192.0.0 U 0 0 0 tun0
-0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
+0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

Steve Beattie (sbeattie) wrote :

Presumably this is an issue in network-manager-openvpn, and not network-manager proper? If so, can the package be adjusted?

affects: network-manager (Ubuntu) → network-manager-openvpn (Ubuntu)

Same problem here.

Actually, looking a bit more at the vpn configuration I can tell that it's all configurable.

Click on the Network Manager icon and choose "VPN Connections" -> "Configure VPN...". Then choose the connection name and click "Edit". Go to "IPv4 Settings" tab and click the "Routes" button at the lower-right corner.
Check off "Use this connection only for resources on its network".
This should make vpn use the old default route instead of redirecting all traffic to tun0.
Additional routes can be set up here as well.

But I really think that leaving the default route intact should be the default vpnc behaviour.

Thanks,
Vax.

Steve Beattie (sbeattie) wrote :

Closing the network-manager component portion of the task.

Changed in network-manager (Ubuntu):
status: New → Invalid
Alexander Sack (asac) wrote :

can you please attach your complete syslog after reproducing this?

Also have you tried to tweak the IPv4Settings tab in the connection editor for your VPN connection? consider to ignore the defaults routes there.

Jonathan Ernst (jonathan.ernst) wrote :

@Alexander
Thanks for looking into this ; here are more informations.

Normal route table (with no VPN) :

jernst@jernst-desktop:~$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Route table (with VPN and "ignore obtained routes" checked (you can see that the default gateway has been replaced even if routes should be ignored) :
jernst@jernst-desktop:~$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.1.0.21 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
193.XX.YYY.99 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 10.1.0.21 0.0.0.0 UG 0 0 0 tun0

Route table (with VPN and "ignore obtained routes" unchecked (the configuration that worked fine before this regression) :
jernst@jernst-desktop:~$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.1.0.21 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
193.XX.YYY.99 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
193.XX.YYY.100 10.1.0.21 255.255.255.252 UG 0 0 0 tun0
193.XX.YYY.4 10.1.0.21 255.255.255.252 UG 0 0 0 tun0
193.XX.YYY.104 10.1.0.21 255.255.255.248 UG 0 0 0 tun0
193.XX.YYY.8 10.1.0.21 255.255.255.248 UG 0 0 0 tun0
193.XX.YYY.112 10.1.0.21 255.255.255.240 UG 0 0 0 tun0
193.XX.YYY.128 10.1.0.21 255.255.255.128 UG 0 0 0 tun0
10.0.0.0 10.1.0.21 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
10.1.0.0 10.1.0.21 255.255.255.0 UG 0 0 0 tun0
10.2.0.0 10.1.0.21 255.255.0.0 UG 0 0 0 tun0
0.0.0.0 10.1.0.21 0.0.0.0 UG 0 0 0 tun0

Requested syslog attached.

tapczan (tapczan) wrote :

Routing tables

no VPN:

10.1.1.0/24 dev wlan0 proto kernel scope link src 10.1.1.11 metric 2
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
default via 10.1.1.254 dev wlan0 proto static

VPN enable by network-manager-openvpn - default route overwrite:

62.xx.xx.xx via 10.1.1.254 dev wlan0 proto static
62.xx.xx.xx via 10.0.12.1 dev tun0 proto static
62.xx.xx.xx via 10.0.12.1 dev tun0 proto static
10.0.12.0/25 dev tun0 proto kernel scope link src 10.0.12.21
10.1.32.0/24 via 10.0.12.1 dev tun0 proto static
10.1.1.0/24 dev wlan0 proto kernel scope link src 10.1.1.11 metric 2
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
62.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
62.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
62.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
62.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
212.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
89.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
79.xx.xx.xx/xx via 10.0.12.1 dev tun0 proto static
169.254.0.0/16 dev wlan0 scope link metric 1000
10.0.0.0/8 via 10.0.12.1 dev tun0 proto static
default via 10.0.12.1 dev tun0 proto static

Steve Beattie (sbeattie) on 2009-04-28
tags: added: jaunty regression-release
removed: regression-potential
dgarcia (garcia-danny) wrote :

I got around this problem by adding a route on the IPv4 tab when editing the VPN connection. The route I added was

address: 172.x.y.0
netmask: 255.255.255.0
gateway: 172.x.y.117
metric: 1000

I also selected "ignore automatically obtained routes" and "use this connection only for resources on this network". The gateway was the remote open VPN server's private IP address. I'm also using a TAP device. The open VPN server gives the client an address in its pool of addresses.

Regards,
Daniel

Tobias Krais (tux-spam) wrote :

I recently upgraded to Jaunty and can now confirm the bug (I didn't have it in Intrepid). I establish the VPN connection (TAP or TUN does not matter) and am able to ping the VPN LAN. But I was no more able to ping the Internet. Each time I established a VPN connection I manually added my default gw and it worked like a charm.

Thanks to Daniel for the workaround. It works out for me, too.

Tobias Krais (tux-spam) wrote :

Sorry for disturbing again. I investigated the problem a bit. Next my routes without VPN connection:
-----%<-----
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 2 0 0 wlan0
default fritz.fon 0.0.0.0 UG 0 0 0 wlan0
-----%<-----

Here my routes when establishing the VPN connection and letting network-manager-openvpn manage the routes. Pinging Internet does not work with it:
-----%<-----
Ziel Router Genmask Flags Metric Ref Use Iface
p549F6954.dip.t 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
10.1.1.21 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 2 0 0 wlan0
10.1.1.0 10.1.1.21 255.255.255.0 UG 0 0 0 tun0
default 10.1.1.21 0.0.0.0 UG 0 0 0 tun0
-----%<-----

And here my routes with the workaround described by Daniel. Pinging VPN LAN and Internet works with it:
-----%<-----
Ziel Router Genmask Flags Metric Ref Use Iface
p549F6954.dip.t 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
10.1.1.21 * 255.255.255.255 UH 0 0 0 tun0
bbec-server.bbe * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 2 0 0 wlan0
10.1.1.0 bbec-server.bbe 255.255.255.0 UG 1000 0 0 tun0
default 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
-----%<-----

My conclusion: the VPN server does not pass a default gw option but the network-manager-openvpn sets it! It should not set a default gw if it is not explecitly passed.

Hope this helps.

Greetings, Tobias

I have a very similar problem here. But I cannot work around it using the technique mentioned in #2 because that box is not checked.

When I connect using vpnc from the command line my name servers are correctly tunnelled down tun0 as in the bug description. However when I connect using NetworkManager-vpnc (default settings, and in fact every combination of settings I have tried so far) my name servers are not send down tun0 and consequently I cannot access any internal systems.

NetworkManager-vpnc should have the same behaviour as the vpnc command line client.

(In reply to comment #2)
> But I really think that leaving the default route intact should be the default
> vpnc behaviour.

It must be a behaviour change, because it used to work OK. Anyway, checking that box does fix the problem for me.

John Rüdén (john-ruden) wrote :

I have this problem as well. Before I could access other stuff on internet but now I can only be connected to either the office (openvpn on) or the rest of internet (openvpn off). I too use the Network Manager Applet for handling this.

bob_bob (matthewmohan) wrote :

Yes! Daniel's workaround solved my issue.

However, I'd suggest a minor refinement. In my case at least, I was able to just use the "use this connection only for resources on this network" and leave the automatic route pushing on. This simplifies managing the routes should the network change, and also seems to prevent the default gateway clobbering.

JeppeM (jeppe-mariager) wrote :

I can confirm this bug as well, using 9.04 with a newly set up OpenVPN server (running the server edition of 9.04 ). When using openvpn from the command-line, this problem does not exist, so it's most likely network-manager-openvpn which is the problem.

Changed in network-manager (Fedora):
status: Unknown → Confirmed

The workaround "use this connection only for resources on this network" seems to fix it.

It should be enabled by default IMHO as this _was_ the default behavious and _is_ the default behavior of openvpn client.

Changed in network-manager (Debian):
status: Unknown → New
Changed in network-manager-openvpn:
status: Unknown → New

Same problem here. I'm behind a firewall and a proxy. The proxy only could only be reached by the default gateway. IMHO network-manager-openvpn should only change routes when routes are pushed. I only push one dedicated route and I need my original default gateway. I've tested all this with the GUI's on Windows and Mac - all behave correct but network-manager-openvpn does not.

Dave Rawks (drawks.) wrote :

The "use this connection only for resources on this network" option only works if the routes you normally push through openvpn are on the same subnet as the openvpn endpoint address you are assigned. Since my vpn config uses static nat'd addresses on 1918 space to provide a route through the vpn to non-1918 space that filters traffic not routed through the vpn AND the vpn only passes traffic for destinations on the subnets that it pushes routes for there is no combination of checkboxes in Jaunty's NM configurator which allows this to work as expected. I want a checkbox that is "only use routes pushed by vpn server" I expect that this is the ACTUAL behavior that most people expect.

Tobias Krais (tux-spam) wrote :

Still same in Karmic.

Confirmed that checking the box fixes the problem here as well.

By default, VPNs get the default route as that is the most secure configuration of a VPN. If that is not your VPN configuration, you'll need to check the "Only use this connection for resources on its network" and then only the specific routes sent by the VPN server (or ones you enter manually) will be routed over the VPN tunnel.

If you have further problems, please re-open and include some of /var/log/messages that show the IP configuration that NM is getting from vpnc. It will look like this:

NetworkManager: <info> VPN connection 'foobar' (Connect) reply received.
NetworkManager: <info> VPN connection 'foobar' (IP Config Get) reply received.
NetworkManager: <info> VPN Gateway: 101.22.183.53
NetworkManager: <info> Tunnel Device: tun0
NetworkManager: <info> Internal IP4 Address: 10.3.227.85
NetworkManager: <info> Internal IP4 Prefix: 20
NetworkManager: <info> Internal IP4 Point-to-Point Address: 10.3.227.85
NetworkManager: <info> Maximum Segment Size (MSS): 0
NetworkManager: <info> Static Route: 172.16.0.0/16 Next Hop: 172.16.0.0
NetworkManager: <info> Static Route: 10.0.0.0/8 Next Hop: 10.0.0.0
NetworkManager: <info> Internal IP4 DNS: 10.5.26.20
NetworkManager: <info> Internal IP4 DNS: 10.5.26.21
NetworkManager: <info> DNS Domain: 'foobar.com'

that will help us determine if vpnc and NM are getting the right data.

Changed in network-manager (Fedora):
status: Confirmed → Invalid

Why exactly is that bug marked invalid?

WalterNicholls (walter-nic) wrote :

I can also confirm this happens in Kubuntu Karmic, trying to get to a newly-set-up OpenVPN server.
It actually eventually fails to connect (for as yet unknown reason) but while it is trying, it sets all the routing table correctly with pushed routes to LAN .. but also sets default gateway to the (remote) VPN server.
Windows XP running OpenVPN GUI works perfectly. Running sudo openvpn --config xyz.ovpn, with exactly the same .ovpn file as used in Windows also works (apart from editing resolv.conf to set name server, a general Linux problem)
I must admit that the Network Manager openvpn gateway is much improved over Jaunty, but it is still many slices short of a full loaf.

Drate Otin (drate-otin) wrote :

Also noting problem in Karmic, also noting the "Daniel Workaround" works.

Am using a bridged VPN connection. Will happily provide other information needed.

Gionn (giovanni.toraldo) wrote :

I am using 'ignore automatically obtained routes', but my original default gateway disappears when connecting to a vpn that already not push any default gw by its configuration.

eth0: 192.168.42.0/24
tun0: vpn with 213.188.*.*
virbr0: ignore it, kvm virtual subnet

$ route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
213.188.*.* 192.168.42.1 255.255.255.255 UGH 0 0 0 eth0
192.168.42.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

should be:
$ sudo route del default
$ sudo route add default gw 192.168.42.1
$ route -n
route -n
Tabella di routing IP del kernel
Destination Gateway Genmask Flags Metric Ref Use Iface
213.188.*.* 192.168.42.1 255.255.255.255 UGH 0 0 0 eth0
192.168.42.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.42.1 0.0.0.0 UG 0 0 0 eth0

Using openvpn with the simplest configuration by hand works.

Gionn (giovanni.toraldo) wrote :

Indeed, with "use this connection only for resources on this network" in the routes tab is a workaround, should be enabled by default.

sw0x2A (sw0x2a) wrote :

Same behaviour still in Lucid Lynx. I really recommend to enable "Use this connection only for resources on its network" by default for OpenVPN connections.

Changed in network-manager-openvpn:
status: New → Invalid
raliegh (steve-ubuntu-sr-tech) wrote :

I've been affected by this bug for since Hardy and surprised to still see it in Lucid. Checking "Use this connection only for resources on its network" is unacceptable for those who need to use the VPN as a way of securing traffic on public hotspots. I normally run an autovpn script that I found online that brings up the VPN after a connection change, like when a wifi interface is brought up, and in that script I'll fix my default gateway.

But today, I noticed that while on a local wifi router that had a different subnet than the one my openvpn server is on, the routes were set fine and I had no issues. Heres the scenario that works using stock nm-openvpn:
 Local wifi router on 192.168.1.0/24 --> Internet
 Remote Openvpn router/server 192.168.0.1/24 --> Internet

The scenerio that doesn't work using nm-openvpn unless default route is modified after vpn up:
 Local wifi router on 192.168.0.0/24 --> Internet
 Remote Openvpn router/server 192.168.0.1/24 --> Internet

Of course, the VPN subnet is on a different subnet than the local ones, 10.0.0.0/24, but thats not a factor.

Perhaps this will help someone?

raliegh (steve-ubuntu-sr-tech) wrote :

Trying to find a better solution, I decided to try some new ways of fixing the routes after the VPN is brought up. Heres what i'm using now:

I edit /etc/NetworkManager/dispatcher.d/01ifupdown as follows:
Add the lines from "#vpn fix" to "#end fix" after the line "case "$2" in" as shown:

case "$2" in
   #vpn fix
   vpn-up)
        #lets stick in a new host route to keep the VPN working
        DIF=`/sbin/route -n | grep UGH | sed "s/ */ /g" | cut -d " " -f 8`
        DRT=`/sbin/route -n | grep UGH | sed "s/ */ /g" | cut -d " " -f 2`
        /sbin/route add -host $DRT $DIF
        exit 0
   ;;
    vpn-down)
        #lets remote the unneeded route now that the vpn is down
        DIF=`/sbin/route -n | grep UH | sed "s/ */ /g" | cut -d " " -f 8`
        DRT=`/sbin/route -n | grep UH | sed "s/ */ /g" | cut -d " " -f 1`
        /sbin/route delete -host $DRT $DIF
     exit 0
   ;;
   #end fix
 up)
 export MODE="start"
 export PHASE="up"
  ...
  ...

Now my OpenVPN configuration works with no extra routes set and no options checked off. I can connect to all the hosts on the remote network as well as use the remote gateway as my default (I push the option on the server side) so I can secure all my activity while on a untrusted hotspot.

Paweł Zuzelski (pawelz) wrote :

“Use this connection only for resources on its network.” resolved this issue. IMHO it should be set by default. Note that remote can still push default route, there is no need to force that.

Changed in network-manager-openvpn:
importance: Unknown → High
Karl (k-schuh) wrote :

Since I have different networks behind my openvpn-gateway, checking “Use this connection only for resources on its network.” did not help me (but I keept it checked). Maybe someone could just add an input-field to specify additional routes (like in an up-script)?

Then I found raliegh´ s tip in post #27. I just simplified it by editing /etc/NetworkManager/dispatcher.d/01ifupdown like:

Add the lines from "#vpn fix" to "#end fix" after the line "case "$2" in" as shown:

case "$2" in
   #vpn fix
   vpn-up)
        #lets stick in a new host route to keep the VPN working
        /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw <my ppp-endpoint>
        exit 0
   ;;
    vpn-down)
        #lets remote the unneeded route now that the vpn is down
        /sbin/route del -net 192.168.0.0
     exit 0
   ;;
   #end fix
 up)
 export MODE="start"
 export PHASE="up"
  ...
  ...

Now everything works fine. My route is set up and deleted automatically as desired when I bring up and close the vpn-connection.

Thanks a lot raliegh!

Karl

Karl,

If you check "Use ..." and have multiple routes provided by your VPN you should also set them in the Routes box above that checkbox (might be slightly different under Kubuntu). Otherwise only the routes sent to you from the VPN server are used.

Marking Fix Released, since there is not only the checkbox but a way to manually set the routes to use.

Changed in network-manager-openvpn (Ubuntu):
status: Triaged → Fix Released
Changed in network-manager (Fedora):
importance: Unknown → Medium
Adam Felson (adam-ubuntu) wrote :

it's 2019 and the same bug still exists.

Peter Würtz (pwuertz) wrote :

Well, it's 2020 now. I'm stunned to see that Ubuntu chooses VPN as the IPv6 default route, even when choosing IPv6 "Disable" in the VPN settings :( (completely ignored by the way).

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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