# OpenVPN and DNS for internal hosts

## TXTad

Howdy!

I've successfully got OpenVPN working but I'm not sure how (if I even can) solve one problem. Both the client and server sites have internal DNS that serve up IPs for internal machines as well as external machines. I don't want to replace the client DNS settings and lose the ability to resolve IPs for machines internal to the client network, but I would like to be able to ALSO use the server network DNS to resolve IPs for internal to the server network machines. In other words, I need to continue to use the client network's internal DNS, but fail over to the server network's DNS before giving up.

Can this be done?

Thanks,

Tad

----------

## magic919

Looks fairly normal.  You can have a list of up to 3 DNS servers in /etc/resolv.conf.  They are tried in order.

See man resolv.conf

----------

## TXTad

Well, that's what I thought, but it doesn't seem to be working for me. I would expect that I would have to use FQDNs for the hosts on the other network, but it's not helping.

Tad

----------

## magic919

Okay.  Let's step by step to see what is happening.

On the client machine

```

nslookup

>server [IP of server DNS]

>host.servernetwork.net (some valid hostname on server network)

```

This will prove the client can reach the DNS on the server side and do lookups.  Or not!

----------

## TXTad

I've already verified that I can hit the other DNS via dig. I can also resolv off of it if it is first in the list. Here is my resolv.conf:

```
# clientvpn.net DNS

nameserver 192.168.1.1

#servervpn.net DNS

nameserver 192.168.99.1

search clientvpn.net servervpn.net
```

If I move the servervpn.net DNS to be first in the list, it works, but then I have the opposite problem. The resolv.conf manpage says this about multiple nameservers:

 *Quote:*   

> Internet address (in dot notation) of a name server that the resolver should query. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multiple servers, the resolver library queries them in the order listed...(The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.)
> 
> 

 

The timeout thing concerns me. It seems that since a request to resolve somemachine.servervpn.net fails against the clientvpn.net nameserver (192.168.1.1) that the next nameserver is never tried since there is no timeout.

Tad

----------

## nielchiano

 *TXTad wrote:*   

> Well, that's what I thought, but it doesn't seem to be working for me. I would expect that I would have to use FQDNs for the hosts on the other network, but it's not helping.

 

FQDN won't help, since you will keep trying the "local" server first, and he SHOULD point you to the right server. However, since that "right" server isn't accessible (normaly) it won't work.

It's an interesting problem, though... I'll think about a solution (after my exams  :Sad: )

----------

## TXTad

Just to clarify, BOTH DNSs are pingable. I've gone and added both domain names to the search directive in /etc/resolv.conf, so I can find machines for either domain by their short name if the given domain's DNS is listed first. The problem is that whatever DNS is listed second is never searched.

----------

## thesnowman

Did you find the solution for this one yet?  I'm trying to do the same thing.

Looks like we need to use the push option on the server like so:

```
push "dhcp-option DNS 192.168.2.254"
```

This works out-of-the-box for Windows clients.  For non-Windows we need a script to run to parse the options: *man openvpn(8) wrote:*   

> Note that if --dhcp-option is pushed via --push to a non-windows client, the option will be saved in the client's environment before the up script is called,  under  the  name "foreign_option_{n}"

 

There's two scripts in /usr/share/doc/openvpn-2.0.5-r2/examples/contrib/pull-resolv-conf/ that should modify resolv.conf accordingly.  Just going to test them out myself now.

----------

## nielchiano

 *thesnowman wrote:*   

> Looks like we need to use the push option on the server like so:
> 
> ```
> push "dhcp-option DNS 192.168.2.254"
> ```
> ...

 

That doesn't solve the problem: your computer will just try the "VPN DNS" server and find all it's names, but fail on "local" names...

I'm afraid that you'll need some kind of (very basic) local DNS server that makes the split...

----------

## daeghrefn

The problem is not with the OpenVPN setup, but rather with the DNS servers.  Basically, you need each DNS server to either be able to forward to the other if it can't find something, or keep a secondary zone copy of the other zone.

You can't use /etc/resolv.conf because that's for FAILOVER.  If the first DNS server responds, either with an IP or with a negative "I don't know that name" response, it is not going to try the second DNS server.

Another option is to only use one DNS server.

Conceptually, what has to happen is the local DNS server somehow has to know how to resolve stuff on the remote subnet.

Hopefully these basics should get you started in the correct direction.

----------

## UberLord

This issue will be resolved soon - I've been working on a Gentoo port of Debians resolvconf which I blogged about.

The nice thing about resolvconf is that it has a nice and very very simple plugin structure.

So when resolvconf is informed about new dns information it can refresh nscd (libc dns cache) and then run any other plugin updates.

For example, you may choose to get around this limitation by installing dnsmasq as a local dns cache and then resolvconf can update the nameservers it should use when an application requests it.

Don't ask when it's going to get in portage btw, it's reliant on a few things happening first, namely getting our dhcp clients to support it and removing a load of stuff from baselayout which did exactly what resolvconf does, just without the nice plugin structure.

----------

## UberLord

 *UberLord wrote:*   

> For example, you may choose to get around this limitation by installing dnsmasq as a local dns cache and then resolvconf can update the nameservers it should use when an application requests it.

 

Using openvpn, dnsmasq and resolvconf I can now get dnsmasq to foward generic queries to nameservers on my LAN and vpn specific queries to the vpn nameservers.

This is done by ensuring the resolv.conf created by openvpn fills in the domain part as supplied by the openvpn server and the dhcp clients fill out their domain in the search field in resolv.conf.

So it's perfectly possible and I have demonstrated it to work - now to get the bits into portage  :Smile: 

----------

## daeghrefn

Fascinating.  Will it work with BIND too?

----------

## UberLord

No reason why not, just create zones with forwarders in a seperate file using similar rules and the reload bind.

I'll see if I can make a bind file too  :Smile: 

----------

## UberLord

I now have a working bind setup too  :Smile: 

----------

