0

I have an OpenVPN instance on AWS I'm using to control access to admin tools. I have an internal Route53 zone and a BIND instance which OpenVPN sets as the client DNS. Everything works great, except than whenever I open my laptop if I have a dashboard open to grafana.mydomain.com it attempts to resolve to the public Route53 zone and fails since this record is only in the private zone. When the VPN connects a moment later the previous failure remains cached for 5 minutes.

Is there any way to fix this behavior (without modifying the client machine)? Something like clearing the DNS cache on connect to the VPN or reduce the time the missed lookups are cached for?

Paul
  • 53
  • 6
  • Yes, edit `/etc/nscd.conf`. – Ipor Sircer Aug 17 '20 at 14:26
  • so your zone has split brain configuration? Does grafana.example.com actually resolves to anything useful? If not you could add the same resolution for grafana.example.com in the external zone so that both zones would point to the same internal address. – Marcel Aug 20 '20 at 13:37
  • Yeah, have both external and internal DNS. Internal records point to my load balancer for the internal ingress controller. External only has a "vpn" record, at the moment I've created a public record for grafana with a 5 second TTL that also resolves to the VPN IP...this works but feels dirty, since I'm publishing a list of internal tools I'm using to the world and sort of defeating the point of having internal DNS at all. I've also seen some training videos saying you should not have public records for private resources, but I think they're thinking in terms of a site VPN for a corp network. – Paul Aug 20 '20 at 19:49
  • Also considered using something like grafana.mycorp.internal but then my certs won't be trusted unless every client installs my CA. – Paul Aug 20 '20 at 19:51
  • What is happening is the TTL on the public zone mydomain.com is coming into play. I dunno how to fix that without modifying the client side since the failures are happening there though. Any easy way to fix it on the client is to add a static host entry to the client for grafana.mydomain.com to the IP address you want it to be. You shouldn't have public DNS records for any resource you want private, corp network or not. – DubStep Aug 21 '20 at 20:29
  • Well I guess I can think of a way to fix it without modifying the client and that is to set the TTL on the public zone really low, but that's a terrible idea, so I wouldn't do it. It would be helpful to know what OS is on the client as well. Some VPN clients have the option clear DNS resolver cache on connect/disconnect. Maybe that is an option in OpenVPN? – DubStep Aug 21 '20 at 20:34

1 Answers1

0

On pfSense, there is a VPN server config option:

Force DNS cache update

Run "net stop dnscache", "net start dnscache", "ipconfig /flushdns" and "ipconfig /registerdns" on connection initiation.

This is known to kick Windows into recognizing pushed DNS servers.

Which in the OpenVPN config file (server side), translates to this:

push "register-dns"

Which in the OpenVPN 2.4 manual, says this:

–register-dns

Run ipconfig /flushdns and ipconfig /registerdns on connection initiation.

This is known to kick Windows into recognizing pushed DNS servers.

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

It seems to generate a warning on non-Windows clients that can be ignored:

https://community.openvpn.net/openvpn/ticket/570

iamacarpet
  • 310
  • 2
  • 12