Re: Correctly write resolv.conf when using OpenVPN plugin

[Dan Williams <dcbw redhat com>]

On Sat, 2010-12-25 at 00:27 +0300, Pentarh Udi wrote:
> I decided to use OpenVPN plugin of NetworkManager instead of of openvn
> CLI binary and I begin to expect name resolving problems.
> 
> Original bug was posted
> in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/651007
> 
> People there suggested to write to this mailing list, so...
> 
> Problem is  in very slow name resolution when connecting to OpenVPN
> peer and obtaining DNS servers from there by directive
> 
> push "dhcp-option DNS x.x.x.x"
> 
> While investigating this issue I found that NM append obtained DNS
> servers to existing resolv.conf. So libc uses not only DNS servers
> from OpenVPN peer, but original DNS servers too. 
> 
> It should be noticed that original DNS servers WILL LIKELY be
> unreacable after establishing VPN connection.
> 
> In my case resolv.conf BEFORE openvpn connection is:
> 
> ---------
> nameserver 212.48.193.37
> nameserver 192.168.100.1
> ---------
> 
> And after is:
> ---------
> # Generated by NetworkManager
> nameserver 88.85.66.222
> nameserver 78.140.128.205
> nameserver 213.158.7.2
> # NOTE: the libc resolver may not support more than 3 nameservers.
> # The nameservers listed below may not be recognized.
> nameserver 212.48.193.37
> nameserver 192.168.100.1
> --------
> 
> In this case last three servers are invalid as they are not reachable
> after VPN connection, so name resolve becomes totally slow after
> openvpn connection because libc tries to get DNS answer from all
> servers:
> 
> --------------
> 
> root@pentarh-netbook:/var/log# tcpdump -i tun0 -n port 53
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
> 22:33:46.803557 IP 10.20.10.6.55426 > 213.158.7.2.53: 32890+ A?
> mail.google.com. (33)
> 22:33:51.807076 IP 10.20.10.6.58861 > 212.48.193.37.53: 32890+ A?
> mail.google.com. (33)
> 22:33:55.521957 IP 10.20.10.6.60601 > 213.158.7.2.53: 49670+ A?
> www.google.com. (32)
> 22:34:00.527135 IP 10.20.10.6.57982 > 212.48.193.37.53: 49670+ A?
> www.google.com. (32)
> 22:34:09.760264 IP 10.20.10.6.39286 > 88.85.66.222.53: 27804+ A?
> pagead2.googleadservices.com. (46)
> 22:34:09.946468 IP 88.85.66.222.53 > 10.20.10.6.39286: 27804 5/4/4
> CNAME pagead.l.google.com., A 209.85.149.167, A 209.85.149.164, A
> 209.85.149.165, A 209.85.149.166 (276)
> 22:34:11.505444 IP 10.20.10.6.45653 > 213.158.7.2.53: 41142+ A?
> chatenabled.mail.google.com. (45)
> --------------
> 
> As you can see, libc tries to resolve mail.google.com from old
> unreachable servers and gets the answer from correct DNS after 20
> seconds (!!!) of first query.
> 
> This should be fixed, it makes OpenVPN plugin for NM unusable.
> 
> The workaround of this issue may be providing static routes to
> original DNS IP, but i cant do that in NM openvpn plugin
> configuration, this option is inactive.

As you pointed out, it depends on routing whether the original servers
are available or not.  And if you check the "Only use this connection
for resources on its network" then any non-VPN traffic will still go
over the wifi or ethernet or 3G device, not over the VPN, and likely the
original DNS servers will be used.

However, libc queries the DNS servers *in order listed*, so it's odd
that anything would be trying to query the older servers at all.  Note
that libc does *not* refresh DNS information when resolv.conf changes,
so if an application does not call res_init() before it makes DNS
lookups, it may be using old information.  This is a well-known glibc
design choice that upstream glibc has declined to change.  THe solution
is to run a local caching nameserver that supports split DNS, thus any
queries for VPN-specific nameservers can go to the VPN, and everythign
else can go to your normal nameservers.

So in the end, there are some things NM could do here.  If the original
nameservers are on subnets that are now owned by the VPN, NM probably
shouldn't put those in resolv.conf.  But on the other hand, it's a bug
in applications to be using old DNS information, which is only fixed in
the application by using res_init(), or by using a local caching
nameserver.

NM 0.8.2 and later has native support for dnsmasq as a local caching
nameserver.

Dan