Arch Linux

networkmanager-openvpn 1.0.8-1? What version of openvpn?

Yes and openvpn 2.3.9-1.

I can reproduce the bug and I have the same problem. Error adding default or specific routes for IPv4 and IPv6:

NetworkManager[619]: (nm-openvpn-service:2599): nm-openvpn-WARNING **: (nm-openvpn-service.c:1269):nm_openvpn_start_openvpn_binary: runtime check failed: (priv->mgt_path == NULL)
NetworkManager[619]: (nm-openvpn-service:2599): nm-openvpn-WARNING **: Directory '/var/lib/openvpn/chroot' not usable for chroot by 'nm-openvpn', openvpn will not be chrooted.
NetworkManager[619]: <info> VPN plugin state changed: starting (3)
NetworkManager[619]: nm-openvpn-Message: openvpn started with pid 2971
NetworkManager[619]: <info> VPN connection 'inberlin-noir (all)' (ConnectInteractive) reply received.
NetworkManager[619]: Sat Dec 26 16:53:59 2015 DEPRECATED OPTION: --tls-remote, please update your configuration
NetworkManager[619]: <info> (tun0): new Tun device (carrier: OFF, driver: 'tun', ifindex: 14)
NetworkManager[619]: <info> VPN connection 'inberlin-noir (all)' (IP Config Get) reply received.
NetworkManager[619]: <info> VPN connection 'inberlin-noir (all)' (IP4 Config Get) reply received.
NetworkManager[619]: <info> VPN plugin state changed: started (4)
NetworkManager[619]: <info> VPN connection 'inberlin-noir (all)' (IP6 Config Get) reply received.
NetworkManager[619]: <info> VPN Gateway: 217.197.80.7
NetworkManager[619]: <info> Tunnel Device: tun0
NetworkManager[619]: <info> IPv4 configuration:
NetworkManager[619]: <info> Internal Gateway: 192.109.82.63
NetworkManager[619]: <info> Internal Address: 217.197.85.148
NetworkManager[619]: <info> Internal Prefix: 32
NetworkManager[619]: <info> Internal Point-to-Point Address: 192.109.82.63
NetworkManager[619]: <info> Maximum Segment Size (MSS): 0
NetworkManager[619]: <info> Static Route: 0.0.0.0/1 Next Hop: 192.109.82.63
NetworkManager[619]: <info> Static Route: 128.0.0.0/1 Next Hop: 192.109.82.63
NetworkManager[619]: <info> Forbid Default Route: no
NetworkManager[619]: <info> Internal DNS: 192.109.42.41
NetworkManager[619]: <info> Internal DNS: 192.109.42.42
NetworkManager[619]: <info> DNS Domain: '(none)'
NetworkManager[619]: <info> IPv6 configuration:
NetworkManager[619]: <info> Internal Address: 2001:67c:1407:1b0::1
NetworkManager[619]: <info> Internal Prefix: 64
NetworkManager[619]: <info> Internal Point-to-Point Address: 2001:67c:1400:1027::1
NetworkManager[619]: <info> Maximum Segment Size (MSS): 0
NetworkManager[619]: <info> Static Route: 2000::/3 Next Hop: 2001:67c:1400:1027::1
NetworkManager[619]: <info> Forbid Default Route: no
NetworkManager[619]: <info> DNS Domain: '(none)'
NetworkManager[619]: <warn> platform-linux: do-add-ip4-route: failure adding ip4-route '14: 0.0.0.0/1 50': Unspecific failure (1)
NetworkManager[619]: <warn> platform-linux: do-add-ip4-route: failure adding ip4-route '14: 128.0.0.0/1 50': Unspecific failure (1)
NetworkManager[619]: <warn> platform-linux: do-add-ip6-route: failure adding ip6-route '14: 2000::/3 50': Unspecific failure (1)
NetworkManager[619]: <info> VPN connection 'inberlin-noir (all)' (IP Config Get) complete.
NetworkManager[619]: <info> (tun0): link connected
NetworkManager[619]: <warn> platform-linux: do-add-ip4-route: failure adding ip4-route '14: 0.0.0.0/0 50': Unspecific failure (1)
NetworkManager[619]: <warn> default-route: failed to add default route 0.0.0.0/0 via 192.109.82.63 dev 14 metric 50 mss 0 src vpn with effective metric 50
NetworkManager[619]: <info> NetworkManager state is now CONNECTED_LOCAL
NetworkManager[619]: <info> NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[619]: <info> Policy set 'inberlin-noir (all)' (tun0) as default for IPv6 routing and DNS.
NetworkManager[619]: <info> Writing DNS information to /usr/bin/resolvconf
NetworkManager[619]: <info> keyfile: add connection in-memory (1cf1da67-95f1-4e0e-a741-d43e1351b689,"tun0")
NetworkManager[619]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[619]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[619]: <info> (tun0): Activation: starting connection 'tun0' (1cf1da67-95f1-4e0e-a741-d43e1351b689)
NetworkManager[619]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[619]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[619]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[619]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[619]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[619]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[619]: <info> Policy set 'tun0' (tun0) as default for IPv6 routing and DNS.
NetworkManager[619]: <info> (tun0): Activation: successful, device activated.

