upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access'

stephenw10

Hmm, by default both subnets would use the pfSense interface IP as the DNS server. The would be Unbound in pfSense and if LAN devices are registered there then they should resolve for both subnets.

First try resolving from the wifi client and see how it fails. Perhaps that device is using a hardcoded DNS server? Did you ever include firewall rules to redirect DNS?

skubany2

When the WiFi client is wired (cable) then it can access the other device via it's host name, because they're both on LAN at that point.

WiFi client is assigned DNS Servers by DHCP Server running on WiFi interface. I tried adding LAN's DNS Server as secondary entry under WiFi interface's DHCP Server but that did not change anything. I did notice at that point that WiFi client was showing two DNS Servers configured, instead of the usual one.

I did not explicitly set any DNS redirection firewall rules.

stephenw10

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

I did notice at that point that WiFi client was showing two DNS Servers configured, instead of the usual one.

And they are both the pfSense interface addresses? Or are you using other DNS servers?

If you try to resolve one of these hosts on a wifi client what error do you see?

skubany2

@stephenw10 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

And they are both the pfSense interface addresses?

Yes.

The issue is on my parent's network and they're far away from me. On my home network I have WiFi client running VNC Server so I'll use that for testing. Using VNC I can connect from LAN to WiFi client fine when using it's IP, but when I use it's host name VNC can't resolve the name.

While testing with VNC when I capture packets on the LAN interface I see LLMNR (Link-local Multicast Name Resolution) requests and NBNS (NetBIOS Name Service) requests for the host name but don't think they're being responded to by anyone. Nothing of interest on WiFi or WAN interfaces.

stephenw10

How are you testing? Try to dig at pfSense on each address directly like:

2.8.1-RELEASE][admin@cedev-2.stevew.lan]/root: dig @172.21.16.1 +short plusdev-2.stevew.lan
172.21.16.167
[2.8.1-RELEASE][admin@cedev-2.stevew.lan]/root: dig @192.168.126.1 +short plusdev-2.stevew.lan
172.21.16.167

One thing you might be seeing is the client device not sending the domain the in query automatically for servers outside the domain.

But both IP addresses should be able to resolve the FQDN. The are both the same server server and data.

skubany2

I've done some testing yesterday. Testing was largely about reaching shared folder on LAN client from WiFi client. I was testing host name vs IP.

I have to make sure that DNS queries are not blocked. In my configuration WiFi interface in general can only reach WAN, not LAN and I have many disabled rules that I activate (one at a time) when I need to reach a LAN client.

I noticed that turning off Windows firewall on the LAN client helped in allowing WiFi client to reach it but I think this was in the case of using IP. Host name still did not work. Windows firewall was never an issue but that is when I only had Win7 machines at home. Now that I have added Win11 to the mix they might not be playing nice with each other with default settings.

Adding secondary DNS (of the other interface) under each interface's DHCP Server may also be needed. I will also look at the DNS Resolver and Forwader to see if I need to change anything there.

I will be testing DNS (rules/settings) and Windows firewall settings while running packet capture. This will take a few days but I know what to focus on and will report back with my findings.

stephenw10

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

I was testing host name vs IP.

Make sure you use the full hostname with the domain. Without that Windows will (probably) add it's own domain which may or may not be correct.

johnpoz

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

Adding secondary DNS (of the other interface) under each interface's DHCP Server may also be needed.

Why would you think you would need to do that.. What would be the point of handing your clients 2 different IPs on pfsense? If pointing them to stuff other than pfsense. How would they resolve your local resources?

If pointing to 1 local (pfsense) and 2nd other outside dns like googledns or something you have no idea which one it might ask.. Such a setup is always asking for having a bad day at some point.

I capture packets on the LAN interface I see LLMNR (Link-local Multicast Name Resolution) requests and NBNS (NetBIOS Name Service) requests for the host name

That would only ever be able to resolve hosts on the same network as the guy asking for it.. Those would not resolve some host on some other network.

skubany2

@johnpoz
"secondary DNS"
Under LAN DHCP Server I would have the LAN IP as primary DNS (default) and WiFi IP as secondary DNS.
Under WiFi DHCP Server I would have the WiFi IP as primary DNS (default) and LAN IP as secondary DNS.

stephenw10

