Intrepid regression: default route is no longer redirected over VPN tunnel

On Thu, Sep 11, 2008 at 05:16:49PM -0000, Launchpad Bug Tracker wrote:
> I believe it stopped working after upgrading to NM0.7, so I'm submitting
> the bug on this package (I'm not ruling out the possibility of the
> regression being in OpenVPN itself, though). I've attached the syslog
> output from when the tunnel is set up. One line stands out:

Are you using NM 0.7 VPN packages or configure that outside of NM?

 status incomplete

 - Alexander

I have NM 0.7, OpenVPN is set up through its GUI. Versions below:

ii network-manager 0.7~~svn20080908t183521+eni0-0ubuntu2 network management framework daemon
ii network-manager-gnome 0.7~~svn20080907t033843-0ubuntu2 network management framework (GNOME frontend
ii network-manager-kde 1:0.7svn830754-0ubuntu3 KDE systray applet for controlling NetworkMa
ii network-manager-openvpn 0.7~~svn20080908t183521a-0ubuntu2 network management framework (OpenVPN plugin
ii openvpn 2.1~rc9-3ubuntu2 virtual private network daemon
ii openvpn-blacklist 0.3 list of blacklisted OpenVPN RSA shared keys

Under «IPv4 Settings», the «Method» is set to «Automatic (VPN)». Under «Routes...», the setting «Ignore automatically obtained routes» is _not_ selected. These are the default settings.

Tore

I opened a similar ticket and closed it a few minutes ago, because in my case there is no default gateway set on my system (since the vpn server is in the same network as the client).

But if you have a default route, redirect-gateway should work! Do you have a default gateway?
Have you tried openvpn without NM - still happening then?

I'll do some tests as soon as I get home... Will report back later.

If I run OpenVPN from the command line, the default route is redirected as expected, so the regression has to be in network-manager[-openvpn].

I've also noticed another regression from Hardy, that the DNS dhcp-option pushed by the server isn't added to the nameserver list in /etc/resolv.conf. Curiously enough the DOMAIN dhcp-option pushed is added to the list of «search» domains in /etc/resolv.conf, and also overrides the «domain» setting in that file. /etc/resolv.conf does not change at all when I run OpenVPN from the command line - I don't think OpenVPN has the capability to do so on its own.

I'll update the title of the bug to include this too...

Tore

I can confirm this and reopend my Ticket #271547 accordingly, too.
So if a default gateway is set through dhcp it get replaced by openvpn (started via init script) but not by network-manager-openvpn.

For DNS there is also another Bugreport, that I created: #271542 for network-manager
In my case the DNS Server doesn't get set correctly, when connecting to the wifi network and getting the nameserver information from dhcp. However nameserver does get set correctly after nm-openvpn connected (after I added explicit DNS Options to the openvpn-server configuration, of course)
push "dhcp-option DNS <dnsserver>"
push "dhcp-option DOMAIN <domain>"
If the Openvpn Server does not provide DNS and DOMAIN the values of the undelaying connection should be used (which in my case were empty, so I had to add the dhcp-option mentioned above)

Like Tore I also noticed that "dhcp-option DOMAIN <domain>" is set as search domain

If you look at the Manpage of openvpn under "--dhcp-option type [parm]" you will not find an option SEARCH, there is only DOMAIN, and it seems DOMAIN is interpreted as SEARCH (there is no other option to set the search domains - SEARCH is more important than DOMAIN in my Opinion)

Tore, one more thing: I would like to know if you have resolvconf installed - I do.

For plain Openvpn look at the script /etc/openvpn/update-resolv-conf, /sbin/resolvconf is used to set the dns options in this script. And also note that you probably need to add a parameter "up <script> "and "down <script>" to your openvpn conf file.

I didn't have resolvconf installed. Tried to install it, but there was no change in behaviour - my employer's domain was added to the «search» list, but the nameserver itself wasn't added. The «domain» setting was completely absent from the file (both with and without VPN active), and the comment indicated that the file was generated by resolvconf instead of NetworkManager.

The regression is the same in both cases; my employers DNS server, pushed by the OpenVPN server as a dhcp-option «DNS», isn't added. Also it's worth noting that resolvconf is in universe, so it's not installed by default, and I therefore expect everything to work just fine (like it did in Hardy) without it.

Installing the resolvconf package didn't help with the default route redirection either, unsurprisingly.

I think your two bug reports can be merged with this one, Michael.

Tore

Marked Bug #271547 as a duplicate of this bug

Workaround or fix available?

The DNS part has started working again for me now, both the search domain and the server is correctly added to /etc/resolv.conf.

If you only need VPN access to a certain number of networks you can work around the bug by going to IPv4 Settings -> Routes... in the VPN connection editor (this _only_ works in GNOME's applet, which could be considered another bug). I've been unable to add 0.0.0.0/0 as a route there (it doesn't save it), but other routes with longer prefixes seems to work fine.

Tore.

There's more screwy things going on with network-manager-openvpn's interaction with the routing table, I realised. This is how my routing table look after activating the tunnel:

tore@envy:~$ ip r
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
VPN-GW.VPN-GW.VPN-GW.VPN-GW via 10.0.0.1 dev wlan0 proto static
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2
VPN.VPN.VPN.0/19 dev tun0 proto static scope link
169.254.0.0/16 dev wlan0 scope link metric 1000
VPN.VPN.0.0/12 dev tun0 proto static scope link
default via 10.0.0.1 dev wlan0 proto static

I've added the routes to VPN.VPN.* manually using the workaround I mentioned in another comment, since the default route redirection doesn't work. One thing missing here is that there should be a route to 10.8.0.1 (the OpenVPN server's internal OpenVPN address). It used to be automatically added before (and indeed, it pushes that address as the DNS dhcp-option too), so that's another regression.

You can see the host-route added to VPN-GW x 4 (which is neccessary for the OpenVPN connection to work, since that particular address is part of my employers VPN.VPN.VPN.0/19 network (and the OpenVPN packets can't very well be routed inside of the OpenVPN tunnel).

Then the VPN connection stop working. In my logs I see the following:

Oct 14 23:10:46 envy dhclient: DHCPREQUEST of 10.0.0.51 on wlan0 to 10.0.0.1 port 67
Oct 14 23:10:46 envy dhclient: DHCPACK of 10.0.0.51 from 10.0.0.1
Oct 14 23:10:46 envy NetworkManager: <info> DHCP: device wlan0 state changed bound -> renew
Oct 14 23:10:46 envy NetworkManager: <info> address 10.0.0.51
Oct 14 23:10:46 envy NetworkManager: <info> prefix 24 (255.255.255.0)
Oct 14 23:10:46 envy NetworkManager: <info> gateway 10.0.0.1
Oct 14 23:10:46 envy NetworkManager: <info> nameserver '217.13.7.140'
Oct 14 23:10:46 envy NetworkManager: <info> nameserver '217.13.4.24'
Oct 14 23:10:46 envy NetworkManager: <info> domain name 'lan'
Oct 14 23:10:46 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Oct 14 23:10:46 envy dhclient: bound to 10.0.0.51 -- renewal in 2735 seconds.
Oct 14 23:10:46 envy avahi-daemon[5342]: Withdrawing address record for 10.0.0.51 on wlan0.
Oct 14 23:10:46 envy avahi-daemon[5342]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51.
Oct 14 23:10:46 envy avahi-daemon[5342]: Interface wlan0.IPv4 no longer relevant for mDNS.
Oct 14 23:10:46 envy avahi-daemon[5342]: Joining mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51.
Oct 14 23:10:46 envy avahi-daemon[5342]: New relevant interface wlan0.IPv4 for mDNS.
Oct 14 23:10:46 envy avahi-daemon[5342]: Registering new address record for 10.0.0.51 on wlan0.IPv4.
Oct 14 23:10:47 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Oct 14 23:10:47 envy NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS.
Oct 14 23:12:36 envy nm-openvpn[23085]: [openvpn-gw.employer.no] Inactivity timeout (--ping-restart), restarting
Oct 14 23:12:36 envy nm-openvpn[23085]: SIGUSR1[soft,ping-restart] received, process restarting
Oct 14 23:12:38 envy nm-openv...

Could you please test the uploads to intrepid i did today? There
should be some fixes surrounding routing+vpn in them

The version to test is: 0.7~~svn20081015t024626-0ubuntu1

Thanks!

On Tue, Sep 23, 2008 at 08:53:01PM -0000, Michael Flaig wrote:
> I can confirm this and reopend my Ticket #271547 accordingly, too.
> So if a default gateway is set through dhcp it get replaced by openvpn (started via init script) but not by network-manager-openvpn.
>
> For DNS there is also another Bugreport, that I created: #271542 for network-manager
> In my case the DNS Server doesn't get set correctly, when connecting to the wifi network and getting the nameserver information from dhcp. However nameserver does get set correctly after nm-openvpn connected (after I added explicit DNS Options to the openvpn-server configuration, of course)

 - Alexander

Okay, did a test. Package versions:

libnm-glib0 0.7~~svn20081015t024626-0ubuntu1
libnm-util0 0.7~~svn20081015t024626-0ubuntu1
network-manager 0.7~~svn20081015t024626-0ubuntu1
network-manager-gnome 0.7~~svn20081015t194645-0ubuntu1
network-manager-openvpn 0.7~~svn20081015t024626-0ubuntu1

After activating the tunnel (I deleted and re-created the config, so now there's no static routes configured anymore), the routing table looks like this:

VPN-GATEWAY via 10.0.0.1 dev wlan0 proto static
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.0.1 via 10.8.0.5 dev tun0 proto static
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
default via 10.0.0.1 dev wlan0 proto static

So the default route is still pointing to the residental CPE device, and not the OpenVPN tunnel (which would then have been "dev tun0"). In other words, the bug is still present. There's an improvement there, though, the route to 10.8.0.1 is back where it should be. resolv.conf still looks good.

I haven't stayed on for long enough to tell if the host route to VPN-GATEWAY will survive a DHCP lease renewal. I'll let you know how it goes when I return from work.

A potential interesting log snippet:

Oct 16 07:38:54 envy NetworkManager: <info> VPN connection 'Work (added in GNOME)' (IP Config Get) complete.
Oct 16 07:38:54 envy NetworkManager: <WARN> nm_system_replace_default_ip4_route(): replace_default_ip4_route() returned error Success (0)
Oct 16 07:38:54 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf

Regards,
Tore

Okay, I can confirm that the host-route to the VPN gateway is still removed after DHCP lease removal, breaking the tunnel. I also noticed that the link-local route to 169.254/16 is also removed then (not sure what added it in the first place).

Tore

ok. could you please file this bug in bugzilla.gnome.org and give us the bug id so we can track it and subscribe to it. Will talk to the NM maintainer then. Thanks.

I found a bug already submitted to bugzilla.gnome.org by someone else, seems to be about the same problem:

http://bugzilla.gnome.org/show_bug.cgi?id=552594

Tore

Oh, by the way - should I open a separate bug report for the issue where DHCP lease renewal nukes the host-route to the VPN gateway that's necessary for the tunnel to work if the VPN gateway resides within a tunneled prefix (like the default route)?

The resolv.conf issue seems fixed, though. I'll update the title of this bug report.

Tore

yes, please use the gnome bug for the title. file a new bug for other issues left and give us the bug id please.

Tore,

please file a bug for that "DHCP lease renewal nukes the host-route". You seem to be able to explain what happens. :)

Setting a "static IP" is of course a workaround, but maybe not so good on laptops.

/ Magnus

Magnus,

I'll submit a new bug, once I can confirm that it's not OpenVPN specific. At least I suspect that the DHCP lease renewal will nuke the link-local 169.254.0.0/16 route regardless of OpenVPN being in use or not. OpenVPN is just hit harder due to the fact that the host route is absolutely necessary for VPN to work if the VPN-gateway resides within one of the networks routed inside the tunnel, but it would probably just be an incarnation of the same bug which is basically bad handling of DHCP renewals. However I'll have to wait some hours for the DHCP lease to expire first. :-)

Alexander,

there was some activity in the GNOME bug tracker, and a setting called «Ignore automatically obtained routes» was mentioned. It defaults to off, which is what I would want it to be (or so I thought), but out of curiousity, I tried to enable that setting, and surprisingly enough - now it works! So the logic is incorrectly reversed in the NM-openvpn code that handles that setting - if you ask it to ignore the VPN server routes, NM-openvpn will respect them, and vice verca. The NM developer commenting there said that « [y]ou also must have at least NM svn r4181 or later as well as NetworkManager-openvpn r4170 or later», so maybe the bug is already fixed upstream. (I'm not sure though, his comment was to me a bit unclear in some places).

Michael & JB: Can you confirm that enabling «Ignore automatically obtained routes» (you'll find it in IPv4 Settings -> Routes... in the config editor) causes the default route to be installed as expected?

Tore

FYI: I'm seeing the "DHCP lease renewal nukes the host-route" with vpnc.

Allright, bug filed (#288703). I subscribed you, Magnus.

Tore

On Thu, 2008-10-16 at 00:20 +0000, Alexander Sack wrote:
> Could you please test the uploads to intrepid i did today? There
> should be some fixes surrounding routing+vpn in them
>
> The version to test is: 0.7~~svn20081015t024626-0ubuntu1
>
> Thanks!

sorry, still no luck. default gateway does not get replaced correctly
with the address of the openvpn gateway.

- mike

--
Michael Flaig <email address hidden>
PROLinux.de

Fixed (or at least, workaround added) upstream. From GNOME's bug tracker:

> ------- Comment #13 from Dan Williams 2008-10-26 15:48 UTC -------
> svn r4212 will ignore /32 vpn-provided routes when determining whether the VPN
> connection should be the default route.

Hurry hurry, and hopefully the fix will be included with Intrepid. :-)

Tore

I'm not sure because I don't know exactly what was the command-line in Hardy, but the bug seems to come from nm-openvpn invoking the openvpn client with the --route-noexec option

When "Ignore automatically obtained routes" is ticked on, nm-openvpn sets the default route (as set up by "redirect gateway") correctly. But in this case all other routes (as set up by "route a.b.c.d w.x.y.z") are ignored.

With the above setting ticked off, the "normal" routes are set while the default route isn't.

same problem here, default gateway does not get redirected.

Beside, I think there should be some user feedback if the tunnel is not used as default gw. By now the network-manager-icon indicates that the tunnel is active, but if the default gateway is not set the right way it is (nearly) never used.

I would like to know if my default route is going through the tunnel or not, its not nice to see a lock as the VPN indicator not knowing what the real status is.

I think "Ignore automatically obtained routes" is just a wrong description
It should be something like "Use routes from VPN server" or something like that, since pulling the routes from the server would be an "automatically obtained route".
Also, this should be defaulted to on, since it's what most users want.

Xamusk,

it sounds weird, but the _real_ bug here is that OpenVPN does not pass the default route to NetworkManager. It only passes some /32-routes that's the link networks used by the OpenVPN server (given by the "server" statement in the server configuration file). There is as far as I've understood _no_ way for NetworkManager to detect that the server is using "redirect-gateway" or not. But this bug is, as I've understood it, in OpenVPN - not NetworkManager.

NetworkManager works around it, though. If the OpenVPN server does not push _any_ routes at all, NM figures that "since OpenVPN doesn't advertise any routes at all, I'm going to assume that it wants the default route, since a VPN tunnel with no routes to it is quite pointless". That's how it should look to NM if only redirect-gateway is in use... only that it doesn't. This workaround didn't take into account that the OpenVPN server (or client, I'm not sure) also announces a /32-route to the OpenVPN server's link network, regardless of this being configured in the server or not. So you end up in the situation where NM says "oh look, it told me to route these /32s over the tunnel, no need to apply the if-no-routes-then-set-default-route workaround then", and only the /32s are added.

It was fixed upstream, by simply making the workaround code disregard /32s when deciding to assume that the default route should be added or not. So when you set «Ignore automatically obtained routes», you do indeed make NM ignore those /32s, which in turn makes it apply the workaround since it can't see any routes at all. If you however add your own static routes in addition to setting the «ignore» option, you'll probably see that the default route is _not_ added (since these routes prevent the workaround to come into effect).

I hope that cleared it up - I was confused about the same at first, too. See the GNOME bug tracker for more comments from the upstream developer.

Tore

OK, I understood all workarounds going back-and-forth, but it's pretty strange that all those are needed, because invoking openvpn manually gets all routes right. As you said, it's probably the openvpn>nm route passing, but if the problem lies in openvpn, why did it work fine before nm 0.7?

Xamusk,

the OpenVPN client knows that redirect-gateway is in use, the bug is that it does not tell NetworkManager about it when running as a NM service (instead of standalone).

I don't know what changed that caused it to break, though. It could be that OpenVPN used to tell NM about the default route before, which means there would have been no need for the workaround, or that the code in NM got changed and accidentally broke. Or something else entirely, I don't know. Doesn't really matter, though, as it is fixed upstream and all that remains is for the fix to make it's way into Ubuntu's downstream packages.

Tore

Did not understand, at the very end, if this bug is going to be fixed and where.
I cannot use anymore my VPN connection. I can for example reach via HTTP the company's intranet pages but I cannot reach anymore my email POP server.

This is still unfixed.

I'm also affected by this problem on Intrepid. No default route is created after stablishing the openvpn connection. Launching openvpn by hand works well. The old nm from hardy was working well too.

I think is a nm problem, because openvpn directly works well.

There is also a problem with the nm routes configuration. When I try to add a 0.0.0.0 default route to the nm tunnel config, it's never saved. If I open again the routes, the list is empty. So setting routes by hand is not a workaround for this problem.

I believe clicking the "ignore automatically obtained routes" checkbox is an effective workaround until the new nm packages are released addressing this bug.

Any idea when this is getting fixed? Still a problem here, my VPN is effectively broken.

Hello all,

Was facing the same "issues" ... But now, reading all the comments, I'm starting to think it is no issue at all : it's not a bug, it's a feature :-)

Put simply :
- Either you need specific routes through your VPN, then it means you obviously want to keep your client's default route through its local interface,
- Or, you need your client's default route to be via the VPN, then there is no need to specifically set the other routes via the VPN ... as the VPN is the default route...

So finally I am very happy with the way the network-manager works for the moment : I need to decide where my default route would go through, and only configure alternate routes.
If these are not through the VPN, I configure them in the local interface. If they are through the VPN, I configure them in the VPN interface and the VPN client adds the routes pushed from the server.

Now, I have to admit the the "Ignore automatically obtained routes" is really really really misleading !!!!
Hope this helps.

No, network manager is wrong doing.

By default network-manager should accept the routes told by the vpn server. If the vpn server is telling the client that the default route should be through the tunnel, nm should obey it. Of course it's great that you could override the configuration sent by the vpn server, but the problem here is that nm is not following the configuration sent by the server.

My openvpn server is configured with:
redirect-gateway def1
This should add a default gw through the tunnel, with higher priority than the already present default gw. Network Manager is not adding on Intrepid. It was working properly on Hardy.

Also nm is not able to remember any manual route added to the configuration.

This bug was found in the Intrepid development cycle; removing regression-potential and marking as regression-release.

Steve Beattie wrote:
> This bug was found in the Intrepid development cycle; removing
> regression-potential and marking as regression-release.
>
>
please test the latest from network-manager team PPA ... those ship the
final 0.7 bits which have some routing improvements.

I can confirm this bug still exists in intrepid with the following ppa:

deb http://ppa.launchpad.net/network-manager/ubuntu intrepid main

Default route does not get used from openvpn server when given under networkmanager, but does from openvpn client on commandline. Tunnel only works as long as DHCP lease.

#dpkg -l | grep libnm\\\|network-manager\\\|openvpn
ii libnm-glib0 0.7-0ubuntu1~nm1~intrepid1 network management framework (GLib shared li
ii libnm-util0 0.7~~svn20081018t105859-0ubuntu2~nm4 network management framework (shared library
ii libnm-util1 0.7-0ubuntu1~nm1~intrepid1 network management framework (shared library
ii network-manager 0.7-0ubuntu1~nm1~intrepid1 network management framework daemon
ii network-manager-gnome 0.7-0ubuntu1~nm1~intrepid1 network management framework (GNOME frontend
ii network-manager-openvpn 0.7-0ubuntu1~nm1~intrepid network management framework (OpenVPN plugin
ii openvpn 2.1~rc11-1ubuntu2 virtual private network daemon
ii openvpn-blacklist 0.3 list of blacklisted OpenVPN RSA shared keys

This Bug is not fixed jet. (Release 0.7-0ubuntu1)

n-m-openvpn passes --route-noexec and --up /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper to openvpn.

nm-openvpn-service.c:
--
 /* do not let openvpn setup routes, NM will handle it */
        add_openvpn_arg (args, "--route-noexec");
--
If the openvpn is up, i have two default gateways and btw. old an new nameservers in /etc/resolv.conf. The NM doesn't remove the old default gateway and the old nameservers.

Doesn't work yet for me. Right now I'm in debian (as I have tons of troubles with the wifi since intrepid) but I have my installation replicated and functional in jaunty, both of which share the home. Packages are the same: 0.7.0ubuntu1 and 0.7.0-1 in debian's case.

Trouble in my case is that the server pushes a route, *but* the client sets it as the default one. I've tried the four combinations among "automatic (VPN) / Only automatic addresses (VPN)" and the "ignore automatically obtained routes" toggle. In *all* of them the default route is changed to "default via 10.8.0.5 dev tun0 proto static" with no other defaults, so it breaks for me as I get disconnected (which I don't want: I just want to add an *extra* route to the VPN, which works).

Server logs:

2009-02-04T00:16:42.341625+01:00 localhost openvpn[24587]: Soporte_desde_el_port_xC3_xA1til/192.168.0.1:55916 PUSH: Received control message: 'PUSH_REQUEST'
2009-02-04T00:16:42.341798+01:00 localhost openvpn[24587]: Soporte_desde_el_port_xC3_xA1til/192.168.0.1:55916 SENT CONTROL [Soporte_desde_el_port_xC3_xA1til]: 'PUSH_REPLY,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

Correct, it pushes the route but has *not* a redirect-gateway directive.

If I do it by hand on the cli it works as well:

Wed Feb 4 00:24:56 2009 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Feb 4 00:24:56 2009 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Wed Feb 4 00:24:56 2009 OPTIONS IMPORT: timers and/or timeouts modified
Wed Feb 4 00:24:56 2009 OPTIONS IMPORT: --ifconfig/up options modified
Wed Feb 4 00:24:56 2009 OPTIONS IMPORT: route options modified
Wed Feb 4 00:24:56 2009 ROUTE default_gateway=192.168.0.1
Wed Feb 4 00:24:56 2009 TUN/TAP device tun0 opened
Wed Feb 4 00:24:56 2009 TUN/TAP TX queue length set to 100
Wed Feb 4 00:24:56 2009 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Wed Feb 4 00:24:56 2009 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5
Wed Feb 4 00:24:56 2009 Initialization Sequence Completed

which *leaves* as is my default route.

Am I esentially misunderstanding this, or there *should* be a way of doing what I want? Intuitively, "accept routes" but "only automatic address" should add a route to the VPN but (as only automatic addresses are being used) should keep the default route untouched.

I too have the same problem. nm-openvpn doesn't handle the 'redirect-gateway' openvpn setting correctly, it uses --route-noexec by default

Here is the `ps` when connected through nm-openvpn

"/usr/sbin/openvpn --remote remote.server.domain.tld --comp-lzo --nobind --dev tun --proto tcp-client --port 1194 --syslog nm-openvpn --script-security 2 --up /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper --up-restart --persist-key --persist-tun --management 127.0.0.1 1194 --management-query-passwords --route-noexec --client --ca /path/to//openvpn.ca.crt --cert /path/to/openvpn.client.crt --key /path/to/openvpn.key"

@Leprechaun: There must be more to it than that, because I see exactly the same options for openvpn in the 'ps' output for openvpn, but with a *working* redirect.

As has been mentioned in some previous comments, I found that setting the option "Ignore automatically obtained routes" sets the local route correctly.

It appears as if the sense of this option has been reversed. Without that option set, the routing table changes are not made on the client.

You're exactly right. Out of all the options, that's the one i didn't
bother trying, who knows why :P

On Fri, 2009-04-10 at 18:21 +0000, davee wrote:
> @Leprechaun: There must be more to it than that, because I see exactly
> the same options for openvpn in the 'ps' output for openvpn, but with a
> *working* redirect.
>
> As has been mentioned in some previous comments, I found that setting
> the option "Ignore automatically obtained routes" sets the local route
> correctly.
>
> It appears as if the sense of this option has been reversed. Without
> that option set, the routing table changes are not made on the client.
>

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug is still marked as confirmed in later versions of Ubuntu.

Currently using natty and the default route is correctly replaced when the tunnel comes up.
Ignore automatically obtained routes does not have to be set

Marking Fix Released; behavior depends on whether "Use this connection only for the resources on its network".

Hi,
this is my first comment on launchpad.
I'm using Ubuntu 10.10 Maverick Meerkat, and this bug also occurs on my system. When checking "ignore autmatically obtained route" and "use this connection only for the resources on its network", the traffic for the vpn is routed through it to my company, while the internet-traffic is routed via my own vpn gateway. rout -n prints the following:

route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
134.91.225.10 10.0.0.1 255.255.255.255 UGH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 tap0
10.0.0.0 0.0.0.0 255.0.0.0 U 1 0 0 eth0
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0

(as can be seen, 0.0.0.0 is routed via eth0)

if one or both of the checkboxes is not checked, the route looks like the following:

route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
134.91.225.10 10.0.0.1 255.255.255.255 UGH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 tap0
10.0.0.0 0.0.0.0 255.0.0.0 U 1 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tap0

(here, 0.0.0.0 is routed via tap0, but with no gateway assigned.)
This does not work, as the only traffic possible is the internal traffic my companys network.

As well, setting a route manually in the vpn-config dialogue does not work, as it forgets the route when closing the dialogue.
So i found no possibility to route my internet-traffic through the VPN.

Hitting this here too.