Is this normal behavior for the Resolver to act that way?
-
@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
-
@marchand-guy your previous post was missing this one
-
@johnpoz I know. That's why I reposted it. I should have guessed that you would make the effort of looking at it
-
@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.
