In n-m-openvpn, "Ignore automatically obtained routes" does the opposite

This should be easy enough to add. I'll see what I can do (tomorrow or thereabouts).

Thanks for your bug reports!

What is the status, about this bug? Will network-manager in feisty support the pull option? It would be very important for me and, I guess for a lot of other people. Can we help?

Soren Hansen is currently working on it, he's already updated the GUI and added the option and did a good part of the code thing (actually there is still a small problem with NetworkManager overwriting the routes just after the --pull option set them).

On Thu, Mar 15, 2007 at 08:06:03AM -0000, Manuel Zach wrote:
> What is the status, about this bug? Will network-manager in feisty
> support the pull option? It would be very important for me and, I guess
> for a lot of other people. Can we help?

I've been working on it, but had a big exam today I had to prepare for.
I'm back at full throttle now. :-) Watch this space for more info. :)

I think my problem is the same as this bug, when I use push "redirect-gateway def 1" it fails to change the default gateway.

I see the following error in syslog:
nm-openvpn[22655]: ERROR: Linux route add command failed: shell command exited with error status: 7

I was going to report this on the NM List but I wanted to make sure that this wasn't a Ubuntu specific issue.

Thanks!

Sorry I just saw Stephane's comment that Soren was working on this and Soren's follow-up. I had bookmarked this bug a couple of days ago to comment on it and should have checked for updates when I came back!

Thank you Soren!

Just a quick note, this is also affecting me, as the server pushes through a couple of routes that are needed to make it work. When started through nm-applet, the route looks like:
Destination Gateway Genmask Flags Metric Ref Use Iface
222-154-246-45. DD-WRT 255.255.255.255 UGH 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
default DD-WRT 0.0.0.0 UG 0 0 0 eth1

where 192.168.1.0 is the VPN network.

However, when connected with openvpn itself, it looks like:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.33 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.33 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 10.8.0.33 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

where the 10.8 network is the 'connecting' VPN network.

The same problem as described by Eythian makes networkmanager-openvpn unusable to me. I cross my fingers for 'pull' support that should be really useful.

Thank you Soren!

Same Problem here with the WLAN of my university. Hope this support is coming soon.

Hello world! my first post on launchpad :)
I've got exact the same problem. I still use openvpn from terminal, it's ok for me but not for my users :(

One more question here - does NM support static routes?
I will be testing NM PPTP plugin soon. I used to set em(static routes) up manualy.
maybe NM will do the magic without me at all :)

Hello all,

I tried to find the problem, because the option --pull is set! If you execute ps aux after starting the vpn connection you will see that this is started:

/usr/sbin/openvpn --remote openvpn.rus.uni-stuttgart.de --comp-lzo --nobind --dev tun --proto udp --port 1194 --cipher AES-256-CBC --syslog nm-openvpn --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 --client --ns-cert-type server --ca /home/....cacert.pem --cert /home/....clcert.pem --key /home/...key.pem --auth-user-pass

The option --client is a alias for --pull, so that is not the problem. When I replace openvpn with a sh script that start openvpn without the --up /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper and --up-restart options it works! But Networkmanager don't get a feedback and said that the openvpn connection failed.
I believe that the problem is hidden in the nm-openvpn-service-openvpn-helper. Maybe it helps to find a solution.

Adding the option --route-delay 15 on the openvpn command, fix this bug for me. When a route is push it will be executet after the Networkmanager, and will be not overwritten as before. If no route is pushed nothing happen.