Last updates:
[2015-12-26 05:05] [ALPM] upgraded libnm-glib (1.0.8-1 -> 1.0.10-1)
[2015-12-26 05:05] [ALPM] upgraded nm-connection-editor (1.0.8-1 -> 1.0.10-1)
[2015-12-26 05:05] [ALPM] upgraded network-manager-applet (1.0.8-1 -> 1.0.10-1)
[2015-12-26 05:05] [ALPM] upgraded networkmanager (1.0.8-1 -> 1.0.10-1)
[2015-12-26 14:20] [ALPM] upgraded openvpn (2.3.8-2 -> 2.3.9-1)

I'm not sure but my VPN worked in the morning with openvpn-2.3.8-2 and the error occurred after upgrading openvpn to 2.3.9-1. More test's can be done later.


UPDATE:

Upgrading to openvpn-2.3.9-1 is not the problem. The problem to set ip4-routes is triggered by following updates:

extra/libnm-glib 1.0.8-1 -> 1.0.10-1
extra/networkmanager 1.0.8-1 -> 1.0.10-1
extra/network-manager-applet 1.0.8-1 -> 1.0.10-1
extra/nm-connection-editor 1.0.8-1 -> 1.0.10-1


I recognized a new problem with 1.0.8-1
NetworkManager[663]: <warn> platform-linux: do-add-ip6-route: failure adding ip6-route '7: 2001:bf0:c000::/35 50': Unspecific failure (1)
I haven't recognized that problem because "IPv6 -> Routes -> Use this connection only for resources on its network" was disables and therefore a default route is set.

Conclusion:
With networkmanager 1.0.8-1 IPv4 routes are working and IPv6 are not working. With 1.0.10-1 IPv4 and IPv6 routes do not work at all. That's independent of openvpn's version.

Exactly the same problem here.
VPN stopped working after the upgrade. "adding ip4-route" fails with "Unspecific failure (1)".

BTW, this is the 2nd time VPN is broken with updates in a few months in the "stable" branch. No one using VPN in testing?

Edit: I did downgrade openvpn and networkmanager-openvpn to their previous version, and the problem persisted.
Everything worked again after downgrading networkmanager and libnm-glib too.

confirmed here also.
routing restored leaving openvpn and networkmanager-openvpn updated and downgrade (networkmanager)s packages to 1.0.8-1

Same issue here, my VPN was working fine before the update, now it leaks my real IP.

Ditto re problem existing prior to openvpn 2.3.9-1. As mentioned, rolling back networkmanager, libnm-glib, and network-manager-applet to 1.0.8-1 restores normal behavior. Also, it seems a Fedora user reported something similar upstream: https://bugzilla.gnome.org/show_bug.cgi?id=759892

VPN fails for me on update as well.

Same here
rolled back to openvpn-2.3.8-2 networkmanager-1.0.8-1

WARNING:
I'm going to start deleting "Me Too!" type comments. If you don't have anything useful to add, don't.

