Public bug reported:

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.

** Affects: network-manager-openvpn (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager-openvpn in Ubuntu.
https://bugs.launchpad.net/bugs/1673165

Title:
  Ignores route depending on other route

Status in network-manager-openvpn package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1673165/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to