No internet on LAN
-
Something upstream blocking DNS maybe?
We previously saw that pfSense can resolve against the server passed by the upstream router. Can it resolve against anything else:
[2.7.2-RELEASE][admin@t70.stevew.lan]/root: dig +short @8.8.8.8 google.com 172.217.16.238 -
@stephenw10
That dig command seems to work...
But when I run it without the 8.8.8.8 reference and try to trace I get nothing
-
Did you try disabling dnssec?
-
@stephenw10
Yep. Just did (saved & applied changes), but no luck. Same behavior in ping, unbound-control, and dig -
@rakya at a loss to what would cause that.. Your saying this is clean out of the box install and you get that
no delegation from cache; goes to configured roots
Could you try setting your outbound in unbound interface to something other than all, I just use localhost, but you could try localhost and lan, etc..
That response is weird..
-
@johnpoz
I set it to localhost and nothing happend, but then I set it to LAN and looks like everything is WORKING!!!Looks like it is a combination of DNS outbound network interface set to LAN and DNSSEC being disabled
-
@rakya dnssec shouldn't be the problem..
So you now see the roots when you do that command?
If you were forwarding I would for sure suggest turning off dnssec, but if your resolving which is what unbound does out of the box - dnssec is good thing to have enabled.
-
@johnpoz
set DNSSEC to disabled first, then I set DNS outbound network interface to LAN and I was able to watch youtube
I then re-enabled DNSSEC and websites no longer work. I woujld like to have DNSSEC set up given my unsecure building settings... -
@rakya dnssec should work out of the box.. could you do a simple test
on pfsense do
dig @1.2.3.4 www.google.com
This should not answer, if it does your dns is being intercepted..
1.2.3.4 should not answer for dns.. If it does then something is intercepting/redirecting your dns.
[23.09.1-RELEASE][admin@sg4860.home.arpa]/: dig @1.2.3.4 www.google.com ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ; <<>> DiG 9.18.16 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; no servers could be reached [23.09.1-RELEASE][admin@sg4860.home.arpa]/:But here for example on a client where I redirect dns..
$ dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.45 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6040 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 30 IN A 142.250.190.100 ;; Query time: 4 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) ;; WHEN: Mon Jan 22 22:38:31 Central Standard Time 2024 ;; MSG SIZE rcvd: 59 -
@rakya I’ve lost track, are you forwarding? If you are, DNSSEC is expected to cause problems. If not it should just work.
Note DNSSEC is not encryption.
-
-
@rakya well clearly something upstream is intercepting/redirecting your dns.. That is clear if you got an answer from 1.2.3.4..
1.2.3.4 is not nameserver for anything - it wouldn't answer.. If your getting an answer something upstream is redirecting your dns.. Do you have some router in front of pfsense?
Where you saw the answer from 1.2.3.4 was my on purpose redirection of to my dns server.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
If on pfsense you did a query to 1.2.3.4 and got an answer something up stream of pfsense is redirecting your dns. And would for sure explain why dnssec fails..
edit
There are a few other ways to validate redirection/interception.. If you query 1.2.3.4 and get an answer, that is really a smoking gun.here is another example of dns being redirect.. See how top one gives an answer, but bottom doesn't
if your being redirect that will normally fail..
Another way is aa flag being missing when you do a directed query to authoritative ns..
-
Aha! Well that's not great. I suspected it might be something like that since the DNS passed by DHCP to pfSense was working.
You could try forwarding and using DNSoverTLS (DoT) which may not be blocked.
Or resolve directly over a VPN.
Or call the ISP and ask them why they are intercepting DNS queries.
-
@stephenw10 we sure its ISP... he has 192.168.1 on the wan? This points to some nat router in front.. ISP wouldn't normally use that range.. They would cgnat it..
edit: btw a few other ways to spot interception/redirection - response time doesn't make sense.. query some ns that is far away and you get response way faster than is possible. Or query an authoritative NS directly and not get the full ttl.
And yeah dnssec failure across the board to any domain - suggests interception as well. 1 domain failing, maybe they have dnssec misconfigured, or its been messed with specific. But all failing - something is up..
But a directed query to some IP you know for a fact doesn't do dns, and you get a response - this is clear smoking gun.
edit2: here is perfect example.. Doing a query directly for ns of top site in china, very far away from me..
[23.09.1-RELEASE][admin@sg4860.home.arpa]/: dig @110.242.68.134 baidu.com ; <<>> DiG 9.18.16 <<>> @110.242.68.134 baidu.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2295 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 10 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 3f28202a8e4040370100000065afc47fc3073eb24d195f85 (good) ;; QUESTION SECTION: ;baidu.com. IN A ;; ANSWER SECTION: baidu.com. 600 IN A 110.242.68.66 baidu.com. 600 IN A 39.156.66.10 ;; AUTHORITY SECTION: baidu.com. 86400 IN NS ns3.baidu.com. baidu.com. 86400 IN NS ns2.baidu.com. baidu.com. 86400 IN NS ns4.baidu.com. baidu.com. 86400 IN NS dns.baidu.com. baidu.com. 86400 IN NS ns7.baidu.com. ;; ADDITIONAL SECTION: dns.baidu.com. 600 IN A 110.242.68.134 ns2.baidu.com. 86400 IN A 220.181.33.31 ns3.baidu.com. 86400 IN A 36.155.132.78 ns3.baidu.com. 86400 IN A 153.3.238.93 ns4.baidu.com. 86400 IN A 14.215.178.80 ns4.baidu.com. 86400 IN A 111.45.3.226 ns7.baidu.com. 86400 IN A 180.76.76.92 ns7.baidu.com. 86400 IN AAAA 240e:bf:b801:1002:0:ff:b024:26de ns7.baidu.com. 86400 IN AAAA 240e:940:603:4:0:ff:b01b:589a ;; Query time: 264 msec ;; SERVER: 110.242.68.134#53(110.242.68.134) (UDP) ;; WHEN: Tue Jan 23 07:51:59 CST 2024 ;; MSG SIZE rcvd: 356Notice 200 some ms away, which would make sense if in china and I am in the us.. But check out the ttls, and response time from my redirected test.
$ dig @110.242.68.134 baidu.com ; <<>> DiG 9.16.45 <<>> @110.242.68.134 baidu.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7171 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;baidu.com. IN A ;; ANSWER SECTION: baidu.com. 3596 IN A 110.242.68.66 baidu.com. 3596 IN A 39.156.66.10 ;; Query time: 10 msec ;; SERVER: 110.242.68.134#53(110.242.68.134) ;; WHEN: Tue Jan 23 07:54:24 Central Standard Time 2024 ;; MSG SIZE rcvd: 70You might have to do the query a couple of times, first one might have long time - if where your being redirected too had resolve it.. But notice hey where is all the extra info got when did a directed query.. 10 ms to ns in china? The ttl is counting down - that doesn't happen if directly query authoritative ns for a domain.
You might also notice the aa missing in the query that was redirected by me.. There are many ways to spot when dns is being messed with.. Which is why I normally recommend if you don't want something using another dns just to block vs redirect. This way the end user will know right away.. Vs maybe not knowing that their dns is being redirected.
-
@johnpoz it could be my buildings' router that is blocking the DNS queries. Right now I have 3 networks going on. The buildings'LAN/wifi, my unifi router/switch/WAP, and this pfSense VM. the last two are using the buildings' LAN as their WAN, and both have 192.168.0|1 subnet masks
I won't have time today to do the above tests, but will definitely get to it tomorrow. I would also like to maintain DNSSEC and as many defaults as possible before doing my own exploration with subnets and plugins.
Thank you all for your help so far!
-
@rakya well not so much "blocking" they are redirecting to something that is for sure.. For dnssec to function correctly you need to be talking directly to the authoritative name servers for a domain, to validate.. If your being redirected that doesn't function correctly.. Also why dnssec makes no sense when you forward.. While you might not get dnssec validation failing all the time, it quite possible it will fail because of the nature of how dnssec works when you forward.. It is pointless to try and do dnssec when you forward.
If your dns is being redirected, dnssec is not going to function correctly.. To get around the redirection, you could do dns over tls, dnssec will be done to where you forward to in this case.. When you forward, where you forward too either does dnssec, or they don't you asking unbound to directly do dnssec if fowarding is not a valid setup.
You could route your resolving via vpn.. If that is the case then you could do dnssec.
-
Yeah I was assuming the 'building' is the provider in this case.
-
@stephenw10 ah ok.. It might be done on accident, its possible just some default function of the router being used at the location. Or it could be done with purpose? If isp is doing it, I would get with the isp and ask for why.. And if can not get a valid answer, and have them turn that off for you - I would be searching for a different ISP to be honest.
If the building has it enabled, ask them to disable that feature - at least for your connection. It is possible the building is trying to do a good thing and have the router cache dns for its users.. And doesn't really understand the implications of redirection of dns.. And had turned on dns redirection in the router not understanding exactly what that meant.
-
@johnpoz Just to hop in, it may not be malicious in intent…we thought about it briefly for our building, to forward to a DNS filter, but decided it wasn’t worth any potential confusion/hassle (from anyone who knew what they were doing).
-
@SteveITS completely agree, it could be an attempt at helping without understanding the full implications.. Completely agree.
