KEA is the fix for the twilighted DHCP server, that DHCP software the developers no longer release updates for. pfSense/Netgate had to redesign a lot of code just to get KEA to work, again with anything new there is a timeline for software convergence that is expected. That is why it was a depreciation notice and not automatically merged to KEA. Thanks for sharing your experience with the community. Sorry you had that experience. Again with the Boot Environment features mitigation for such issues is a breeze to jump back to a known good configuration. I love Boot Environments.

@netblues Thanks for the info. I reconnect the cable to the port and it seems that it can now get the IP address. No change in the configuration.

@Gertjan I checked my DNS forwarder settings, made a slight change (turned off reverse DNS for local servers) and it worked. Thanks.

I totally agree on the meaningful error messages. I also wonder if there shouldn't be a mechanism to restart a critical service intelligently (since as I learned above, watchdog is not intelligent enough). Another thing you might want to try @Mission-Ghost is to update pfBlockerNG. I learned that packages do not auto-update. When looking at the package list (now a widget on my dashboard) it allowed to start an update.

@patient0 Thanks for your replies! I know we can change the MAC in the VM configuration, but I wanted to get a new interface going to ensure nothing cached would impact the outcome.

@RJ said in Upgrade to 24.03 - DNS Settings: @jimp Thanks for confirming the nameserver ::1 entry in /etc/resolv.conf is there for IPv6. This has not caused any problems for me. However, I think it causes DNS Lookups from within the pfsense GUI to briefly hang as it waits for a timeout from the query to ::1 Look at this one: https://forum.netgate.com/topic/189394/local-loopback-ipv6-dns-timeouts-no-response-24-03

Reporting back. Creating a "quick" floating firewall allowing outbound access from my Nord interfaces to my System DNS servers seems to have gotten rid of these blocked inbound connections. It's not clear to me why, but maybe it will be to someone else . . . [image: 1728073502330-b2c8bc7a-9afb-4133-9bd9-ce88b385bb9a-image.png]

@GeorgeCZ58 A rapid Google search gave me this : https://community.ipfire.org/t/any-way-to-block-all-dns-queries-and-whitelist-some/10544 Btw : and because 'respip' was unknown to me, I found this. So it exists, Not sure if pfSense has this software component. It is a module created by NLnetLabs (unbound author). So, easy plan A : PI-Hole ?

@b0sman can you query anything from your vpn client to your 10.0.0.11? say pfsense own name? When you add a vpn tunnel network.. I don't believe that adding a vpn tunnel network adds that to the unbound default ACLs Also if you setup some domain override to go lookup this pc01.mydomain.local, that would be rebind if the answer is a rfc1918 IP. Also .local is not a good choice for local tld, since .local is used by mdns.. I would suggest moving to better choice, either use home.arpa locally, or the new one is .internal

@johnpoz Thank You, I never knew that.

@Gertjan Ended up needing to fully set a static IP on the NAS to get it to work. Tried it on a managed switch before doing that and that didn't work either. In any case, seems to be working properly now. Thanks again.

@Tactis where in zero trust does it say a client can't even lookup a name? Access control yup, monitor sure, but just because a client can lookup that host.domain.tld is at 192.168.14.12 doesn't mean it can access it. You can do with views what your asking, or simpler solution would just be run a different NS for this other network - that would be far better then putting rfc1918 in a public NS. You could prob do it with Response Policy Zones, as well.. Putting your resources into the public, now allows anyone to lookup those records.

...Aaaand sorry @ all. Seems I am getting old. I asked about that a while ago, got an answer...but seems I are senile. So, carry on, nothing to see here... :) here's my first attempt: https://forum.netgate.com/topic/172512/wan-interface-as-dhcp-client-error/5?_=1726758878697

Edit: Just heard back from VSSL. known issue with Google Home/Speaker Groups. Sorry about that! @johnpoz @Gertjan @SteveITS @bmeeks Hey all! sorry to necromance an old thread but I ran into a possibly related issue and just wanted to see if anyone that was up to speed had any thoughts. I've noticed that my VSSL (zoned audio like sonos) speakers show as offline in the Google Home app. But i'm able to stream spotify to the individual zones no problem. I see all the zones/speakers in the proprietary VSSL App and there are no errors on the physical VSSL units. When I pull up the Spotify "select your device" menu to choose speakers, I see all the zones AND the Speaker Groups (multiple zones, that I define in the Google Home), BUT if I select a Speaker Group it spins forever saying it's connecting and never does. Each zone has a static IP on the IoT VLAN and playing to Speaker Groups def worked before the do-ip6:no option was added. Does anyone know if Google Speaker Groups use ip6? Any ideas how to fix this? Full disclosure: It's obviously been a while since I used the zoned audio, so it's possible something else is causing the issue but I'm somewhat convinced that VSSL is related to the DNS_PROBE_FINISHED_NXDOMAIN exceeded maximum number of sends error. It's a wild hunch, but I was having an issue much earlier where turning on the VSSL's would boot a bunch of devices off the DHCP server (still operating but no way to access them over IP). It was actually one of the motivations for segmenting the networks in the first place. Seems like too many coincidences.....

@Gertjan Not correct as in serve-expired is not irrelevant. Your case might work ok for you, as it depends on how many clients you have and what domains they are requesting. But if a domain is not requested within 10% of the TTL then it will not be prefetched. If you don't believe me you can check the code, or ask the dev https://github.com/search?q=repo%3ANLnetLabs%2Funbound%20prefetch&type=code So a scenario where a record is fetched, not reused within it's TTL, and then expired - (thereby removed from the cache) is required to be fetched again even with prefetch enabled. Say you are only using prefetch....with 5 min TTLs or less (or even 30 min TTLs) or less being the norm today, you can have scenarios where peak periods of your network are serviced well by the cache. But if there is another peak period later in the day, the cache has to get almost rebuilt. With serve-expired you can keep these records in the cache from one peak period to the next. Then use serve-expired-ttl to optimise how long the records are kept. For me 1 day is good so that the peak periods throughout the day are served with an already healthy cache before the device requests it. Hope that makes sense.

@girkers Go here : Status > System Logs > DHCP (logs contain always the answer ^^ ) and hit Ctrl-F (search) and look for the "bd:db" (without the " ). If you don't find any occurrences of "bd:db" you have proof that the pfSense DHCP server didn't handle the DHCP transaction. As it never received the request. That means some other DHCP server on the LAN work exists. Like an wifi access point that is also a router with DHCP capabilities. Btw : you screen shot of the phone's address details doesn't say me that it's in 'automatic' mode (== DHCP). So, for me, these settings could be static == set by you, manually. That would also explain a lot, if not everything. Hummm ... https://forum.netgate.com/topic/190153/change-mac-address-on-static-ip-now-can-t-get-dhcp/9 => you use kea or isc ?