Ignores route depending on other route

[Tobias Wolter]

Used versions:
* Ubuntu 16.10
* network-manager 1.2.6-0ubuntu1
* network-manager-openvpn 1.2.6-2ubuntu1
* openvpn 2.3.11-1ubuntu2

Just like iputils refuses to add routes where it doesn't has a route to the gateway on the device, openvpn seems pretty much to do the same.

% sudo /usr/lib/NetworkManager/nm-openvpn-service --debug
[...]
nm-openvpn[16132]: <debug> [helper-16342] environment: script_type=up
nm-openvpn[16132]: <debug> [helper-16342] environment: dev_type=tun
nm-openvpn[16132]: <debug> [helper-16342] environment: dev=tun0
nm-openvpn[16132]: <debug> [helper-16342] environment: link_mtu=1542
nm-openvpn[16132]: <debug> [helper-16342] environment: tun_mtu=1500
nm-openvpn[16132]: <debug> [helper-16342] environment: script_context=init
nm-openvpn[16132]: <debug> [helper-16342] environment: route_gateway_2=172.19.200.141
nm-openvpn[16132]: <debug> [helper-16342] environment: route_netmask_2=255.255.255.0
nm-openvpn[16132]: <debug> [helper-16342] environment: route_network_2=172.19.200.0
nm-openvpn[16132]: <debug> [helper-16342] environment: route_gateway_1=172.19.200.141
nm-openvpn[16132]: <debug> [helper-16342] environment: route_netmask_1=255.255.0.0
nm-openvpn[16132]: <debug> [helper-16342] environment: route_network_1=172.19.0.0
nm-openvpn[16132]: <debug> [helper-16342] environment: route_vpn_gateway=172.19.200.141
nm-openvpn[16132]: <debug> [helper-16342] environment: route_net_gateway=192.168.178.1
nm-openvpn[16132]: <debug> [helper-16342] environment: ifconfig_remote=172.19.200.141
nm-openvpn[16132]: <debug> [helper-16342] environment: ifconfig_local=172.19.200.142
nm-openvpn[16132]: <debug> [helper-16342] environment: common_name=server
nm-openvpn[16132]: <debug> [helper-16342] environment: trusted_port=1194
nm-openvpn[16132]: <debug> [helper-16342] environment: trusted_ip=IP_REMOVED
nm-openvpn[16132]: <debug> [helper-16342] environment: untrusted_port=1194
nm-openvpn[16132]: <debug> [helper-16342] environment: untrusted_ip=IP_REMOVED
[...TLS certs etc]
nm-openvpn[16132]: <debug> [helper-16342] environment: verb=10
nm-openvpn[16132]: <debug> [helper-16342] environment: daemon=0
nm-openvpn[16132]: <debug> [helper-16342] environment: daemon_log_redirect=0
nm-openvpn[16132]: <debug> [helper-16342] environment: daemon_start_time=1489594872
nm-openvpn[16132]: <debug> [helper-16342] environment: daemon_pid=16267
nm-openvpn[16132]: <debug> [helper-16342] environment: proto_1=udp
nm-openvpn[16132]: <debug> [helper-16342] environment: local_port_1=0
nm-openvpn[16132]: <debug> [helper-16342] environment: remote_1=HOST_NAME_REMOVED
nm-openvpn[16132]: <debug> [helper-16342] environment: remote_port_1=1194
[...]

% ip r l | grep 172.19
172.19.200.0/24 via 172.19.200.141 dev tun0 proto static metric 50
172.19.200.141 dev tun0 proto kernel scope link src 172.19.200.142 metric 50

I don't see anything happening to the routes wrt errors:
Wed Mar 15 17:21:15 2017 us=306238 PUSH: Received control message: 'PUSH_REPLY,route 172.19.0.0 255.255.0.0,route 172.19.200.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 172.19.200.142 172.19.200.141'
Wed Mar 15 17:21:15 2017 us=306271 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 15 17:21:15 2017 us=306287 OPTIONS IMPORT: --ifconfig/up options modified
Wed Mar 15 17:21:15 2017 us=306290 OPTIONS IMPORT: route options modified
Wed Mar 15 17:21:15 2017 us=306371 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=eth0 HWADDR=54:ee:75:51:75:eb
Wed Mar 15 17:21:15 2017 us=324890 TUN/TAP device tun0 opened
Wed Mar 15 17:21:15 2017 us=324925 TUN/TAP TX queue length set to 100
Wed Mar 15 17:21:15 2017 us=324964 /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 6 16132 --bus-name org.freedesktop.NetworkManager.openvpn --tun -- tun0 1500 1542 172.19.200.142 172.19.200.141 init
Wed Mar 15 17:21:15 2017 us=325278 PKCS#11: __pkcs11h_forkFixup entry pid=16342, activate_slotevent=1
Wed Mar 15 17:21:15 2017 us=325329 PKCS#11: __pkcs11h_forkFixup return
nm-openvpn[16132]: <debug> [helper-16342] command line: "/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper" "--debug" "6" "16132" "--bus-name" "org.freedesktop.NetworkManager.openvpn" "--tun" "--" "tun0" "1500" "1542" "172.19.200.142" "172.19.200.141" "init"
nm-openvpn[16132]: <debug> [helper-16342] environment: script_type=up

I'm figuring it's trying to add the route before the network route itself is there, which leads to expected results when testing:

% sudo ip link add foobar0 type dummy
% sudo ip r a 172.19.0.0/16 dev foobar0 via 172.19.200.141
RTNETLINK answers: Network is unreachable

If you use openvpn directly though, it works just fine:
% ip r l | grep 172.19
%
% sudo openvpn client.conf
[...]
Wed Mar 15 17:42:13 2017 /sbin/ip addr add dev tun0 local 172.19.200.142 peer 172.19.200.141
Wed Mar 15 17:42:13 2017 /sbin/ip route add 172.19.0.0/16 via 172.19.200.141
Wed Mar 15 17:42:13 2017 /sbin/ip route add 172.19.200.0/24 via 172.19.200.141
[...]
% ip r l | grep 172.19
172.19.0.0/16 via 172.19.200.141 dev tun0
172.19.200.0/24 via 172.19.200.141 dev tun0
172.19.200.141 dev tun0 proto kernel scope link src 172.19.200.142

So I'll be blaming nm-openvpn-service-openvpn-helper for doing something weird.