Is this normal behavior for the Resolver to act that way?
-
@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!
-
@stephenw10 Exactly. Still investigating.
-
@stephenw10 So, I removed every packages, every openvpn clients (and associated interface, NAT and rules. Every rules and NAT forwarding related to DoT.
What remained for me was to put the NAT rules to automatic instead of manual. Since I upgraded to 2.8 CE from 2.7.2 the rules went from (forget the VPN1 interface, it was removed. this is an old picture):
To:
I then made sure to only select the DNS interfaces as follow:
Network interface LAN, Localhost
Outgoing network interface WAN, LocalhostAnd rebooted the FW.
This setting breaks the resolution sevice on the LAN side, as no internet sites are acessible via browser or apps.
Until I manually restart the unbound service. Then everything works.
At this point, I'm troying the towel and leaving the interfaces used for DNS at their defaul values; which is "All" for both settings. Everything works after that with a reboot.
F**k you OCD monkey!