This only occurs if I start an OpenVPN connection with the NetworkManager (GUI, didn't test CLI).

If I start an OpenVPN connection using systemd, routes are added correctly.

Simply reverting networkmanager back to 1.0.8-1 fixes, no others need be rolled back.

Using OpenVPN cli directly works perfectly, only when using NetworkManager is there a problem. (openvpn 2.3.9-1, NetworkManager 1.0.10-1)

I managed to make it work again after reverting http://cgit.freedesktop.org/NetworkManager/NetworkManager/patch/?id=df4e5357521d00f4d9bc746cb2f530d5617d3e2c

Any chance the cause is a mismatch between the networkmanager and networkmanager-openvpn packages? networkmanager has been updated to 1.10 but networkmanager-openvpn is still on 1.08

Sorry guys, i am quite a n00b...and i have same issue here with my vpn not showing new IP.

Please can you suggest best way to revert networkmanager from 1.0.10-1 to the 1.0.8-1 ??

Thax to all !!

@archspoilt pacman -U /var/cache/pacman/pkg/proper version..

Im mobile I can't provide an accurate link. I can confirm downgrading to 1.08 works

@ArchSploit Check out https://wiki.archlinux.org/index.php/Downgrading_packages

The downgrade script in AUR automates this but it's worth reading through that short wiki page first.

ok guys, sorry, but i just discovered that that in var/cache/pacman/pkg i have only the networkmanager-openvpn-1.0.8-1-x86_64.pkg.tar.xz and NOT the networkmanager. In fact, the latter is only available at version 1.0.1.-1
Any ideas where can i download the earlier version ?
Sorry and tx

Try downgrading both to 1.01?

sorry to be read networkmanager 1.0.10-1, i have NO networkmanager 1.0.8-1.

@archspoilt try this https://archive.archlinux.org/packages/n/networkmanager

Newbie here so I apologize if the following is not relevant or appropriate Bugtracker etiquette.

I have two stray observations:
1) This bug is particularly nasty because the failure is not immediately apparent. NM appears to connect to the VPN correctly and it's not immediately obvious that the VPN is not working properly.

This means a user may be exposing sensitive data on a connection they believe to be private and secure.

2) @pavanky, I had the same thought regarding the networkmanager 1.0.10-1 and networkmanager-openvpn 1.0.8-1 version mismatch. However, that appears to be latest versions available in upstream: http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-openvpn/1.0/

It may be worth noting that networkmanager-openvpn is listed as an Orphan in the Maintainer section of its package page.

Tx to all guys !!
I have downloaded from the above link provided by pavanky the right networkmanager version, added to bla/bla/pkg then downgraded accordingly via pacman -U

Then i did stop networkmanager.service, restarted it and ran the vpn, now the IP shows correctly !!

Tx Again !!

--

Can anyone clarify how to reproduce this bug?
I have networkmanager 1.0.10-1 and networkmanager-openvpn 1.0.8-1 on KDE4 (networkmanager plasma applet) and everything seems to work fine.
I'm using OpenVPN every day and all the time.

@ValdikSS for reference I am facing the issue with GNOME 3.18.3, networkmanager 1.0.10 and networkmanager-openvpn 1.0.8-1

Downgrading networkmanager to 1.0.8 seems to fix the issue.

BTW can you verify if your IP address is changing after connecting through VPN ? Because the failure to add routes is a silent one.

The original bug description says the problem occurs if the server pushes a default route. Although I see the same problem when the server pushes ANY route. NM fails to create entires in the client's routing table.

@pavanky sure I made sure everything is as good as it was on 1.0.8.
After connecting to the VPN, routing table has new default route over VPN and two routes 0.0.0.0/1 and 128.0.0.0/1 (a small networkmanager bug), just as in a previous version.
I don't have any special connection configuration.

To be more clear, I'm using IPv6 inside VPN too, and it also works fine just as in a previous version.

@ValdikSS: Pushing two routes 0.0.0.0/1 and 128.0.0.0/1 is not a bug it is a feature and done in many VPN setup: Your default route 0.0.0.0/0 is preserved. Traffic is routed over the more specific routes 0.0.0.0/1 and 128.0.0.0/1 - the two halves of the internet :-)

It's fixed in networkmanager git, please apply this patch:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=11aa07ed939193e85516c287a57dee1837242972

@sma i meant that networkmanager adds both 0.0.0.0/1 and 128.0.0.0/1 and a default route over vpn, this is a bug since it should not add default route. But it's there for ages and that's kinda ok.

I applied the patch on my personal system that AnAkkk linked to and it seems to solve the issue.

Seems that this bug is now solved with this updates :
- libnm-glib (1.0.10-1 -> 1.0.10-2)
- networkmanager (1.0.10-1 -> 1.0.10-2)

I can second that the issue is fixed with the latest update.