No internet on LAN
-
I would try disabling dnssec in Unbound. It may have failed to pull in the valid keys at first boot because of the original subnet conflict. Though I would have expected it to do so on subsequent reboots. And to be logging an error somewhere.
-
@johnpoz @stephenw10
Unfortunately I did not take a snapshot, because I have tried multiple times to reinstall, and am completely unable to get a WAN address from the installer, as well as multiple attempts to assign the interfaces , and the set interface IPs
THis happened last time, but eventaully I was able to get to a promt that told me to ensure the WAN link was up/plugged-in and press enter, then did the same for LAN, and that was how I was able to get an address for both WAN/LAN
currently I cant even get to the web configurator when connected to the LAN
-
@rakya well your not going to be able get anywhere without a wan ip.. If your wan is 192.168.1 your going to need to change your lan IP when you first set it up.
-
@johnpoz @SteveITS
Any ideas on how to work the install to see why I am not getting a WAN address?
If I plug the same cable that I am trying to (and was previously successful) use as a WAN connection into my laptop or phone, I am immediately connected to my buildings LAN -
Which Im not keen on since I was able to confirm I can Wireshark my neighbors traffic from my parking lot!
I dont know if that LAN/WAN introduces a subnet conflict, as @stephenw10 thought in the first reply 3 days ago... Any thoughts? -
@rakya if you can not get a IP your wan, its never going to work.. But your lan and wan can not overlap if you want connectivity to work.. When you install pfsense you can set the IP on the lan to something other than the 192.168.1 network..
What is this wan connectivity exactly..
I was able to confirm I can Wireshark my neighbors traffic from my parking lot!
Huh?
-
@rakya said in No internet on LAN:
I moved my LAN IP to 192.168.0.1
Do that again. At least as a test. If there is a conflict between WAN and LAN it will always fail.
-
@johnpoz
I'm an idiot and didn't realize the interfaces on the NIC cards were reversed in software from my last install. I have a WAN now, and I have a totally stock installation, but I am seeing the same ping behavior as before.
I can ping 8.8.8.8, but not google.com
nslookup cannot find www.google.comI also see the same reply to
unbound-control -c /var/unbound/unbound.conf lookup .The following name servers are used for lookup of . no delegation from cache; goes to configured roots -
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.
