Is this normal behavior for the Resolver to act that way?
-
@johnpoz My outgoing connection is WAN, instead of "All" by default. My Interface IP addresses used by the DNS Resolver for responding to queries from clients is LAN and Localhost, instead of "All" by default. Blame it on my OCD monkey, as you said.
The problem appears after a reboot with this configuration. DNS is not working, no messages in all the related logs. I also checked pfblockerng.
To make DNS work again, I need to restart the service as is, OR also select WAN for responding to queries. Reboot in this configuration works but it makes no sense to me. Your thoughts are appreciated. -
@marchand-guy yeah that makes no sense - possible issue with 2.8, when I get a chance I will update my 2.7.2 vm and see if can duplicate your problem.
btw - I don't run all either, my listens are just the interfaces I want to listen on for queries. And my outgoing is just localhost. I don't have wan selected in either of them.
-
@johnpoz outgoing just local host ? That is because you are not forwarding using SSL/TLS, probably. I will try it but I doubt it will work in my case.
Version 2.8.0-RC (amd64)
built on Fri May 16 11:21:00 EDT 2025
FreeBSD 15.0-CURRENTThe system is on the latest version.
Version information updated at Tue May 27 10:23:35 EDT 2025Thank you.
-
@marchand-guy localhost would work with forwarding - or it should, there is no difference if its a tcp connection or just a udp send. I know I have switched over to tls fowarding for testing for other threads and never had to change that.
localhost used as source will be natted as it leaves whatever interface your routing says to use to get to where its trying to go.
edit: here I just turned on forwarding via tls to cloudflare (1.1.1.1) - sure seems to be working to me with just localhost as outbound.
You can test if your using tls on cloudflare here https://one.one.one.one/help/
Take this with grain of salt I guess - this is on my main 24.11 system.. I don't have 2.8 to test with as of yet - need to upgrade my 2.7.2 vm still to be able to test that.
-
@johnpoz I wiil try it and report back. I will even strip my FW of packages and NAT relating to DNS forwarding and OpenVPN client that I have.
Thank you for your generosity in all these matters.
UPDATE:
I can confirm that selecting only Localhost for outgoing interface works, as you showed.
BUT the problem remains for me. DNS is not working after a reboot, if WAN is not also selected. After the reboot, when DNS is not working, restarting unbound brings it back. Again, here, the problem only shows after a reboot if WAN is not selected in Outgoing Network InterfacesI need to test further without any packages and custom NATs. But I doubt that will be it. I also have a floating rule on the WAN interface to block any communication on port tcp/udp 53 (I only use 853). But it does not seem to trigger as I am logging this rule and nothing shows in the logs.
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
Again, here, the problem only shows after a reboot if WAN is not selected in Outgoing Network Interfaces
Not the listening interfaces?
What outbound NAT rules are you using?
-
@stephenw10 said in Is this normal behavior for the Resolver to act that way?:
Not the listening interfaces?
What outbound NAT rules are you using?
No, the problem seems to be related to the selection in Outgoing Network Interfaces.
My outbound NAT rules are as follows:
-
Hmm, I can't replicate that.
Check the state table when DNS is failing. Are there DNS states? On which interface?
-
@stephenw10 Will do but not now. The wife is annoyed when I cut her internet
Good tip on checking the states while failing.
Thank you. -
@stephenw10 If you can't replicate, it means it's particular to my installation. I will need time to investigate.
Thank you
-
How are you testing? After reboot I tested from Diag > DNS Lookup and can see Unbound responding on localhost.
I could imagine the internal forward rule doing something odd at boot perhaps.
-
@stephenw10 Ok! Thank you for sharing that. That is NOT how I test. I test from different machines, starting with my computer. None of my browser bookmarks respond after a reboot of the FW. Until I restart unbound, as stated.
-
Mmm, so it could be some LAN side issue. Try checking from Diag > DNS Lookup locally to narrow it down.
-
@stephenw10 Diag DNS Lookup responds after 16 seconds! No replies on the LAN side with my computer. At this point, the problem is on my side. I will continue to investigate and report anything useful.
Thank you
-
@marchand-guy did you mean 16ms? no client would wait 16 seconds for a response before giving up.. 2 seconds or 5 seconds are normally time limits for dns response.
You could ask a ns on the other side of the planet, and he could ask another ns on your side of the planet and it still shouldn't be anywhere close to 16 seconds.. Something is wrong if your measuring dns response in seconds vs ms.
-
@johnpoz You read it right 16 SECONDS. Clearly, after a reboot, the DNS service is defective until i manually restart unbound from the GUI. I need to backtrack everything I did untill I find the setting that creates this ptoblem. Although I can't stop wondering how many of you use SSL/TLS for outgoing DNS Queries to Forwarding Servers, plus, have not selected All interfaces by default as I did, plus, have disabled IPv6 (even though it is still showing on the dashboard as a listening address for DNS), and have rebooted with that configuration,
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
(even though it is still showing on the dashboard as a listening address for DNS),
there was just a thread about how to make that go away if it bugs you.. That ::1 is just ipv6 loopback. Was that you?
Dashboard isn't a listening address, that is NS that pfsense can use. Not IPs of unbound listening on.
I can tell you there are quite a few users doing the tls forwarding.. I personally don't see the point.. But as you can see from my previous test it works just fine - and makes no sense that it wouldn't work unless your listening on your wan..
You sure you don't have clients pointing to your wan address or something?
Taking a look at your outbound nats - yeah those are borked if you ask me, and could explain your issues maybe - your forcing traffic out your vpn and have no nat for just your normal lan side networks to be able to use your wan IP natted. You followed some idiot guide from some vpn services didn't you.. There is zero reason to do manual outbound nat - just use hybrid and map what you would need for vpn interface you want to route traffic out.
example: I can route anything I want out my vpn connection if I so desire..
Those other outbound nats are to talk to my modem on its 192.168.100 address and I do source natting to talk to cameras behind a nvr because they use the nvr as their gateway.
-
Yup I use forwarding to DoT in 2.8 here without issue.
What does DNS Lookup actually show? For example:
That's with DNS set to 'use local, fall back to remote' in general setup.
If you have other servers that are not responding you will see significant delays.
-
@johnpoz Borked outbound NAT, you say? Here they are again:
I control what goes trough the VPN interface with rules that specify the VPN1 interface. All other rules use the default WAN interface, as it should.
Anyway, I need to investigate further.Thank you.
-
@stephenw10 The "recipe" for ssl/tls forwarding specifies "Set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers"
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
