@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 ?

@darkknight74 kea doesn't as of yet support reservations from my undering

I would suggest you move back til kea is at feature parity with isc..

@Prodigy if resolving is taking long time.. I would do a dig +trace to see where the slow down is happening.. Yes a full resolve can take a few ms.. But it it should maybe be in the hundreds of ms tops..

here is an example +trace

[24.03-RELEASE][admin@sg4860.home.arpa]/root: dig www.netgate.com +trace ; <<>> DiG 9.18.20 <<>> www.netgate.com +trace ;; global options: +cmd . 67159 IN NS g.root-servers.net. . 67159 IN NS l.root-servers.net. . 67159 IN NS c.root-servers.net. . 67159 IN NS b.root-servers.net. . 67159 IN NS h.root-servers.net. . 67159 IN NS f.root-servers.net. . 67159 IN NS m.root-servers.net. . 67159 IN NS i.root-servers.net. . 67159 IN NS a.root-servers.net. . 67159 IN NS k.root-servers.net. . 67159 IN NS d.root-servers.net. . 67159 IN NS e.root-servers.net. . 67159 IN NS j.root-servers.net. . 67159 IN RRSIG NS 8 0 518400 20240928170000 20240915160000 20038 . e9UFtVfZ3m82jc/rSzafGSvpiNHeDa89f5LwHY5zsSvXl+3OFAgU2ycR juXiRTrYAZnoZ4BSW+ZZT9XRdbCWd8LeF5k8PGxTqpSGFZ05o1nHXEau nXXPLuGH9J9/23PnQNtTLeY7RMRMYjwFrFFlzU3iOtDWVoNpGOgnX/vM Ts6J77CDlAs3DPQU57InshJDdKyncrGCN/Ai+mBCZ03vAKydm77Qrm1w bqH0R066b6Kdq0XjliXm97NGXl4rxzKLE7ij6xKWcH72o1QCD1xjJmT9 K6xghRrbHWhbx0aMlKQ/IhajwDEQY5nNMMOuApMHfNurfJyLQhGOI6yg mZeoVQ== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20240928170000 20240915160000 20038 . VzcC8YqsDVBbaB5yH5Nr7tbDT6Ds58tgoCf+DTyufirZiXE4LitOAaro /Jk/xB9Py6AV11gph0Hr4QeC1ctiv4mVed8zataERfObEh35kyho8abx WaRI42Dct0PUfpNYHmFV4jnBk5PdUFdD66G53g6nl5SGBOajchBqP1vW dMoMpUTHf19uzgfNXbYmC7mrv3v5yxjorYmGF8T2BJzSLoRfS2hRP33H h3DgtxQFI7AsTDqRAegMz5UMJMyOT926gBMdQxmxL71QbYhq0vsKCadb bC854E9E0832llvmLJgYEsJ1VmUWbogoopM0NxfKqXihFpvdsiMNARDM ygLS+Q== ;; Received 1206 bytes from 192.36.148.17#53(i.root-servers.net) in 122 ms netgate.com. 172800 IN NS ns1.netgate.com. netgate.com. 172800 IN NS ns2.netgate.com. netgate.com. 172800 IN NS ns3.netgate.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240921002601 20240913231601 59354 com. pSHnE+OIiU8H0lRp5YP2Yvl/ohLSLt6wQxqr6ON6NYv0lLb17kKVsIAS OwXmVwBs5XuFC1Z7X5vt64JsO4bk4A== 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 86400 IN NSEC3 1 1 0 - 2U54JL908MKCE6VDBRTOBQM3A838AA3F NS DS RRSIG 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 86400 IN RRSIG NSEC3 13 2 86400 20240922001625 20240914230625 59354 com. /vLmkD4Ydx0ML1Ztlo9UFDSeK20+E4Uhs5U1hoDvmkZdBMNTXefT1ivc 5S2O4HVcrfMErVTJVYRznxytz0TCaw== ;; Received 587 bytes from 192.26.92.30#53(c.gtld-servers.net) in 39 ms ;; Received 72 bytes from 34.197.184.5#53(ns3.netgate.com) in 30 ms [24.03-RELEASE][admin@sg4860.home.arpa]/root:

So you can add that up.. what 122, plus 39 plus 30 is 191 ms from cold start full resolve..

@newUser2pfSense as we said in your other duplicate thread ;) just because you create a dhcp reservation doesn't mean your client instantly renews its lease, etc.

@newUser2pfSense glad you got it sorted.

@NOCling I am using a static DNS server. Is the option you’re talking about something different?

@johnpoz Thank you for your help, I learned alot! Take are.

@Gertjan said in GoDaddy DDNS error:

@bmeeks
Thanks for the reminder ... I knew there was a issue somewhere.
This explains the :

@ascabral said in GoDaddy DDNS error:

(Error) Authenticated user is not allowed access.

as the service was ditched a couple of months ago.

But this has nothing to do with the "DDNS supplier" :

@ascabral said in GoDaddy DDNS error:

Public IP address could not be extracted from Check IP Service

as this is a test been done locally by pfSense and can only fail, imho, if local DNS has been messed up.

I have seen the "could not be extracted" error in my own setup from time to time. It seems to happen during a restart of the interface (as in when my ISP has a short outage for some reason). I suspect, but without any proof or deep knowledge, that the DDNS client might be trying to grab the WAN external IP before the interface restart is fully complete.

@maurofbmarques said in Negar acesso para IPs fora da reserva no DHCP:

Valeu, encontrei...

ARP Table Static Entry
Create an ARP Table Static Entry for this MAC & IP Address pair.

Obrigado

é na tela principal mesmo, não seria aí

43c628a4-179c-4f18-8b6f-e9115b410196-image.png

