There's more screwy things going on with network-manager-openvpn's interaction with the routing table, I realised. This is how my routing table look after activating the tunnel:
[EMAIL PROTECTED]:~$ ip r 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 VPN-GW.VPN-GW.VPN-GW.VPN-GW via 10.0.0.1 dev wlan0 proto static 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2 VPN.VPN.VPN.0/19 dev tun0 proto static scope link 169.254.0.0/16 dev wlan0 scope link metric 1000 VPN.VPN.0.0/12 dev tun0 proto static scope link default via 10.0.0.1 dev wlan0 proto static I've added the routes to VPN.VPN.* manually using the workaround I mentioned in another comment, since the default route redirection doesn't work. One thing missing here is that there should be a route to 10.8.0.1 (the OpenVPN server's internal OpenVPN address). It used to be automatically added before (and indeed, it pushes that address as the DNS dhcp-option too), so that's another regression. You can see the host-route added to VPN-GW x 4 (which is neccessary for the OpenVPN connection to work, since that particular address is part of my employers VPN.VPN.VPN.0/19 network (and the OpenVPN packets can't very well be routed inside of the OpenVPN tunnel). Then the VPN connection stop working. In my logs I see the following: Oct 14 23:10:46 envy dhclient: DHCPREQUEST of 10.0.0.51 on wlan0 to 10.0.0.1 port 67 Oct 14 23:10:46 envy dhclient: DHCPACK of 10.0.0.51 from 10.0.0.1 Oct 14 23:10:46 envy NetworkManager: <info> DHCP: device wlan0 state changed bound -> renew Oct 14 23:10:46 envy NetworkManager: <info> address 10.0.0.51 Oct 14 23:10:46 envy NetworkManager: <info> prefix 24 (255.255.255.0) Oct 14 23:10:46 envy NetworkManager: <info> gateway 10.0.0.1 Oct 14 23:10:46 envy NetworkManager: <info> nameserver '217.13.7.140' Oct 14 23:10:46 envy NetworkManager: <info> nameserver '217.13.4.24' Oct 14 23:10:46 envy NetworkManager: <info> domain name 'lan' Oct 14 23:10:46 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf Oct 14 23:10:46 envy dhclient: bound to 10.0.0.51 -- renewal in 2735 seconds. Oct 14 23:10:46 envy avahi-daemon[5342]: Withdrawing address record for 10.0.0.51 on wlan0. Oct 14 23:10:46 envy avahi-daemon[5342]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51. Oct 14 23:10:46 envy avahi-daemon[5342]: Interface wlan0.IPv4 no longer relevant for mDNS. Oct 14 23:10:46 envy avahi-daemon[5342]: Joining mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.51. Oct 14 23:10:46 envy avahi-daemon[5342]: New relevant interface wlan0.IPv4 for mDNS. Oct 14 23:10:46 envy avahi-daemon[5342]: Registering new address record for 10.0.0.51 on wlan0.IPv4. Oct 14 23:10:47 envy NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf Oct 14 23:10:47 envy NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS. Oct 14 23:12:36 envy nm-openvpn[23085]: [openvpn-gw.employer.no] Inactivity timeout (--ping-restart), restarting Oct 14 23:12:36 envy nm-openvpn[23085]: SIGUSR1[soft,ping-restart] received, process restarting Oct 14 23:12:38 envy nm-openvpn[23085]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Oct 14 23:12:38 envy nm-openvpn[23085]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 14 23:12:38 envy nm-openvpn[23085]: Re-using SSL/TLS context Oct 14 23:12:38 envy nm-openvpn[23085]: LZO compression initialized Oct 14 23:12:38 envy nm-openvpn[23085]: UDPv4 link local: [undef] Oct 14 23:12:38 envy nm-openvpn[23085]: UDPv4 link remote: VPN-GW.VPN-GW.VPN-GW.VPN-GW:1194 Oct 14 23:13:25 envy NetworkManager: <info> (wlan0): supplicant connection state change: 7 -> 6 Oct 14 23:13:25 envy NetworkManager: <info> (wlan0): supplicant connection state change: 6 -> 7 Oct 14 23:13:38 envy nm-openvpn[23085]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your networkconnectivity) Oct 14 23:13:38 envy nm-openvpn[23085]: TLS Error: TLS handshake failed Oct 14 23:13:38 envy nm-openvpn[23085]: SIGUSR1[soft,tls-error] received, process restarting Oct 14 23:13:40 envy nm-openvpn[23085]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. [...repeated...] And the new routing table: [EMAIL PROTECTED]:~$ ip r 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.51 metric 2 VPN.VPN.VPN.0/19 dev tun0 proto static scope link VPN.VPN.0.0/12 dev tun0 proto static scope link default via 10.0.0.1 dev wlan0 proto static So what just happened? It seems that the DHCP lease (given out by a lame residental CPE/NAT device which terminates my DSL circuit) was up for renewal. As part of this procedure n-m removed the route to VPN-GW, which of cause breaks the tunnel since those packets are now routed to inside the VPN tunnel (a catch-22), since the VPN routes themselves are left in place. The same problem would occur if the redirection of the default route redirection worked, since VPN-GW is within the default route too. So the host (/32) route to the VPN GW needs to left intact for the VPN connection to work, but right now this too seems to be broken. Apologies for the anonymisation, I'm a bit paranoid about these things. Hope the report is still usable. Tore -- Intrepid regression: default route is no longer redirected over VPN tunnel, and DNS servers provided by VPN server not used https://bugs.launchpad.net/bugs/269071 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
