On Mon, 2009-01-19 at 11:24 -0500, Dan Williams wrote: > VPN (if VPN all traffic is routed over the VPN) > Primary connection > Others
What if the default route does _not_ go trough the VPN (as it is in my case)? > The question I guess is if your VPN is becoming your default route or > not in both cases. It's not, in neither case. The VPN configuration has a 172.20.125.0/24 route for my home network (where the home DNS is) through the VPN. So let me bring some output: With WLAN (Hotspot LAN: 172.20.124.0/24, VPN Gateway 172.20.124.10) and VPN tunnel up (172.20.125.0/24 configured to go through the tunnel). ~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Iface 172.20.124.10 0.0.0.0 255.255.255.255 UH 0 wlan0 172.20.124.0 0.0.0.0 255.255.255.0 U 2 wlan0 172.20.125.0 0.0.0.0 255.255.255.0 U 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 wlan0 0.0.0.0 172.20.124.1 0.0.0.0 UG 0 wlan0 ~$ ~$ more /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 172.20.125.30 nameserver 172.20.124.1 search <my.domain> With Mobile Broadband and VPN tunnel down: ~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Iface 10.6.6.6 0.0.0.0 255.255.255.255 UH 0 ppp0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 ppp0 0.0.0.0 10.6.6.6 0.0.0.0 UG 0 ppp0 ~$ ~$ more /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 138.188.101.186 nameserver 138.188.101.189 With Mobile Broadband and VPN tunnel up (172.20.125.0/24 configured to go through the tunnel): (where 85.5.xxx.xxx is the current dynamic IP of my VDSL connection - IOW my VPN Gateway). ~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Iface 85.5.xxx.xxx 10.6.6.6 255.255.255.255 UGH 0 ppp0 10.6.6.6 0.0.0.0 255.255.255.255 UH 0 ppp0 172.20.125.0 0.0.0.0 255.255.255.0 U 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 ppp0 0.0.0.0 10.6.6.6 0.0.0.0 UG 0 ppp0 ~$ ~$ more /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 138.188.101.186 nameserver 138.188.101.189 nameserver 172.20.125.30 search <my.domain> For a test, I removed the 172.20.125.0/24 route from the VPN configuration, so that the default route now goes through interface tun0, as your comment suggested. With Mobile Broadband and VPN tunnel up (default route through the tunnel): ~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Iface 85.5.xxx.xxx 10.6.6.6 255.255.255.255 UGH 0 ppp0 10.6.6.6 0.0.0.0 255.255.255.255 UH 0 ppp0 172.20.125.0 0.0.0.0 255.255.255.0 U 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 tun0 ~$ ~$ more /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 138.188.101.186 nameserver 138.188.101.189 nameserver 172.20.125.30 search <my.domain> So the Mobile ISP's DNSs still take precedence over the VPN connection's DNSs in resolv.conf, with default route through the VPN or not. I can resolve internal names allright - after sending two queries towards the ISPs DNSs unnecessarily (with my Cisco PIX, they're unreachable anyway). If this (mis)behaviour is Ubuntu specific, I'll happily file a bug on launchpad, that's why I wanted to know if it was intentional to have it different when connecting with (W)LAN vs connecting with Mobile Broadband. regards Marc _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
