Internal DNS Not Working
-
@aiden21c
Hi! What you are seeing may be the expected behavior, because:
This here is not what DNS servers PfSense uses per WAN connection, but rather (as per your choice to use local DNS first):- First try localhost (self) DNS
- If not working, try 1.1.1.1 and send all queries from opt1
- If not working, try 1.0.0.1 and send all queries from wan
Next, you specified in Unbound (forwarding mode), that all queries should be sent from WAN2. Unbound then grabs the first DNS from above (1.1.1.1), sends queries through WAN, but expects answers from WAN2, answers that never come (on that interface).
You should either set the DNS interface to "None" in general setup, or create another 2 entries for the WAN interface.
And, in any event, 1.1.1.1 cannot receive queries from the Office interface, it should be either WAN or WAN2 (or, if you want my advice, none).
If you want to see what DNS is used in each query (to confirm what is happening) see dig and nslookup (for Windows clients).
-
@nightlyshark I have done the following to no avail. I have also hard restarted the pfsense to see if that helps but it did not. By setting "none" in general setup it actually meant that even the clients weren't able to resolve any host names until I changed this back.
-
@aiden21c
Please follow all instructions.
Set Unbound to recursive mode (disable forwarding mode).
After that, make sure that you have no DNS servers in DHCP Server and in DHCP-v6-RA -
-
-
@aiden21c You should also enable DoT in Unbound. You will need a rule for port 853.
-
@aiden21c Just noticed that... Did you use the LAN interface address of PfSense to query DNS? Try WAN or WAN2, first. LAN network is NATed, LAN address is not.
-
@nightlyshark I apologise, your instructions weren't very clear so I'm not too sure exactly what to change. What I have done:
- Unchecked "Enable forwarding mode" in the DNS resolver
- Set "Network interfaces" to "All" in the DNS resolver
- Tried both enabling and disabling the "Enable SSL/TLS Service"
All this did was actually take my client down and my client was no longer able to resolve DNS quieries.
I have set all the settings back to how they were originally in order to get my client back online. I then ran a "dig" from the pfsense shell and obtained these results.
-
@aiden21c said in Internal DNS Not Working:
Set "Network interfaces" to "All" in the DNS resolver
If you're using IPv6 there is a bug where using All doesn't set up the ACL entries to allow clients to query DNS.
Patch ID: 46b159032fef8c78783aa1a749d2238cfed7ac0d
https://forum.netgate.com/topic/176989/problems-with-pfsense-ipv6-dns-function-does-it-exist/36 -
@steveits I am not using any IPv6. I have also reset this setting back to only responding to queries from "LAN" and "LocalHost".
-
@aiden21c Let's take it in steps:
- (If it were me) Remove the extra servers in General Setup (for now)
- Set DNS Resolver as:
- Set all interfaces with DHCP in DHCP server as:
- Allow LAN to DNS (both TCP and UDP), LAN to DoT (TCP)
- Setup NTP correctly (DoT may have problems if clock is wrong)
- Provide a diagram of your network (along with exactly how you connect to WAN), so I (or others) can direct you what to do (and explain each step so you will be able to change config later by yourself)
-
@aiden21c Also, as per dig, all is OK. You just tried pinging from the LAN ip of PfSense, which isn't NATed (meaning, it can't reach the internet, only WAN can).
-
@aiden21c Next try
-
@nightlyshark No good unfortunately. I have done the following:
My network setup is a concurrent dual wan setup. This is where I route all traffic out of WAN2 (my main WAN connection) and only traffic directed to the networks specified in the routing rules will be routed through WAN1. I eventually want to have VPN traffic come down through WAN2 and be able to reach the network on WAN1.
-
@aiden21c I have now found another very weird issue. I have reset my settings to give the client device access to the internet, and it seems as though when I reset these settings, the DNS forwarder is working exactly as expected. Btw there is no DHCP on the LAN.
It seems that with my testing, I am actually only able to use the diagnostics to ping only the IP addresses specified within the General setup page. It doesn't matter what IPs I set in here, but so long as they are assigned to a gateway I can ping these from any of the 3 interfaces (2 WAN and 1 LAN). Examples:
General Setup
8.8.8.8 - wan2 gw
8.8.4.4 - wan1 gw
ping success to 8.8.4.4 and 8.8.8.8 from all 3 interfaces
ping failure to 1.1.1.1 and 1.0.0.1 from all 3 interfacesGeneral Setup 2
1.1.1.1 - wan2
1.0.0.1 - wan1
ping success to 1.1.1.1 and 1.0.0.1 from all 3 interfaces
ping failure to 8.8.8.8 and 8.8.4.4 from all 3 interface -
Here are the traceroutes to the hostnames of the DNS servers which are specified in the general setup page. Traceroutes fail if I attempt any other hostnames. In general setup, for this to work I need to set both gateways to use the DNS pair from the same provider, otherwise the opposing WAN and LAN wont be able to reach. Below I used 1.0.0.1 on WAN2 an 1.1.1.1 on WAN1.
When DNS servers from different providers are in General Setup, I can ping both IPs from any interface, but I can not traceroute to both hostnames, only the IPs.
-
@aiden21c I suggest using the DNS lookup diag page to test DNS problems. While Google DNS should answer pings, testing by ping introduces another layer. One problem at a time . :)
Re pinging DNS servers, I believe pfSense sets up routing entries for them specifically. Ensure you have a default route and/or routing is correct.
-
@steveits as is visible above, DNS lookup was actually working. I was able to lookup facebook.com and have repeatedly been able to lookup google.com and others. I think this is likely a firewall or NAT issue, or something else entirely.
I still can't get my head around why my LAN client is able to use pfSense as it's dns and everything works fine, but the pfsense itself is having DNS (and outgoing Ping) issues, as I'm not actually able to use the ping diag tool to ping any IPs other than those specified. -
My turn.
I left "Resolving mode" for 48 hours.
I've tested Forwarding for a while.I chose "1.1.1.1" - so I went to to 1.1.1.1 set up instructions. I even added TLS support.
So : first :
Take note : strictly speaking, I have just one WAN, but IPv4 and IPv6 are separate. Half of all my outgoing traffic is IPv6 these days.
Then : Unbound :
I made no changes to the Unbound Advanced page, neither the ACL page.
I have no floating rules.
A DNS NAT rule for a specific interface : I force the (captive) PORTAL network to use 127.0.0.1 : that's unbound. I might as will delete this rule, I'm not using it myself.
And that's it.
This morning, I even forgot about the fact I was not resolving anymore.Since the day before, unbound didn't restart.
No DNS interruptions as far as I know.
During breakfast this morning, no captive portal clients were complaining.Btw : I'm using 23.01.
I've done an identical test during one week with 22.05
Same thing with 2.6.0, the CE version.
Using a SG-4100.
I was using VDSL before January, 15, 2023. Since then, fiber. -
@gertjan @aiden21c Please remove all port forwards or firewall rules that redirect or block DNS. If you have such rules activated with recursive mode, you are essentially redirecting Unbound packets back to itself.
@Gertjan Happy it works, anyway. Sorry for the edits, rushed to answer without drinking my coffee, first .