DNS Domain Override Not Working
-
Hello All,
Long ago I used a PC with pfSense 2.3.4 (July 2017 Build) as my firewall. I had it set up using the DNS Forwarder to send DNS queries for our domain across the VPN to our DNS servers at our data center so that domain stuff would resolve to the LAN IPs but then normal internet traffic like google.com would resolve at pfSense and would not need to traverse the tunnel.
Back then the DNS Resolver did not work for this, even though it had Domain Overrides as an option so we used DNS Forwarder and all was well.
I was then forced to install a Cisco ASA but was able to keep the pfSense machine in the mix as just the DHCP / DNS server and that process kept working.
I've now been able to make the move back to 100% pfSense with the purchase of a Netgate box.
I am now trying to use either DNS Resolver or DNS Forwarder to accomplish this and it does not work no matter which I try.
I removed all setup from the DNS Forwarder and currently have DNS Resolver activated.
My setup is:
My LAN
172.26.10.xDNS Servers (in general setup)
127.0.0.1
1.1.1.1
1.0.0.1DNS Resolver ON
DNS Query Forwarding (have tried both on and off)Domain Override
mydomain.com --> 172.30.10.200 (IP of DNS on other side of tunnel)When trying nslookup like this, it fails:
nslookup server.mydomain.comIf I do this, it works perfectly:
nslookup server.mydomain.com 172.30.10.200Anyone know why this might be or suggestions on how to configure?
Thank you.
-
@beckenrod Is your remote network behind a pfsense device? If so you'll need to allow your local network to access the remote DNS. You would to that at Services/DNS Resolver/Access Lists.
-
@beckenrod It's either a routing or a firewall problem. On what machine are you doing the nslookups? What is its gateway and default DNS? In general, use pfsense packet capture on the relevant interfaces (can limit to src/dest port 53 to troubleshoot DNS). First confirm that the queries are arriving into Pfsense on the expected interface with expected IP destination, then see that they are leaving on the expected interface (VPN); then if you can, check that they are arriving at the DNS server, then follow the replies. Somewhere the query and/or reply is going astray (routed incorrectly) or being firewalled.
Sometimes the packet capture display within pfsense is all one needs, but if you need to look at deeper into packets, use Wireshark: stop the capture, hit "download" and open in Wireshark (you can make your browser do this automatically if you are doing many repetitions).
That nslookup is successful with an explicit server rules out some potential problems, but the packets are not traveling the same route in the two queries, and the query with the explicit server doesn't involve pfsense DNS at all, it's being routed as generic TCP/UDP traffic to the DNS server.
-
Thanks for your replies. The nslookups are failing on my laptop that is on the same LAN as pfSense. What's odd though is if I explicitely request the DNS lookup to go to our active directory server on the other end of the VPN, it works.
The firewall on the other end is a Juniper hosted and managed by our data center provider.
It does seem like a routing issue, but I am not sure where the issue lies.
I was able to get it working via the DNS Forwarder again by using this in the Domain Override there:
Domain
mydomain.comIP Address
172.30.10.200 (AD server on other end of tunnel)Source IP
172.26.10.254 (IP of local pfSense on my LAN)Somehow this seems to trigger the lookup to go over the tunnel.
While this is working just fine, it would be nice to know why the DNS Resolver config does not work. I do not know if there is an advantage to one over the other in my situation but since Resolver is the default and seems to have the correct options, using that would be nice.
Do I need specific rules in the firewall for the VPN?
When I set it up, none were created after the IPSec tunnel was activated. I looked at my old pfSense PC and it had a "pass everything" rule so I created that, but that never solved anything in the DNS Resolver so I am not sure if that did anything.
Thanks again for your help and feedback.
-
@beckenrod I'm not familiar with IPSec tunnels, but (hoping it may be similar enough to help) with OpenVPN tunnels, the tunnel interface appears on Pfsense like any physical interface, and all traffic not originating on the pfsense box itself will be blocked from entering the tunnel (i.e., ingress on the pfsense interface at the near end of the tunnel) by default. Traffic can be passed with a "floating rule" (checked first), a rule on the generic "openvpn" interface (checked next), or a rule on the specific interface.
The near end of tunnel does NAT, and when using the DNS Forwarder, the pfsense box originates the DNS query, so the src IP of the query packet is the IP of the near end of the tunnel, which is its own /30 (2-node) subnet outside your LAN subnet.
Having the additional information you provide, my guess what's happening is that one or more machines beyond the remote end of your tunnel are not expecting any (legitimate) traffic to originate on the tunnel subnet, so either the Juniper firewall is swallowing the query (while allowing queries from the LAN subnet, such as your laptop making a direct query to the remote DNS server, or which you've forced pfsense to use now for the src IP of its own requests), or remote routes are not set up to get the query to and/or the reply packet back from the remote DNS server back to src IPs on the tunnel (but correctly set up for traffic between the DNS server and src IPs on your LAN). I say "my guess" because it's possible something's different about IPSec tunnels, but if not, then I'm confident this is what's happening (though not enough information yet to say whether the problem is lack of a route or the firewall cops along it (or both).) You can take the knowledge that packets with src IPs outside your LAN aren't going to "work" at the remote site to your investigation of the Resolver. Again, pfsense Diagnostics -> Packet Capture is going to be your friend. Select the tunnel interface and write in port 53 (assuming your DNS is on standard port), hit start, do an nslookup, and use level of detail "High" or up to view the capture.
-
@msswift I've made too many edits to last post so I'm being blocked as a spammer. Please cross out "The near end of the tunnel does NAT." It's neither true nor relevant.