Can't ping any LAN hosts by host name
-
Home router setup with pfSense, everything as far as internet access (DNS) has been working fine. But, no matter how I twiddle with things (DNS resolver, configured DNS resolution settings, external DNS servers configured or not) no device on the local network can ping or connect either the pfSense box, or any other host on the network.
I've been using mDNS/Bonjour/zeroconf names to connect to LAN hosts for quite a few years. That's still generally working fine. I know the pfSense box can't act as a server for that since it's a decentralized system, and I'm not trying to use the ".local" domain. The pfSense box is using "mylocal", but I've also tried "local.lan".
I can ping all the LAN hosts with the hostname plus the domain that the pfSense box is giving the DHCP clients, but only from the pfSense box itself.
The pfSense box also seems to be trying to ping itself at 10.10.10.1, which I assume has something to do with pfBlockerNG/DNSBL. But I completely disabled both of those and uninstalled that package and it still persists in trying to ping 10.10.10.1. The real subnet is 10.x.y.0/24, so pfSense should be pinging itself at 10.x.y.1.
I've checked the boxes that are supposed to register the static and dynamic DHCP clients for DNS resolution. Still no ability to resolve LAN hosts.
The resolution config is using the default (127.0.0.1 and fall back to remote DNS). The other settings made no difference.
There's obviously something (probably multiple things) I'm not understanding about how the local DNS resolution is supposed to work.
-
@redbearak so what does unbound have for records?
cat /var/unbound/host_entries.conf
-
[2.6.0-RELEASE][admin@pfSense.mylocal]/root: cat /var/unbound/host_entries.conf local-zone: "mylocal." transparent local-data-ptr: "127.0.0.1 localhost.mylocal" local-data: "localhost. A 127.0.0.1" local-data: "localhost.mylocal. A 127.0.0.1" local-data-ptr: "::1 localhost.mylocal" local-data: "localhost. AAAA ::1" local-data: "localhost.mylocal. AAAA ::1" local-data-ptr: "10.x.y.21 mynet-ds220p.mylocal" local-data: "mynet-ds220p.mylocal. A 10.x.y.21" local-data-ptr: "10.x.y.22 synods220.mylocal" local-data: "synods220.mylocal. A 10.x.y.22" local-data-ptr: "10.x.y.23 synods115.mylocal" local-data: "synods115.mylocal. A 10.x.y.23" local-data-ptr: "10.x.y.28 mynet-timecap2.mylocal" local-data: "mynet-timecap2.mylocal. A 10.x.y.28" local-data-ptr: "10.x.y.29 mynet-timecap3.mylocal" local-data: "mynet-timecap3.mylocal. A 10.x.y.29" local-data-ptr: "10.x.y.31 speedefy.mylocal" local-data: "speedefy.mylocal. A 10.x.y.31" local-data-ptr: "10.x.y.32 hap-ac2.mylocal" local-data: "hap-ac2.mylocal. A 10.x.y.32" local-data-ptr: "10.x.y.240 switch1.mylocal" local-data: "switch1.mylocal. A 10.x.y.240"I noticed that I do actually have at least one host on the network that can ping at least one other host on the "mylocal" domain. It's a Mac mini running Big Sur. At the moment I have no idea why that particular machine can ping and other Macs and a Linux laptop can't. Unless I'm not getting a complete reset of DHCP configuration without rebooting every host.
-
@redbearak not sure why your hiding rfc1918 address
But for example there you have switch1.mylocal
So your saying if you do a query for switch1.mylocal to pfsense IP you don't get an answer? What do you get timeout, nx, refused?
example - here I can resolve nas.local.lan
; <<>> DiG 9.16.30 <<>> nas.local.lan @192.168.9.253 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51887 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nas.local.lan. IN A ;; ANSWER SECTION: nas.local.lan. 3600 IN A 192.168.9.10 ;; Query time: 0 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Wed Jul 20 04:58:12 Central Daylight Time 2022 ;; MSG SIZE rcvd: 58 -
For nslookup I get:
;; connection timed out; no servers could be reachedNow for a ping it is suddenly (sort of) working (I rebooted the pfSense box a while ago). This is from the Linux laptop. It is pinging successfully but there is a very long delay of several seconds between pings, indicating something is experiencing difficulty with the reverse name lookup for each ping.
PING mynet-ds220p.local (10.3.9.21) 56(84) bytes of data. 64 bytes from 10.3.9.21: icmp_seq=1 ttl=64 time=0.434 ms 64 bytes from 10.3.9.21: icmp_seq=2 ttl=64 time=0.937 ms 64 bytes from 10.3.9.21: icmp_seq=3 ttl=64 time=0.578 ms 64 bytes from 10.3.9.21: icmp_seq=4 ttl=64 time=0.521 ms ^C64 bytes from 10.3.9.21: icmp_seq=5 ttl=64 time=0.973 ms --- rbns-ds220p.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 40036ms rtt min/avg/max/mdev = 0.434/0.688/0.973/0.222 msNotice no packet loss, but that set of 5 pings took around 30 seconds to complete.
The Mac mini mentioned previously is having none of these issues. It's getting immediate feedback from pinging all the LAN hostnames I've tried.
I get the same delay with the Linux laptop when pinging mDNS/Bonjour hostnames with the ".local" domain. I don't see how that could be related to the pfSense DNS setup but I don't recall having such a delay in mDNS/Bonjour responses before switching from a DD-WRT router to the pfSense box.
-
@redbearak said in Can't ping any LAN hosts by host name:
;; connection timed out; no servers could be reached
Well that is not good.. Do you not have 53 open to pfsense? is unbound listening on that interface?
If it was just an acl problem you would get refused, etc.
Linux can be tricky in how its doing dns, it loves to point to its own local cache notice here its using 127.0.0.53, which is itself. And then that actually ends up going to what it got from dhcp, etc.
user@NewUC:~$ nslookup nas.local.lan Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: nas.local.lan Address: 192.168.9.10 user@NewUC:~$Trying doing directed query in nslookup by setting the server.
user@NewUC:~$ nslookup > server 192.168.9.253 Default server: 192.168.9.253 Address: 192.168.9.253#53 > nas.local.lan Server: 192.168.9.253 Address: 192.168.9.253#53 Name: nas.local.lan Address: 192.168.9.10 > -
nslookup mynet-tech.local Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find mynet-tech.local: NXDOMAINnslookup > server 10.3.9.1 Default server: 10.3.9.1 Address: 10.3.9.1#53 > mynet-tech.mylocal ;; communications error to 10.3.9.1#53: connection refusedI've already tried switching between different network interfaces on the Linux laptop. Wireless access points and wired. I would have thought that would be enough to get the current DHCP info on the laptop and have it working just as well as the Mac mini that doesn't seem to be having any kind of problem.
-
@redbearak said in Can't ping any LAN hosts by host name:
;; communications error to 10.3.9.1#53: connection refused
So refused - this is different than not being able to talk to unbound on pfsense, this is unbound saying - oh hey buddy, sorry your not on my acl to allow to talk to me. Or you not allowed to query that, etc. Or maybe you have a reject setup on your firewall rules?
Now by default, acls are auto created and list who can ask.. But if you turned that off, or if your source IP is different than actual network pfsense
You can look in your acl..
cat /var/unbound/access_lists.conf
[22.05-RELEASE][admin@sg4860.local.lan]/: cat /var/unbound/access_lists.conf access-control: 127.0.0.1/32 allow_snoop access-control: ::1 allow_snoop access-control: 10.0.8.0/24 allow access-control: 10.0.200.248/29 allow access-control: 127.0.0.0/8 allow access-control: 192.168.2.0/24 allow access-control: 192.168.3.0/24 allow access-control: 192.168.4.0/24 allow access-control: 192.168.6.0/24 allow access-control: 192.168.7.0/24 allow access-control: 192.168.9.0/24 allow access-control: 192.168.200.0/24 allow -
cat /var/unbound/access_lists.conf access-control: 127.0.0.1/32 allow_snoop access-control: ::1 allow_snoop access-control: 10.3.9.0/24 allow access-control: 127.0.0.0/8 allow access-control: ::1/128 allowAll my hosts are definitely getting on the 10.3.9.0/24 subnet via DHCP, either dynamic or static. I have no issues whatsoever pinging IP addresses. Just hostnames.
-
@redbearak yeah I see your 10.3.9/24 network there as allowed.
You sure your client is coming from 10.3.9/24 address
I can duplicate refused, if I remove 192.168.2/24 from my access list.. And then ask 192.168.2.253 from a 192.168.2.12 client
user@NewUC:~$ nslookup > server 192.168.2.253 Default server: 192.168.2.253 Address: 192.168.2.253#53 > nas.local.lan Server: 192.168.2.253 Address: 192.168.2.253#53 ** server can't find nas.local.lan: REFUSED >Refused - but also that says your having issue talking to 10.3.9.1 - what are your firewall rules on this 10.3.9.1 interface in pfsense - do you have maybe a reject setup?
communications error to 10.3.9.1#53
-
I haven't set up any kind of refusal rules that I know of. I'm pretty new to pfSense and tried to keep it as simple as possible for now. How do I output the firewall rules in a simple text format?
All hosts are being served by the same single LAN connection out to a switch and the same DHCP server (the pfSense box). All hosts are using DHCP to acquire an address. The Linux laptop has DHCP configured on both wired and wireless network interfaces. Nothing weird going on there.
The laptop is on Wi-Fi at the moment, showing it on the 10.3.9.0/24 subnet:
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 18:26:49:2d:b5:nn brd ff:ff:ff:ff:ff:ff inet 10.3.9.136/24 brd 10.3.9.255 scope global dynamic noprefixroute wlp4s0 valid_lft 2441sec preferred_lft 2441sec -
@redbearak easier to just post a screen shot of your rules.
but if your saying your default rules are the default lan any any rule?
And you don't have anything in floating?
So are you saying you can lookup say google via nslookup pointing to your 10.3.9.1 address, just not local resources?
If you change your server to 10.3.9.1 in nslookup and then ask for say www.google.com - that works?
user@NewUC:~$ nslookup > server 192.168.2.253 Default server: 192.168.2.253 Address: 192.168.2.253#53 > www.google.com Server: 192.168.2.253 Address: 192.168.2.253#53 Non-authoritative answer: Name: www.google.com Address: 142.251.32.4 Name: www.google.com Address: 2607:f8b0:4009:81c::2004 >
-
Actually no, I noticed that if I requested public domains like www.google.com I got the same "connection refused". So... I guess the Linux host isn't really talking to 10.3.9.1 for DNS at all?
I have four LAN ports bridged together, so here are the floating rules and the bridge/BR0 and LAN1 rules. There's nothing on LAN2/3/4.
-
@redbearak said in Can't ping any LAN hosts by host name:
I got the same "connection refused". So... I guess the Linux host isn't really talking to 10.3.9.1 for DNS at all?
Then where is getting dns from?
Your lan rules there show no evaluations at all thos 0/0 B
And you have no bridge rules - so how is anything using pfsense to get to anywhere?
Oh my bad - your no rules are on br0
I would remove all that bridging nonsense - you mention you have a switch.. remove all the bridge stuff and just use 1 port.. On pfsense..
-
I'd much rather just make sure the bridge is actually working as intended. It's a 6-port fanless box with Intel i225v3 2.5GbE ports. Having three leftover 2.5GbE ports that will never be able to do anything seems like a huge waste. But if it's actually a problem I can follow the instructions in reverse and remove the bridge setup.
The Linux laptop seems to just talk to itself (127.0.0.53) and then I guess it goes right to the external DNS servers. It's never seemed to be a problem. The response is very quick.
nslookup www.google.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: www.google.com Address: 74.125.199.147 Name: www.google.com Address: 74.125.199.103 Name: www.google.com Address: 74.125.199.105 Name: www.google.com Address: 74.125.199.106 Name: www.google.com Address: 74.125.199.99 Name: www.google.com Address: 74.125.199.104 Name: www.google.com Address: 2607:f8b0:400e:c09::68 Name: www.google.com Address: 2607:f8b0:400e:c09::69 Name: www.google.com Address: 2607:f8b0:400e:c09::93 Name: www.google.com Address: 2607:f8b0:400e:c09::6aOn the other hand, the Mac mini definitely talks directly to the pfSense box IP for DNS. At least that's what the response from nslookup showed.
None of this makes any sense to me. The LAN ports are bridged but there is still only a single LAN cable plugged in so far, going to a 16-port switch, and from the 16-port switch to another 8-port switch upstairs in the small office where the Mac mini is located. If the bridge was affecting anything it should also have the same affect on the Mac mini.
-
@redbearak said in Can't ping any LAN hosts by host name:
The LAN ports are bridged but there is still only a single LAN cable plugged
Then why bridge anything?? Makes no sense to complicate your setup with a bridge..
-
@redbearak said in Can't ping any LAN hosts by host name:
it should also have the same affect on the Mac mini.
Lets see you mac mini do a directed query and look up local resources.
-
The point of the bridge is to potentially (in the future) use the extra LAN ports on the pfSense box to provide a 2.5GbE backbone to up to 4 different locations in the house with 2.5GbE switches, without needing yet another 2.5GbE switch at the location of the pfSense box, costing probably another $200.
Another point of the bridge is just to learn how to set up a bridge. And consumer routers pretty much all come with a few switch ports so the device is a bit more useful to home users on a budget. I just wanted to see if a pfSense box could do something similar. It can, and I haven't really seen any logical arguments online for why it's not a valid idea.
All the bridged ports do work as expected, and hand out DHCP leases from the BR0 virtual interface. I just haven't added any other direct connections yet while I'm making sure the basic routing stuff is actually working like I want.
The Mac mini has always shown that it was connecting to 10.3.9.1 when I used nslookup. I made it explicit with the server directive and I get the same instant response for the local domain hosts from the pfSense box.
And... That's a big clue. I think I just figured out my problem. Some of my hosts happen to be using individual VPN client software, for work purposes and privacy on public hotspots, and the Mac mini usually isn't connected to one. Of course the VPN client software typically automatically sets things up to bypass the ISP -- and usually the local -- DNS servers when you're connected to the VPN.
So there we go. I'll have to configure the VPN clients to use local DNS or find some other solution if I want to be able to ping/connect to the LAN hosts by name with the pfSense DNS resolver while still on the VPN.
Funny how this has never been an issue over the years when using the mDNS/Bonjour/zeroconf decentralized ".local" domain names. So I didn't think of the VPN software until now as a possible cause of the issue. No wonder it was working perfectly on one host but not others. There's actually nothing wrong with the pfSense box configuration. It's the hosts that are the problem.
Setting the VPN client software to use "Existing DNS" solves the issue, but is a definite blow to basic privacy if used like that outside my home network. I hesitate to try and put the whole network on a VPN because most of the VPN services I've tried tend to cause streaming services to throw a fit and demand that you disconnect from the VPN, even when I make sure it's on a US server.
The only way I can think of to bypass that kind of issue is setting up a custom VPN on Linode or something, and making sure it has a US IP address. But with how testy the streaming services are getting these days if you're using any kind of proxy it wouldn't surprise me if they are already blocking or planning to block all IP blocks connected with hosting companies like Linode.
Thanks for the feedback in trying to figure out the source of the problem. PEBKAC, as usual, right?
Only remaining problem is I still can't ping the pfSense box itself by its configured hostname, even from within the pfSense UI or SSH. So that's pretty weird. It's not even giving me the invalid 10.10.10.1 address anymore.
But since Avahi is installed, I can connect to it from LAN hosts with "pfSense.local". Except from within itself. It's at that hostname according to the rest of the network, but internally it has no idea that it's at that hostname.
Can't solve every mystery all at once, I guess.
-
@redbearak said in Can't ping any LAN hosts by host name:
The point of the bridge is to potentially (in the future) use the extra LAN ports on the pfSense box to provide a 2.5GbE backbone to up to 4 different locations in the house with 2.5GbE switches, without needing yet another 2.5GbE switch at the location of the pfSense box, costing probably another $200.
Bridging in BSD should be used in a very sparing, limited function. It's not a switch, it's a router. You're asking it to switch packets -- that's what we have switches for.
In my experience bridging on pfSense is best done in very limited, very short-term, and very last-resort scenarios.
-
I see. I suppose that means consumer routers actually have hardware switch chips running the LAN ports and connecting the switch to the "router" part.
Are we talking about stability issues if pfSense is asked to handle multiple 2.5GbE LAN-to-LAN streams on the bridge, even without any additional filtering rules? It's an Intel N5105 with 16GB of RAM and all Intel NICs. I was assuming BSD on this hardware would have enough juice and stability that the lack of hardware switching wouldn't really be an issue, at least for a home network. BSD has long had a reputation of being very efficient at handling high network traffic. Especially with Intel NICs.
It's only using a tiny fraction (2-4%) of the available memory and CPU so far. But that's on a low-bandwidth ADSL connection.
If bridging is really something BSD can't do reliably, I'll have to think about removing the bridge, or at least just not using more than the one LAN port. But all the discussions I've seen online just basically say that it will take up CPU resources and a switch will be more efficient at the job. Which, well, of course.
