GNOME Bugzilla – Bug 673636
pushed route with net_gateway on wrong interface
Last modified: 2020-11-12 14:27:42 UTC
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 Bug was first posted on https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/974912 but it appears to be present on all distributions.
I'm having this issue as well. I'm on version 0.9.8.0 The route pushed with net_gateway as a gateway is pushed through tun0. For some reason, another route is created on tun0 which causes me to lose all connectivity until I remove it or close the VPN. Like the submitter, when I use openvpn directly, this issue does not occur, but I'm guessing that openVPN does the routes so it ends up working correctly, whereas with networkmanager-openvpn networkmanager handles the routes.
Created attachment 242872 [details] [review] awful patch to circumvent issue This was what I had to apply to circumvent this issue - it does not create the routes at all if the gateway is the same as route_net_gateway
Created attachment 242873 [details] debug log This is part of the debug log, with a lot of information removed. Hopefully it wasn't too much to be of use.
The problem is that nm-openvpn-service doesn't actually use the information from the remote OpenVPN server as part of the "push route" data, which includes whether to use a local or a remote gateway. By not passing down that information, the interface to rtnl_route_add has to resort to trying to guess if an intermediate ("bridge") route is needed, and guesses wrong if a push route tries to poke a hole in another pushed route, by pushing a more-specific route tagged to be routed locally. The code then proceeds by setting a route to your default route through the tunnel, causing a catch-22. I started to identify how many changes would be required to fix this, but I gave up for tonight. The "awful patch" actually gets things limping along by ignoring the pushed exceptions, but only if they're trying to poke a /32 sized hole. The patch does not cleanly apply to the current code because a comment was moved around in the mean time.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).