FS#47535 - [networkmanager] 1.0.10-1 openvpn plugin fails to add routes.

Attached to Project: Arch Linux
Opened by Armin Fisslthaler (afics) - Saturday, 26 December 2015, 13:44 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 06 January 2016, 14:42 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 40
Private No

Details

Description:
OpenVPN connections (which serve a default route) initiated via NetworkManager fail to add essential routes -> VPN does not work.

Downgrading to 1.0.8-1 is a possible workaround (not that you would want that).

Additional info:
* networkmanager 1.0.10-1
* log output
Dez 26 14:08:11 antares NetworkManager[1391]: <warn> platform-linux: do-add-ip4-route: failure adding ip4-route '5: 172.17.1.1/32 50': Unspecific failure (1)
Dez 26 14:08:11 antares NetworkManager[1391]: <info> VPN connection 'somename' (IP Config Get) complete.
Dez 26 14:08:11 antares NetworkManager[1391]: <info> (tun0): link connected
Dez 26 14:08:11 antares NetworkManager[1391]: <warn> platform-linux: do-add-ip4-route: failure adding ip4-route '5: 0.0.0.0/0 50': Unspecific failure (1)
Dez 26 14:08:11 antares NetworkManager[1391]: <warn> default-route: failed to add default route 0.0.0.0/0 via 172.17.1.17 dev 5 metric 50 mss 0 src vpn with effective metric 50

Steps to reproduce:
Connect to an OpenVPN server which pushes a default route to its clients.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 06 January 2016, 14:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  networkmanager 1.0.10-2
Comment by Doug Newgard (Scimmia) - Saturday, 26 December 2015, 14:42 GMT
networkmanager-openvpn 1.0.8-1? What version of openvpn?
Comment by Armin Fisslthaler (afics) - Saturday, 26 December 2015, 15:10 GMT
Yes and openvpn 2.3.9-1.
Comment by Andreas Herrmann (sma) - Saturday, 26 December 2015, 15:58 GMT
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.
Comment by raine (raine) - Sunday, 27 December 2015, 03:55 GMT
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.
Comment by Massimo Branchini (max.bra) - Sunday, 27 December 2015, 11:36 GMT
confirmed here also.
routing restored leaving openvpn and networkmanager-openvpn updated and downgrade (networkmanager)s packages to 1.0.8-1
Comment by Nick Mvh (Nikolay31) - Sunday, 27 December 2015, 23:19 GMT
Same issue here, my VPN was working fine before the update, now it leaks my real IP.
Comment by Po Schmo (poppyschmo) - Monday, 28 December 2015, 00:41 GMT
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
Comment by M.Reynolds (TheChickenMan) - Monday, 28 December 2015, 01:15 GMT
VPN fails for me on update as well.
Comment by Ksarv (Ksarv) - Monday, 28 December 2015, 15:01 GMT
Same here
rolled back to openvpn-2.3.8-2 networkmanager-1.0.8-1
Comment by Doug Newgard (Scimmia) - Monday, 28 December 2015, 15:07 GMT
WARNING:
I'm going to start deleting "Me Too!" type comments. If you don't have anything useful to add, don't.
Comment by Clemens (vibee) - Tuesday, 29 December 2015, 14:31 GMT
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.
Comment by Conker (oconkero) - Tuesday, 29 December 2015, 19:54 GMT
Simply reverting networkmanager back to 1.0.8-1 fixes, no others need be rolled back.
Comment by nope (siim555) - Saturday, 02 January 2016, 17:30 GMT
Using OpenVPN cli directly works perfectly, only when using NetworkManager is there a problem. (openvpn 2.3.9-1, NetworkManager 1.0.10-1)
Comment by Ionut Biru (wonder) - Sunday, 03 January 2016, 12:44 GMT Comment by pavan yalamanchili (pavanky) - Monday, 04 January 2016, 13:09 GMT
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
Comment by Guy Fawkes (ArchSploit) - Monday, 04 January 2016, 14:39 GMT
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 !!
Comment by pavan yalamanchili (pavanky) - Monday, 04 January 2016, 14:45 GMT
@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
Comment by Julio Gonzalez (inti) - Monday, 04 January 2016, 14:48 GMT
@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.
Comment by Guy Fawkes (ArchSploit) - Monday, 04 January 2016, 15:00 GMT
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
Comment by pavan yalamanchili (pavanky) - Monday, 04 January 2016, 15:01 GMT
Try downgrading both to 1.01?
Comment by Guy Fawkes (ArchSploit) - Monday, 04 January 2016, 15:03 GMT
sorry to be read networkmanager 1.0.10-1, i have NO networkmanager 1.0.8-1.
Comment by pavan yalamanchili (pavanky) - Monday, 04 January 2016, 15:04 GMT Comment by Julio Gonzalez (inti) - Monday, 04 January 2016, 15:20 GMT
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.
Comment by Guy Fawkes (ArchSploit) - Monday, 04 January 2016, 15:29 GMT
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 !!
Comment by Clemens (vibee) - Monday, 04 January 2016, 16:33 GMT
--
Comment by ValdikSS (ValdikSS) - Monday, 04 January 2016, 23:33 GMT
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.
Comment by pavan yalamanchili (pavanky) - Tuesday, 05 January 2016, 00:11 GMT
@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.
Comment by Rob Hasselbaum (Rob_H) - Tuesday, 05 January 2016, 00:14 GMT
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.
Comment by ValdikSS (ValdikSS) - Tuesday, 05 January 2016, 00:14 GMT
@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.
Comment by Andreas Herrmann (sma) - Tuesday, 05 January 2016, 00:27 GMT
@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 :-)
Comment by AnAkkk (AnAkkk) - Tuesday, 05 January 2016, 14:39 GMT Comment by ValdikSS (ValdikSS) - Tuesday, 05 January 2016, 15:22 GMT
@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.
Comment by James Barnett (barnett) - Tuesday, 05 January 2016, 17:00 GMT
I applied the patch on my personal system that AnAkkk linked to and it seems to solve the issue.
Comment by Adrien Jacquet (N3mesis98) - Wednesday, 06 January 2016, 07:24 GMT
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)
Comment by pavan yalamanchili (pavanky) - Wednesday, 06 January 2016, 08:08 GMT
I can second that the issue is fixed with the latest update.

Loading...