net_gateway adds route on wrong interface

[Ced]

When using push route on server side to bypass the vpn for a specific subnet :
push "route 1.2.3.0 255.255.255.0 net_gateway"

The network manager registers the route on tun0 instead of net_gateway interface :
NetworkManager[1149]: <info> Static Route: 1.2.3.0/24 Next Hop: 1.2.3.0

See the route in kernel :
1.2.3.0 192.168.0.1 255.255.255.0 UG 0 0 0 tun0

192.168.0.1 is on eth2
but route is registered on tun0
and traffic to 1.2.3.0/24 is sent to tun0 instead of eth2

When I launch openvpn in command line I get the correct route :
us=482299 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dns bypass-dhcp,route 1.2.3.0 255.255.255.0 net_gateway,comp-lzo yes,route-gateway x.x.x.x,topology subnet,ping 10,ping-restart 120,ifconfig x.x.x.y 255.255.255.0'
us=490292 /sbin/route add -net 1.2.3.0 netmask 255.255.255.0 gw 192.168.0.1
and the route appears on eth2
1.2.3.0 192.168.0.1 255.255.255.0 UG 0 0 0 eth2
then traffic to 1.2.3.0/24 flows through eth2 as expected

[Nicollet Xavier (xnicollet)]

Confirm: I have the same issue here.

Can't add new users easily for roaming. We stick to previous solutions for now (pptp or windows platforms).

Cheers,

[Mathieu Trudel-Lapierre (cyphermox)]

You may want to try clicking the "use this connection only for the resources on its network" checkbox under Routes, which may help.

[Ced (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7)]

I just tested with "use this connection only for the resources on its network" checked.
Still same issue : all routes pushed with the net_gateway option are on tun0.

[Launchpad Janitor (janitor)]

[Expired for network-manager-openvpn (Ubuntu) because there has been no activity for 60 days.]

[Oliver Dumschat-Hötte (o-dumschatt-hoette)]

Still the same issue in Ubuntu 12.04.2.

All pushed routes are added on tun0 device, including the route to the vpn gateway(s).
Imho this happens because the default route is changed to the tun0 device before the pushed routes are set. So all routes added after this will be bound to the (then default) tun0-Interface. I assume, changing the workflow to set the default route at the end of vpn initialisation could solve this problem.

Until now i took the direct way and changed this by patching network-manager-openvpn to let openvpn set the routes instead of network-manager, because patching only a plugin is much easier than patching the NetworkManager, but i don't think this is a good solution.

[Joel Garske (joel-garske)]

Same Problem here.

As Oliver said, it is not a problem with openvpn (vanilla OpenVPN connections to the same service work fine here), but with NM-openvpn. Also, I encountered the problem on different distributions (Arch, Debian "sid" (as of now)). Do we (as in "should I") kick this upstream? There does not seem to be an appropriate bug at the NM-Project - or I am missing it.

[Stephan Springer (geryon)]

Yes please, go ahead. :)
And please add the link to the upstream bug here. Thanks!

[Joel Garske (joel-garske)]

Ok. I will test and confirm with the most current upstream version and - if the bug still applies - file it, posting the link here. Thanks for the approval.

[Nick Douma (lordgaav)]

https://bugzilla.gnome.org/show_bug.cgi?id=673636

There doesn't seem to be much progress on the upstream issue, but a patch was posted.

Is it possible for Ubuntu to include the patch in the packages? I'm running into this issue on 12.04 and 14.04.

[Bert Driehuis (driehuis)]

Unfortunately, that patch is just a partial workaround for a very limited use case. If the sysadmin ever tries to override more than a single IP through the route push mechanism of openvpn (i.e., something larger than a /32), this hack will stop to do what it did. Also, NetworkManager still sets a bogus route to your router through tun0, causing all kinds of hard to diagnose breakage.

The problem is that NetworkManager's OpenVPN handling tries to infer if it needs to set a host route to reach a remote gateway, rather than just using the explicit interface passed as part of OpenVPN's "route push".

For a proper fix, nm should pass the interface for each route all the way down to rtnl_route_add. That's a non trivial amount of work, which is probably why the effort stalled upstream.