Re: vpnc plugin: order of resolv.conf entries when using Mobile Broadband vs. (W)LAN



On Tue, 2009-01-20 at 09:11 +0100, Marc Luethi wrote:
> 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)? 

It should still be the first nameserver, even if the default route
doesn't go through it.  The problem is that without a local caching
nameserver that can do split DNS, you can't often use *both* the VPN
nameservers and the upstream nameservers.  The glibc resolver limits you
to a maximum of 3 nameservers in /etc/resolv.conf, the rest are ignored.
Many DHCP servers will give you 2 or even 3 nameservers, leaving at most
1 nameserver for the VPN.  Thus, if the upstream nameservers were first,
there's a good chance that the VPN nameservers would simply be pushed
out of use.  The assumption is made that since you connected to the VPN
in the first place, you probably want to be able to resolve the names of
resources inside that VPN.

In the future I'd like to be able to turn a lightweight caching
nameserver (like dnsmasq or something) on by *default*, then we can
avoid this whole problem and use split DNS where queries for the search
domains of your VPN go to the VPN nameservers, and the rest go to the
upstream nameservers.

> > 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.

Ok, so your home netblock is still being routed over the VPN because the
server is pushing down a route that explicitly directs the traffic from
your home network over the VPN before the routing table even gets to the
default route.

> 
> 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>

Ok, because the VPN is up, the VPN nameservers are preferred as
expected.  Only VPN traffic is routed through the VPN (I assume the
server returns the 172.20.125.0/24 route) because the server returned a
static route, which is the default behavior of NM < 0.7.1.

> 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

Right, I assume these are your mobile broadband nameservers.  This looks
OK too.

> 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>

Yeah, so this doesn't look correct.  Let's assume that perhaps
resolvconf is screwing something up since it's obviously rewriting the
file.  Would you mind moving the resolvconf binary
(usually /bin/resolvconf) out of the way so that NM can't find it?  NM
*should* then fall back to writing out /etc/resolv.conf directly, which
should allow us to isolate whether NM is indeed getting the nameserver
ordering wrong, or whether it's the extra indirection of resolvconf

Thanks,
dan

> 
> 
> 
> 
> 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
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]