Yeah, there's really no point in doing that. You are just accessing the same server via two addresses it's listening on.

skubany2

How the time flies.

To be able to use computer names, versus IPs, when trying to connect to network shares I have to solve the problem of LLMNR/NBNS packets being contained within the interface they originated from.

I have LAN and WIFI interfaces. When LAN client tries to browse shares on a WIFI client that can be achieved only via IPs at the moment.

I'll be reading about multicast to understand how it works in detail.

johnpoz

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

when trying to connect to network shares I have to solve the problem of LLMNR/NBNS

Why?? There is zero reason for those if you just setup dns to resolve your resources.

Here I resolve my nas, doesn't matter what network I am - be it my trusted wifi, my psk wifi, my lan, etc..

Dns resolves nas.home.arpa

$ ping nas

Pinging nas.home.arpa [192.168.9.10] with 32 bytes of data:
Reply from 192.168.9.10: bytes=32 time<1ms TTL=64
Reply from 192.168.9.10: bytes=32 time<1ms TTL=64

My machine uses a search suffix of home.arpa - so I can just use nas if I want.. But even if application or os or whatever I am using doesn't or can't use a search suffix just use the fqdn nas.home.arpa

Those discovery protocols are fine for grandma's network where she has the wifi router supplied by her isp, and its just 1 flat network.. But they don't work across networks - never meant to, nor does anyone need them that is going to go to the trouble of segmenting their network. Just use dns.

skubany2

@johnpoz

You are saying that I should go into my OS config and disable LLMNR/NBNS?

I have observed, via packet capture, that Win7 only utilizes LLMNR/NBNS it does not even attempt DNS.

On Win11 it does try DNS first, then mDNS and finally LLMNR/NBNS. The problem on Win11, I'm guessing, is that it appends .localdomain to the hostname I'm typing which gets a DNS response as not found. In a LLMNR/NBNS query Win11 does not append .local or .localdomain.
Can I prevent Win11 from appending .localdomain, if it matters?

johnpoz

@skubany2 yeah disable the shit of that.. Its noise on the network! ;)

Why and the hell would you be using windows 7??

As to .localdomain - Yeah set your domain. home.arpa is the approved for local use. Or use .internal - single label not a good idea imho.. use something.internal or home.arpa.

As to not even trying dns - did you set one? how do you think you could get to something on the internet without dns? Can you ping www.google.com - if so then its using dns.

also you should get out of the habit of just using a host name - use the fqdn..

skubany2

@johnpoz said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

Why and the hell would you be using windows 7??

You're very helpful and I appreciate that. But this comment is not helpful :) I only mention Win7 in case that helps in troubleshooting because OS type can make a difference. Why I use Win7 it's up to me, my preference.

As to .localdomain - Yeah set your domain. home.arpa is the approved for local use. Or use .internal - single label not a good idea imho.. use something.internal or home.arpa.

I would like to prevent Win11 from even appending ".localcomain". I'll search the net to see if I can do that. Even if I disable LLMNR/NBNS, Win11 will still try to resolve <hostname>.localdomain instead of just <hostname>. Based on my testing <hostname>.localdomain even over DNS will not resolve.

Here is the response to <hostname>.localdomain DNS request:
"Standard query response 0x69f9 No such name A <hostname>.localdomain SOA a.root-servers.net"
This may be an indication that I have something incorrectly configured in my pfSense. Again, <hostname> is on LAN interface, the request originates on WIFI interface. 'a.root-servers.net' is the request going out to internet? pfSense should be able to resolve it locally.

As to not even trying dns - did you set one? how do you think you could get to something on the internet without dns? Can you ping www.google.com - if so then its using dns.

"not even trying dns". This is not me, it is Win7. Why it does that, I don't know, I did not code it. Win11 tries DNS as I stated.

johnpoz

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

. This is not me, it is Win7.

I have not used windows 7 in what a decade or something - but it for sure uses dns, you couldn't get on the internet if it didn't. And it for sure supports search suffixes

Here is the response to <hostname>.localdomain DNS request:

Well yeah - not sure why you would expect the public internet to resolve a non valid public tld.

You can for sure use that locally if you want.. Here 5 seconds to create a record, and there you go it resolves

$ dig testlocaldns.localdomain

