Remote site DNS for Windows clients

[shapelytraffic]

I am using a Netgate XG-7100. This site does not have any servers, so I am looking to offload DNS onto the router mentioned herein. I'm having a bit of trouble getting the client to resolve DNS queries and NSLookup from the client is only checking one of the configured DNS servers.

I've set up an IPSec tunnel from this site to my main site which has an identical Netgate router. I will need to resolve private IPs from the main office while on the remote LAN.

I am able to ping both public and private IPs from the diagnostic section of the remote router UI.

Please assist as I am less familiar with using network gear for DNS. I've typically relied on AD servers to serve in this function.

Thank you for your time, I am in the Pacific time zone and my replies will be within normal office hour for me.

[KOM]

@shapelytraffic Is each side on its own domain? If so, you could add a domain override to DNS Resolver to tell it what the authoritative DNS is for that specific domain and point it to the DNS on the other side on the tunnel.

[SteveITS]

@shapelytraffic said in Remote site DNS for Windows clients:

NSLookup from the client is only checking one of the configured DNS servers

Nslookup is only going to check one server unless the request fails. You can force it to use a server by using "nslookup example.com servernameorIP".

You can use a domain override to have pfSense forward the query to the Windows domain controller/DNS over the VPN.

FYI, Windows itself doesn't check DNS servers in order, it starts with the "last successful" as it assumes that one is good. So you may want the pfSense as the only DNS server in that location.

[shapelytraffic]

@kom Both sides would have clients that are members of the same AD Domain, but AD is not present in the remote site. Ideally, the clients in the remote site would treat the main office as an extension of the remote office, such as accessing shared drives and sending authentication traffic to the main office AD servers.

I'm contrasting this experience with another remote office (relative to the main office). In this other remote location, there are AD servers and there are no issues with traffic traversing the IPsec tunnel as desired.

However, I just realized the FW versions are different between the main office and the remote office where I am having issues. I am planning a mid day FW upgrade today, in the next 90 minutes or so. That can't hurt (aside from cutting off remote access if things go poorly), so I anticipate that there will be some improvements. Could just be protocol version mismatch in the IPsec suite / stack.

[shapelytraffic]

Thanks for the suggestions @KOM and @SteveITS
After upgrading the firmware, the traffic started flowing right away. This is an object lesson in "upgrade your firmware first before asking for help".