But there is still a problem ( Bug #96260 ). Networkmanager removes the old nameserver from the /etc/resolve.conf even when no dns server. In this case you can't resolve domains.

Same problem. Anyhow invoking the command (and args ) unmodified as if NetworkManager would in a root terminal works fine:

usr/sbin/openvpn --remote VPN_SERVER_ADDR --comp-lzo --nobind --dev tap --proto tcp-client --port 1194 --syslog nm-openvpn --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 --client --ns-cert-type server --ca CA_PATH --cert CERT_PATH --key KEY_PATH

I also tried MIchael Trunner's version in a root terminal, works, too:

usr/sbin/openvpn --remote VPN_SERVER_ADDR --comp-lzo --nobind --dev tap --proto tcp-client --port 1194 --syslog nm-openvpn --persist-key --persist-tun --management 127.0.0.1 1194 --management-query-passwords --client --ns-cert-type server --ca CA_PATH --cert CERT_PATH --key KEY_PATH

The problem is that networkmanager overwrites the routes from openvpn. So both commands are wokring as root, because networkmanager do nothing in this case.
My fix is that networkamanger configures his settings and 15 seconds later openvpn overwrites the settings from networkmanger, (when there is some route to set).

Hi,

that fixed it for me. I made a patch for the deb.

1. $ sudo apt-get build-dep network-manager-openvpn
2. $ apt-get source network-manager-openvpn
3. place the patch file in debian/patches
4. $ sudo debuild -us -uc

Install the new package. Hope it helps.

Sorry, but I must revoke the patch, because the routing commands are in a wrong order with this patch.
It only works with some VPNs, but not with all.

Is there away to delete his own stupid comments? :-/

Forget about that it isn't working. It was my own fault. It's working for me :-)

I am not able to connect using the network manager. I am getting the following error

Could not start the vpn connection xxxx due to a connection error
The VPN login failed because the VPN program could not connect to the VPN server.

The exported .pcf file
[openvpn]
description=My Office
connection-type=x509
remote=<XXXXIP ADDRESSXXXX>
port=1194
dev=tap
proto=tcp-client
ca=/home/prasanth/configfiles/cacert.pem
cert=/home/prasanth/configfiles/ntbk-pullatti.crt
key=/home/prasanth/configfiles/ntbk-pullatti.key
comp-lzo=yes
shared-key=
local-ip=
remote-ip=
username=
cipher=
ta=
ta_dir=
routes=

I am able to connect properly running the /usr/sbin/openvpn -config <file> from the command shell
the working .ovpn looks like this
remote <XXXXIPADDRESSXXX> #original ip masked
dev tap
tls-client
ca cacert.pem
cert ntbk-pullatti.crt
key ntbk-pullatti.key
pull
ping 10
ping-restart 60

# enable LZO compression (only if server and all clients can do this!)
comp-lzo

# moderate verbosity
verb 4
mute 10

# notify server when stopping openvpn
explicit-exit-notify 2

port 1194

Can somebody tell me what I am doing wrong here. I tried the patch also

Same for me :-/ I must use openvpn configuration for having right routes.

Does it only not work with my patch?
Is it working with the orginal ubuntu package or only with the command line?
Have you choose the right auth in the options? Do you need to enter a username and a password with openvpn at the commandline?

It is not working with the original package also.
It only works with the command line.
I think I have the right auth options, did u find any problems with the config files I posted (the .ovpn is the one I use in both windows and from linux command shell)
I don't enter username/password from commandline, I just pass the config file as the command line parameter

Sorry but that's a other bug. Please open a new one :-)
But no, I found no problem with your configs.

BTW, there seems to be a general problem on Linux with pulling dns settings, at least according to this: http://openvpn.net/howto.html#dhcp
Could that be related?

Michael Trunner
Since this works only for some routes, as you have stated, could you make a patch that would work for everybody? I am not a coder so I cannot make it myself...

Yes it's in a other order but thats no problem! My problem that i tolded was a diffrent.

To patch nm you have to change the complete system!
 And because of problems with wpa-eap, I don't use nm anymore.

Oh, I see, I misread what you said before. I will try this.
As for the EAP, it seems there is a patch upstream that makes it work now: http://mail.gnome.org/archives/networkmanager-list/2007-June/msg00055.html

No my Problem is that nm tries every encryption method and did not use one that the access-point him told or that I configured.

Unassign Soren. He is currently not continuing his work on this feature because there is a lot more work involved behind the scenes to make it running.

The problem is that network-manager-openvpn is unable to correctly pull the routes pushed by the endpoint. Is this correct?

The plugin is able to pull other settings just fine.

Yes that was the problem

