Internal DNS only when VPN is up

McMurphy

I wish to configure a split dns allowing a remote site to resolve hosts internally only when the VPN link is up. If the VPN link is down then I want to use the public dns servers.

We are using Wireguard VPN between two pfsense.

stephenw10

Hmm, the only way I can imagine doing that would be to redirect DNS requests to a server across the VPN using a policy routing rule. That would only apply when the VPN gateway was up.

But that would be pretty ugly! I could also imagine that causing problems.

There's no way to apply a host or domain override based on gateway status directly.

luckman212

I'd imagine this is actually possible if you:

configure Unbound in forwarder mode
enable unbound-control (control-enable: yes)
use a small helper script to check the status of the VPN gateway (if you have pfS+, the Nexus API is the cleanest way):

result=$(curl -s --unix-socket /var/run/pfnet-controller.sock http://unix/api/system/gateways/status | jq '.gateways | map(select(.name=="MY_VPN_GW" and .loss=="0.0%")) | length == 1')

that command above returns true only when the vpn is up with 0% packet loss
helper script can change the list of forwarders based on that status, eg:

if [ "$result" = "true"; then
  /usr/local/sbin/unbound-control forward 10.1.2.3 10.1.2.4
else
  /usr/local/sbin/unbound-control forward 8.8.8.8 8.8.4.4
fi

The helper script can be called by dpinger on gateway events, or just run periodically with cron.

stephenw10

Ooo fun, that could work. Pretty custom at that point though.

tinfoilmatt

This should contain the disclaimer that when "$result = false", DNS queries for internal resources will leave the LAN.

johnpoz

@McMurphy could you give some more details of this use case...

So 2 sites A and B.. Resolving local resources in B should be as simple as a domain override in A pointing to the NS in B.

siteb.domain.tld

Be a given that if the vpn is down you would not be able to resolve those.

Are you using a public domain internally, where you want to resolve the rfc1918 address when vpn up but the public IP when the vpn is down? So like host.sitebpulic.tld when vpn down 1.2.3.4, but when vpn up host.sitebpublic.tld resolves to say 192.168.1.42 ? Why, if A can access resource in be over public network, what is the point of the vpn?

Are trying to leverage not only resources in site B but also use this connection to resolve public dns? when when clearly external dns works from A if the vpn is down, etc.

Curious to this use case to why a simple domain override doesn't solve the issue of resolving stuff in siteb from a. And the reverse also works a domain override in a to resolve stuff in b.

luckman212

@tinfoilmatt That should be possible to work around as well...

e.g... when VPN is down:

unbound-control forward_remove +i ad.corp.
unbound-control local_zone ad.corp. always_refuse
unbound-control flush_zone ad.corp.

in that mode, lookups for *.ad.corp will return REFUSED instead of being leaked.

and then, when it's back up:

unbound-control local_zone_remove ad.corp.
unbound-control forward_add +i ad.corp. 10.1.2.3 10.1.2.4
unbound-control flush_zone ad.corp.

SteveITS

but OP says

If the VPN link is down then I want to use the public dns servers.

(And resolve to the public IP, I read it)

stephenw10

@johnpoz said in Internal DNS only when VPN is up:

Be a given that if the vpn is down you would not be able to resolve those.

As I read it that would still resolve to the same private IP it just wouldn't be reachable. The OP wants it to fall back to the real public IP in that case.

johnpoz

@stephenw10 if so then means the they are available via public - so what is the point of the vpn? Just not understanding they are wanting to actually accomplish other than complexity.

If I want to resolve stuff on the other end of a vpn, I put in a domain override to go ask the the ns there for the domain at that site, done..

I am not understanding what exactly they are trying to accomplish here.. The use case makes no sense to me.