@jlw52761 said in Unbound with DHCP Registration Very Slow:

Sorry, but this is supposed to be an Enterprise grade product, this type of bug is not acceptable in a feature that's been core to the product for a number of years.

Interesting.
pfSense is a (nearly native) FreeBSD kernel and uses pf which is part of the the kernel.
Both are open source.
The whole is enveloped with a nice GUI, and add to to that, a lot of network related features are added.
A pretty complicated things became easy to handle on first sight. But it's still a 'Enterprise grade product' needing 'Enterprise grade product' knowledge 😊

@jlw52761 said in Unbound with DHCP Registration Very Slow:

So if I have to do static leases, what the hell's the point of DHCP in the first place?

You misunderstood static leases : all network clients still use the default dhcp client. The DHCP server is still needed.
Only the admin decides now what IP every device gets.
@home this isn't' really needed, but for an company or enterprise, this is a must have, as I'm not going to run around on every floor to set a static IP for every new device that comes in.
For info : I'm using pfSense since day one, and actually rarely handle DHCP stuff.
I do have a 'map' in pfSense - nice centralized in one place - where every device has its IP and host name that I choose, like Android-William, instead of seeing this :

edit : wait ... 'a couple of thousands of workstations' .. you already know all this.

6337b4e1-08c5-4e4f-9ecb-4fda30420780-image.png

@jlw52761 said in Unbound with DHCP Registration Very Slow:

I am very disappointed in this product at this point.

Just wait a couple of .. what .. weeks, and this situation will be something of the past.
You'll get over it, as the other million or so users ^^

@jlw52761 said in Unbound with DHCP Registration Very Slow:

Since I have a lot of DHCP clients and would like to use .... ..... more stable like Bind.

bind9 is the full solution and can do more as unbound. It is available as a pfSense package.
pfSense needed a resolver, was using a forwarder (its still there, in case of), and unbound was chosen.
unbound is stable, though. Its just the "DHCP lease to DNS" integration that was somewhat quirky.
As said, that will be addressed very soon.

Btw : I'm using bind myself for the classic "domain name" services on a Debian server. Using the good old config files method, as interfacing bind with a GUI is just IMHO, plain impossible.

@jlw52761 said in Unbound with DHCP Registration Very Slow:

I have the default of 7200 for the lease time

Another factor : Wifi devices that go off range, come into range, etc every time they come back, a DHCP request is fired ...
If you have 'thousands' of devices that your DHCP server, on all of its interfaces, will see many request per minute.
The "DHCP Registration" isn't an option for you, that's for sure.
With that number of devices, I probably would use the firewall as the firewall, and use a dedicated DHCP server for my internal needs. And even outsource locally DNS also.

@jlw52761 said in Unbound with DHCP Registration Very Slow:

Also, still can't find in the logs that Unbound is restarting, so curious on that and how long it's taking to restart

Look in the unbound (Resolver) logs ?

5d8e761d-04c1-4371-b501-acf760728a0a-image.png

ec2edb72-92cd-413d-983f-243903fb33b6-image.png

2,5 seconds.

I'm using pfBlockerng with a couple of hundreds of thousands DNSBL ...

edit :
Posted a couple of hours ago :
https://forum.netgate.com/topic/189752/is-24-08-on-track/28?_=1726035419944

Read the bug report ... its .. yeah, you have (and get the) point.

@bschapendonk I'll check this out when Windows 11 24H2 will be deployed to our devices through the General Availability Channel.

@elvisimprsntr said in How to enforce encryption of outbound DNS queries:

Seems like this thread has gotten off topic. Started with how to make sure all outbound DNS queries are encrypted, which I think we provided a solution.

I've implemented the provided suggestion. Even I didn't run extensive tests and long-period packet captures in order to ensure that there's absolutely no unencrypted outbound DNS traffic, I highly suspect that it works. It's okay for now. The internal DNS traffic between the cleints and the pfSense is unencrypted because I didn't manage to configure the clients to use pfSense's capability to process encrypted inbound DNS queries.

@elvisimprsntr said in How to enforce encryption of outbound DNS queries:

Client isolation is a completely different subject altogether. Suggest OP open a new thread.

Yes. I will try to get into client isolation and roll it out at a rainy afternoon. I guess it will be a challenge because I will have to avoid side effects (some clients have to be able to communicate with each other, in example a computer which has to transfer a print order to the printer or a file to the NAS).

@Modesty said in I dont get an active IP on WAN side interface:

I found the missing link

igb1 did not work, maybe due to lightning (happened with my previous pfSense box also).

I changed WAN to igb3, viola, all good.

Back up in your very first post with the screen capture -- the big red circle containing the white 'X' means "physical link failure". That indicates hardware or cable issues with the NIC port. Nothing else will work until a physical link is established.

@christophdb said in [SOLVED] No DNS Resolution for vlan:

I had a allow any rule, but this rule was only for "tcp" Requests - and DNS requests are "udp".

You're still not there.
Handling TCP and UDP is ok, but there are more - like 50 or so ? - protocols.
The next best that you probably shouldn't block is ICMP. Better get used to include this one, because the day you'll adopts IPv6, ICMP becomes pretty mandatory.

True : the other 47 are less known, less used.
But beware of the pitfall : in the future you install that new great app that does super things ..... and omg it doesn't work with pfSense ! .... because you took wrong decisions when "setting up your own firewall rules".

I've solved the issue for myself with these selected two rules :

6c50ce64-4242-4d5c-8ec5-905d224a3483-image.png

and I found out later that these two rules are the ones present on the LAN interface when you install pfSense from scratch.

@M0L50N
I would run a DNS Resolver at B and add domain overrides to it for local domains provided by the DNS server at A.