Handling DNS resolution when IPsec is down
-
Hi there,
I have a question on how to handle DNS resolution in a IPsec scenario:
I'm using the latest pfSense firewalls to connect two offices (head and branch) with IPsec routing internal subnets and not routing internet traffic.
But since the DNS sever is on the head office, when the IPsec goes down for external reasons, the branch office is unable to access the internet because the devices can't reach the DNS server, located in the head office.
When this happens, I have a NAT port forward rule on the port 53 that I manually activate during the downtime hours, redirecting everything to 8.8.8.8. This way, the branch office is able to access the internet even if the IPsec is down.
This workaround has many problems but the worst of them being the fact that is a manual operation to enable and disable the NAT rule.
I've been looking for alternatives but can't seen to find the best way:
Option 1) In the DHCP server, put the head office DNS as primary and a public DNS as secondary: this cause some issues because each system handles the primary/secondary servers differently. I'm unable to have the same behavior between Windows, macOS and mobile devices.
Option 2) Use some kind of automation to enable the NAT rule when the IPsec is down and disable it when it goes up. This could work, there's two issues:
a) pfSense doesn't seem to have a "built-in" way to accomplish this - I would need a shell/PHP script or something like that, not a problem, but maybe a bad work around?
b) NAT redirection feels wrong.Option 3) Enable Unbound on the branch office and configure in a way to use the head office DNS as the main lookup source and a public DNS server as second. Not sure if this is viable but I think would be the best option.
Any thoughts?
Thanks!
-
I manage to fix this problem with a better "option 3":
Unbound on the branch office forwards only the needed zones to the main office, while all other zones are being forwarded to public DNS servers (root or not).
Here's the complete step by step:
- Make sure you have your preferred external DNS server set in System -> General Setup -> DNS Server Settings.
- Run DNS Resolver on the remote pfSense box but for the "Outgoing" interface, make sure you use the "LAN" interface, not the WAN. This is needed so that the requests go across the tunnel.
- Under the "Domain Overrides", enter the domains that you need to have resolved by the DNS at the main branch (i.e. ad.company.com) and the IP address of those DNS servers. You can also add the in-addr.arpa to those forwarding domains as well if reverse lookups are needed. If you have more than one server, duplicate the entry but change the DNS IP.
- Change the DHCP server settings to used the LAN address of the pfSense box as their DNS servers.
In this case, when the tunnel drops, the only items that will fail to resolve will be the ones that specifically are forwarded to the main branch.
-
@vegbrasil said in Handling DNS resolution when IPsec is down:
I manage to fix this problem with a better "option 3":
Unbound on the branch office forwards only the needed zones to the main office, while all other zones are being forwarded to public DNS servers (root or not).
Here's the complete step by step:
- Make sure you have your preferred external DNS server set in System -> General Setup -> DNS Server Settings.
- Run DNS Resolver on the remote pfSense box but for the "Outgoing" interface, make sure you use the "LAN" interface, not the WAN. This is needed so that the requests go across the tunnel.
- Under the "Domain Overrides", enter the domains that you need to have resolved by the DNS at the main branch (i.e. ad.company.com) and the IP address of those DNS servers. You can also add the in-addr.arpa to those forwarding domains as well if reverse lookups are needed. If you have more than one server, duplicate the entry but change the DNS IP.
- Change the DHCP server settings to used the LAN address of the pfSense box as their DNS servers.
In this case, when the tunnel drops, the only items that will fail to resolve will be the ones that specifically are forwarded to the main branch.
I have the same setup although instead of using LAN in the outgoing interfaces in unbound, I use localhost OR use both WAN and the IPsec interface (as I use Routed VTI). This works the same way as you did but I'm not sure if there's an advantage.