GNOME Bugzilla – Bug 549196
openvpn route_vpn_gateway setting ignored
Last modified: 2008-10-11 14:45:01 UTC
Please describe the problem: (as discussed on irc with dcbw) our openvpn based network works roughly as follows: - multiple /24 subnets, with one of the subnets for vpn logins - an openvpn server which uses "push route-gateway 10.x.y.1", where 10.x.y.1 is the next-hop address to get out of the /24 vpn subnet - no other pushed routing information when the n-m client connects, it does not look for this pushed variable, and with the absence of other pushed routes it adds a default route which makes everything outside of the vpn's /24 unroutable. Steps to reproduce: 1. have an openvpn server that uses "push route-gateway" for sending routing info 2. connect with n-m openvpn client Actual results: a routing table ends up looking something like: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface a.b.c.d 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0_rename 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0_rename 10.x.y.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 0.0.0.0 0.0.0.0 0.0.0.0 UG 0 0 0 tap0 where a.b.c.d is the world-routable address of the vpn server, and 192.168/24 is the wireless network in my apartment, and 10.x.y/24 is the vpn subnet at the remote site. Expected results: the routing table *should* look something like: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface a.b.c.d 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0_rename 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0_rename 10.x.y.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 0.0.0.0 10.x.y.1 0.0.0.0 UG 0 0 0 tap0 Does this happen every time? yes Other information: i've written a patch to fix this behaviour, with the help of dcbw on irc. will attach shortly.
Created attachment 117301 [details] [review] patch for correct usage of route_vpn_gateway note that the whitespacing is probably incorrect...
the previous patch basically does the following: first, it adds a new #define for this setting, as is done for the other settings second, it moves the "add a default route if no routing info found" logic, from nm_system_vpn_device_set_from_ip4_config to main() in nm-openvpn-service-openvpn-helper.c. [1]. the latter, if no routing is found, appends the default route to the list of routes which is then sent to the former. the former then checks for each of the routes in the route list as being default (0 for destination and netmask), and if it finds such a route it calls the default route replacing function instead of the route adding function. [1] i just realize while writing this that this patch may introduce problems for the other helpers, which depended on the logic being there too. re-adding the removed code around "if (num == 0)" should fix that, as it will never be evaluated for the openvpn plugin.
Created attachment 117302 [details] [review] second version of openvpn routing fix this one shouldn't have the previously mentioned problem.
I had the same problem as Sean and I've now been using this patch for two weeks and it works really nice. Could this patch be integrated in standard nm?
fixed in NM r4169 and openvpn r4170, please test. Thanks!