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

[Marc Luethi <netztier bluewin ch>]

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