After activating the tunnel (I deleted and re-created the config, so now there's no static routes configured anymore), the routing table looks like this:
VPN-GATEWAY via 10.0.0.1 dev wlan0 proto static
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.0.1 via 10.8.0.5 dev tun0 proto static
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
default via 10.0.0.1 dev wlan0 proto static
So the default route is still pointing to the residental CPE device, and not the OpenVPN tunnel (which would then have been "dev tun0"). In other words, the bug is still present. There's an improvement there, though, the route to 10.8.0.1 is back where it should be. resolv.conf still looks good.
I haven't stayed on for long enough to tell if the host route to VPN-GATEWAY will survive a DHCP lease renewal. I'll let you know how it goes when I return from work.
A potential interesting log snippet:
Oct 16 07:38:54 envy NetworkManager: <info> VPN connection 'Work (added in GNOME)' (IP Config Get) complete.
Oct 16 07:38:54 envy NetworkManager: <WARN> nm_system_replace_default_ip4_route(): replace_default_ip4_route() returned error Success (0)
Oct 16 07:38:54 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Okay, did a test. Package versions:
libnm-glib0 0.7~~svn2008101 5t024626- 0ubuntu1 5t024626- 0ubuntu1 5t024626- 0ubuntu1 manager- gnome 0.7~~svn2008101 5t194645- 0ubuntu1 manager- openvpn 0.7~~svn2008101 5t024626- 0ubuntu1
libnm-util0 0.7~~svn2008101
network-manager 0.7~~svn2008101
network-
network-
After activating the tunnel (I deleted and re-created the config, so now there's no static routes configured anymore), the routing table looks like this:
VPN-GATEWAY via 10.0.0.1 dev wlan0 proto static
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.0.1 via 10.8.0.5 dev tun0 proto static
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
default via 10.0.0.1 dev wlan0 proto static
So the default route is still pointing to the residental CPE device, and not the OpenVPN tunnel (which would then have been "dev tun0"). In other words, the bug is still present. There's an improvement there, though, the route to 10.8.0.1 is back where it should be. resolv.conf still looks good.
I haven't stayed on for long enough to tell if the host route to VPN-GATEWAY will survive a DHCP lease renewal. I'll let you know how it goes when I return from work.
A potential interesting log snippet:
Oct 16 07:38:54 envy NetworkManager: <info> VPN connection 'Work (added in GNOME)' (IP Config Get) complete. replace_ default_ ip4_route( ): replace_ default_ ip4_route( ) returned error Success (0)
Oct 16 07:38:54 envy NetworkManager: <WARN> nm_system_
Oct 16 07:38:54 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Regards,
Tore