On 9/24/07, Philipp Kern <email address hidden> wrote:
> The problem is that network-manager-openvpn is unable to correctly pull
> the routes pushed by the endpoint. Is this correct?
>
> The plugin is able to pull other settings just fine.
>
> ** Summary changed:
>
> - [Feisty] NetworkManager OpenVPN doesn't have a pull option
> + [Feisty] n-m-openvpn fails to pull routes
>
> --
> [Feisty] n-m-openvpn fails to pull routes
> https://bugs.launchpad.net/bugs/88069
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I can confirm that the problem with the routes not (or false) being propagated still exists on gutsy.

I get for example the following route propagated:

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tap0

instead of:

0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 tap0

(which works well with if I use openvpn with the daemon).

would be nice to fix this, as otherwise the plugin is not yet finally ready to use. Thanks for all the work.

Same Problem to me.
There are no pulls for routes and also my resolv.conf is empty after connection to a VPN Server.

Would be great, if this will be fixed, because the Network Manager Plugin is a cool tool.

I'm register now and this is my first post.
Does any moves this network-manager? A really need working OpenVPN with this plugin...

Hi!

For me this is also a must-have feature. It would really simplify the process of securely surfing in public WLANs.

Thanks
Kevin

When I use the following in my server.conf
push "redirect-gateway def1"

I am able route all but my local subnet down the tunnel.

I know this doesn't solve the problem for those that want to route just a specific subnet but for those who want to use the openvpn plugin to protect their traffic when on a public wifi network this should work.

This Problem is still not fixed for me:

Using OpenVPN over NetworkManager

$ route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
3-063.dsl.cyber 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.2.0 * 255.255.255.0 U 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
link-local * 255.255.0.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 vnet0
default 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
default * 0.0.0.0 U 1000 0 0 eth0

Using "native" OpenVPN Client

$ route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.10.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.10.1 192.168.10.5 255.255.255.255 UGH 0 0 0 tun0
192.168.2.0 192.168.10.5 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
link-local * 255.255.0.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 vnet0
default 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
default * 0.0.0.0 U 1000 0 0 eth0

Any solutions out there? OpenVPN with NetworkManager would be finally usable, if this would be fixed...

It won't work for me, too.

with native command, the route table looks like this

seen@seen-desktop:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
129.69.244.1 129.69.245.137 255.255.255.255 UGH 0 0 0 tun0
129.69.245.137 * 255.255.255.255 UH 0 0 0 tun0
openvpn.rus.uni DD-WRT 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 129.69.245.137 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 129.69.245.137 128.0.0.0 UG 0 0 0 tun0
default DD-WRT 0.0.0.0 UG 0 0 0 eth0

with network-manager-openvpn, it changes to

seen@seen-desktop:/etc/openvpn$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
129.69.90.133 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
link-local * 255.255.0.0 U 1000 0 0 eth0
default * 0.0.0.0 U 0 0 0 tun0

and of course the second one won't work, it lacks of the other route definition similar to the first one.

sorry forget to name my spec.

xubuntu 7.10 amd64

and check out the native openvpn connection log, it lacks of the part of adding new route definitions.