; <<>> DiG 9.16.50 <<>> testlocaldns.localdomain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18636
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;testlocaldns.localdomain.      IN      A

;; ANSWER SECTION:
testlocaldns.localdomain. 3589  IN      A       10.11.12.13

;; Query time: 3 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Fri Oct 31 07:25:44 Central Daylight Time 2025
;; MSG SIZE  rcvd: 69

Lets see the output of ipconfig /all on your machines - this will show where you point for dns, what its using for a seach suffix, etc.,.

example, my pc

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : i9-win
   Primary Dns Suffix  . . . . . . . : home.arpa
   Node Type . . . . . . . . . . . . : Broadcast
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : home.arpa

Ethernet adapter Local:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Killer E2600 Gigabit Ethernet Controller
   Physical Address. . . . . . . . . : B0-4F-13-0B-FD-16
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.9.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, October 30, 2025 7:36:16 AM
   Lease Expires . . . . . . . . . . : Friday, November 7, 2025 7:36:10 AM
   Default Gateway . . . . . . . . . : 192.168.9.253
   DHCP Server . . . . . . . . . . . : 192.168.9.253
   DNS Servers . . . . . . . . . . . : 192.168.3.10
   NetBIOS over Tcpip. . . . . . . . : Enabled

Another way to see where you are pointing for dns is just nslookup

C:\>nslookup
Default Server:  pi.hole
Address:  192.168.3.10

>

See how that matches up with my ipconfig output 192.168.3.10 is the name server my machine points too - in my case running a pi hole, which forwards to my pfsense for dns, and then my pfsense resolves external records.

My guess is you have your clients pointing to some external dns like google or something - and then no you would never be able to resolve your local resources.

Your clients should point to pfsense for dns, or another local name server you want to run.. This would resolve all your local resources either through dhcp registration of their names, or you manually creating the records, or reservation in dhcp that register the name in dns.

Gertjan

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

I have observed, via packet capture, that Win7 only utilizes LLMNR/NBNS it does not even attempt DNS.

Windows 7 uses the classic DNS : UDP (and TCP !) traffic with destination port 53.
Not the newer "DoH/DoT/DoQ " methods.
The IP used will be "the DNS IP the DHCP client obtained" and is normally the pfSense LAN IP.

So, I'm curious. If you can't capture any DNS from that W7 device, that's problematic.
Talk the owner and ask what he did to break DNS ^^

@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

problem of LLMNR/NBNS

I have to look that one up. I don't know what "LLMNR/NBNS" is. I doubt - but who am I - that that is a standard W7 thing.

johnpoz

@Gertjan said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

I have to look that one up. I don't know what "LLMNR/NBNS".

LLMNR - link local multicast name resolution. = NOISE ;)

NBNS - netbios.. Maybe you are too young to remember that, hehehe ;) Back in the days before dns.. You use to have to run wins to be able to resolve name that did not exist on your local network. Or to not fill your network with everything broadcasting for everything.. But wins went away when MS came out with active directory and switch to dns.. I mean it hung around for a long time.. But your talking what 25 some years ago when AD came out.

edit: netbios will still happen, if you have it enabled when you query something without being fqdn, or no answer.. So I just tried to ping something, you will notice it auto added my domain home.arpa to the query even though I just did a ping something. And it tried netbios when there was no response returned address. See how destination is 192.168.9.255 (directed broadcast)

then did a ping for my switch, with just its host name sg300-28, and again it did a fqdn query auto adding the domain home.arpa - notice since it got a response, no netbios broadcast went out. It just arp for the mac and then started the ping.

edit2:
Here just to be complete - this is where you would disable llmnr and netbios - notice now when I do a query for otherthing, it did just the dnsquery, but no netbios broadcast for the the name.

stephenw10

This should work fine if hosts are using pfSense for DHCP and the dhcp leases are set to register in the resolver.

Gertjan

@johnpoz said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':

NBNS - netbios.. Maybe you are too young to ...

Helas, that's not the case. I was there when Clippy was shot in the ally, when Byte Magazine featured the new '80836' ... - and I dare not to continue now
Netbios : yeah, that was a thing ... no : Microsoft wanted to be a thing.
Port 137 (138, 139 ?) ... thanks, now I recall. What a sh*t show.