Is this normal behavior for the Resolver to act that way?
-
@marchand-guy said in Is this normal behavior for the Resolver to act that way?:
"Set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers"
yeah technically that is true - or you could have a scenario where pfsense directly talks to servers you have in general without the tls. So guess you have to live with the ::1 listed as NS you could talk to ;) Or you could run into a scenario where pfsense doesn't use tls to talk to your remote tls server you want to talk to. When itself wants to resolve something - like is there an update available, need to pull the list of available packages.. etc. but clients talking to pfsense IP for dns would not.
-
Yup that's why I mentioned it since you would normally only see local host there if you have followed the guide.
But importantly you should not see anything that's present and unresponsive.
-
@stephenw10 said in Is this normal behavior for the Resolver to act that way?:
you would normally only see local host there if you have followed the guide.
Not according to the doc at https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html#figure-dot-servers
But maybe I misunderstand what you are meaning.
What I see on the dashboard is:
-
@johnpoz said in Is this normal behavior for the Resolver to act that way?:
but clients talking to pfsense IP for dns would not.
And I made sure of that with this NAT:
(and yes, I tried without it)And I go further withe these rules (and yes, I tried without them):
-
Oh, you're right it does still test them from Diag > DNS Lookup even if it ignores them for real resolution.
-
UPDATE:
After stripping the FW of all packages, openVPN client, NAT and rules associates, it turns out that the openVPN client installation is causing the problem. I suspect it has something to do with the DNS it is trying to use, as I am not allowing it to use it's own resolver. I will read further on that and try in making it work. Thank you all.Correction: This morning stripping th FW did not correct the problem. Until unbound restarts.
-
@marchand-guy your problem is most likely you are routing all traffic out your vpn - even your tls dns..
-
@johnpoz Not according to pftop. I have rules that specify when going thru the VPN interface.
-
But is the client allowing the remote server to pass it a default route?
-
@stephenw10 I don't think so:
-
I usually just set don't pull routes. But it's easy enough to check what's happening there in the routing table.
You can't policy route traffic from the firewall itself so it will just use the system default route at that point. I'd bet that's what's happening.
-
@stephenw10 I will try.
Thank you. -
@marchand-guy yeah a peak at your routing table will tell you - you could also look here
the gateway you have set for your vpn should not be the default.
-
@johnpoz Looks good:
file:///home/guy/Downloads/Screenshot%20from%202025-05-30%2011-56-16.png -
@stephenw10 I tried the openvpn client seeting on not pulling route. It did not clear the problem. Furthermore, the gateway monitoring function for the vpn interface stopped working properly.
But your suggestion remains valid concerning the routing. Still investigating. -
@marchand-guy not sure what there is to "investigate" just look in your routing table. take all of 2 seconds
Unless you have a more specific route for your NS your pointing to - its going to go out the default route.
-
@johnpoz said in Is this normal behavior for the Resolver to act that way?:
@marchand-guy not sure what there is to "investigate"
Semantics...Looks fine to me but we don't have the same version, so:
file:///home/guy/Downloads/Screenshot%20from%202025-05-30%2012-54-37.png -
@marchand-guy well from that there its not routing traffic out any vpn..
I have 2.8 running now and could test.. But I can tell you with like 99.9% certainty I will not be able to duplicate it.. Because if 2.8 broke dns resolution with users that use vpn - the forums would be on fire with people complaining. So pretty sure whatever your issue is unique to your setup.
-
@johnpoz Agreed!
Thank you, again
-
It only happens after reboot though and restarting unbound after boot corrects it. So that suggests that the default route is wrong when Unbound initially opens the outbound state during boot only. For some reason!