Wed Apr 9 10:30:12 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Wed Apr 9 10:30:12 2008 LZO compression initialized
Wed Apr 9 10:30:12 2008 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Apr 9 10:30:12 2008 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Apr 9 10:30:12 2008 Local Options hash (VER=V4): '22188c5b'
Wed Apr 9 10:30:12 2008 Expected Remote Options hash (VER=V4): 'a8f55717'
Wed Apr 9 10:30:12 2008 UDPv4 link local: [undef]
Wed Apr 9 10:30:12 2008 UDPv4 link remote: 129.69.90.133:1194
Wed Apr 9 10:30:12 2008 TLS: Initial packet from 129.69.90.133:1194, sid=54baea99 96dfaa2f
Wed Apr 9 10:30:12 2008 VERIFY OK: depth=1, /C=DE/ST=BW/L=Stuttgart/O=Universitaet_Stuttgart/OU<email address hidden>
Wed Apr 9 10:30:12 2008 VERIFY OK: nsCertType=SERVER
Wed Apr 9 10:30:12 2008 VERIFY OK: depth=0, /C=DE/ST=BW/O=Universitaet_Stuttgart/OU<email address hidden>
Wed Apr 9 10:30:12 2008 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Apr 9 10:30:12 2008 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 9 10:30:12 2008 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Apr 9 10:30:12 2008 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 9 10:30:12 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Wed Apr 9 10:30:12 2008 [openvpn.rus.uni-stuttgart.de] Peer Connection Initiated with 129.69.90.133:1194
Wed Apr 9 10:30:13 2008 SENT CONTROL [openvpn.rus.uni-stuttgart.de]: 'PUSH_REQUEST' (status=1)
Wed Apr 9 10:30:13 2008 PUSH: Received control message: 'PUSH_REPLY,route 129.69.244.1,ping 10,ping-restart 120,redirect-gateway def1,echo +-------------- important notes --------------+,echo |,echo | - this box will be used to deliver,echo | important notes to you,echo |,echo +----------------- sincerely your vpn-admin --+,ifconfig 129.69.245.138 129.69.245.137'
Wed Apr 9 10:30:13 2008 ECHO:+-------------- important notes --------------+
Wed Apr 9 10:30:13 2008 ECHO:|
Wed Apr 9 10:30:13 2008 ECHO:| - this box will be used to deliver
Wed Apr 9 10:30:13 2008 ECHO:| important notes to you
Wed Apr 9 10:30:13 2008 ECHO:|
Wed Apr 9 10:30:13 2008 ECHO:+----------------- sincerely your vpn-admin --+
Wed Apr 9 10:30:13 2008 OPTIONS IMPORT: timers and/or timeouts modified
Wed Apr 9 10:30:13 2008 OPTIONS IMPORT: --ifconfig/up options modified
Wed Apr 9 10:30:13 2008 OPTIONS IMPORT: route options modified
Wed Apr 9 10:30:13 2008 TUN/TAP device tun0 opened
Wed Apr 9 10:30:13 2008 ifconfig tun0 129.69.245.138 pointopoint 129.69.245.137 mtu 1500
Wed Apr 9 10:30:13 2008 route add -net 129.69.90.133 netmask 255.255.255.255 gw 192.168.1.1...

Hi there...

Just a BUMP....

I can confirm that this bug is still present on Ubuntu 8.04 (hardy), running nm-applet 0.6.6.

Does anyone know if there are any prediction on resolving this issue?

Is there a workaround, or do you recommend other client?

As for now I'm running openvpn in the cli.

Is there another applet that manages networks, wifi and vpns?

Thanks

This is solved in Intrepid, due to network-manager 0.7.

I have been running Intrepid Beta for some days now and connect to serveral different VPNs (albeit only one at a time, network-manager does not allow more than 1 connection).

It has never failed on me, always pulls the correct routes.

It's a leap forward in ease of use.

Closing as Fix released based on latest comment. Please reopen if you still have the problem with the latest NM 0.7 in intrepid.

Using intrepid with NM 0.7.0.
NM sets up a default gateway but it shouldn't.
Routes with OpenVPN/NM (works not):
78.47.23.201 192.168.220.1 255.255.255.255 UGH 0 0 0 eth0 <-- remote vpn server address
10.23.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 <-- network inside vpn
192.168.220.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 <-- my local net
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tap0

Routes with OpenVPN CLI (works):
10.23.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.220.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.220.1 0.0.0.0 UG 0 0 0 eth0 <-- the default gateway that i actually want

I'm not sure whether this is a configuration issue but I believe it's this bug still being there.

I managed to pull my routes going to, in the NM connection manager:
IPv4 Settings > Routes... > Ignore automatically obtained routes

I think the real bug is that that option description is written as the opposite of what the user wants.

I have to confirm that checking of "IPv4 Settings > Routes... > Ignore" flag in NM correctly sets all routes as required and VPN works like a charm :-)

I marked it as confirmed and updated the description of the bug as it has changed, I hope someone will correct it, it seems it should be fairly easy.

Hm, I found out this has already been reported, as the other bug report seems to have more info, I am makring this one as a duplicate.

I am having the exact problem as described in Jan Kaessens comment.

openvpn works as a client via command line, but not using network-manager-openvpn. I see the additional entries as well when I use the command 'route' or 'ip r'

The following is what I get when running nm-openvpn plugin:

Destination Gateway Genmask Flags Metric Ref Use Iface
96.***.**.** 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tap0

* = my WAN IP

This restricts me to the VPN lan and I have no way to access anything else while nm-openvpn is running.