@gabe-negate seen what you haven't provided any info - other than YOUR assessment of what you believe is going on.. AP can sometimes use their own mac vs the clients mac.. WIFI router to assign IP's in the same block as the external block, That will never work... So lets see pfsense arp cache.. What IP did it assign your client? Do an arp ping, ping it - does it show in the arp cache? Does the client see the mac of pfsense? What is in its arp cache? Are these correct - maybe you have a duplicate IP problem? Does anything in the arp cache show incomplete vs the mac assigned to the IP? arping is addon package you can add to pfsense. Will be under diagnostic menu, if you added it. but a ping to the IP, and then looking in the arp cache is another way... You could also just sniff on your interface while you ping and see if your getting back an arp, when a IP is not in the arp cache, then an arp has to go out for it to be able to send a ping or any other traffic. [image: 1709291889596-validate.jpg]

@viragomann That's due to me switching between DHCP and static to see if it made any difference. It's now set to static 192.168.2.50. Based on another forum post here and some on Reddit I suspect the problem is the new router (which is temporary, apparently) uses CG-NAT and it isn't configurable to that level unfortuantely. Thank you for replying, though

@SteveITS Thanks. After Kea integration is complete I hope Kea gets all features of isc-dhcp before that becomes the only option.

@SteveITS Oh My..... you just solved 20hrs plus of thinking trining and restoring withing 10 seconds. the domain override was exactly what i was looking for. Thank you so much for the help

@johnpoz said in Unbound keeps forgetting hostnames registered by DHCP on VLANs: @doejohn so with a 2 hour lease, every hour (50% mark) client will renew - this will cause an event.. If you have 1 client that is every hour unbound will be restarting. If you have 100, its a lot of restarts ;) That's right. But yet again: 2 hours is the default setting (I just double-checked). And I have a relatively small network, a total of only about 15 leases here. If such a small amount of hosts is causing problems with the default setting, then increasing the default should definitely be taken into account.

@Gareth-0 said in DNS Query from Some Workstations Not Resolving: From a specific Linux VM (172.17.20.250/24) it can ping the psfense device (172.17.20.1/24), but when I perform an nslookup I get the error: root@pve:~# nslookup ibm.com ;; communications error to 172.17.20.1#53: timed out ;; communications error to 172.17.20.1#53: timed out ;; communications error to 172.17.20.1#53: timed out ;; no servers could be reached 172.17.20.1 is your pfSense, right ? Check if the resolver is actually running;, this says something : [image: 1709103278441-917269d7-1b38-42e4-b4a5-9a6ebc41f308-image.png] This is better : [23.09.1-RELEASE][root@pfSense.bhf.tld]/root: ps ax | grep 'unbound' .... 60596 - Ss 0:10.50 /usr/local/sbin/unbound -c /var/unbound/unbound.conf .... and this checks what process is listing on port '53' : [23.09.1-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep ':53' unbound unbound 60596 5 udp4 *:53 *:* unbound unbound 60596 6 tcp4 *:53 *:* unbound unbound 60596 18 udp4 192.168.10.4:7656 150.171.16.34:53 avahi avahi-daem 70288 13 udp4 *:5353 *:* The first two lines tell me that unbound is listening on every interface, for IPv4 and IPv6, on port 53 using TCP and UDP. The LAN firewall rules have to permit UDP (and TCP !!) traffic to port 53. The default LAN firewall rule will do the job. [image: 1709103474408-55fa8ac7-460f-4b41-9edd-fac2d9d00915-image.png] If any of these conditions is false, no 'DNS' for you on LAN. @Gareth-0 said in DNS Query from Some Workstations Not Resolving: dig @1.1.1.1 ibm.com ;; communications error to 1.1.1.1#53: connection refused ;; communications error to 1.1.1.1#53: connection refused ;; communications error to 1.1.1.1#53: connection refused Which means : from your device, you cant' reach "1.1.1.1". Or no traffic to port '53' is allowed .....

@rjcab all the green arrow means is pfsense has seen that device in the last 20 minutes, its in its arp cache.. There was just another thread no that long ago going over this. pfsense gets that info if the device is online or not from the arp cache.. If its not in there then pfsense assumes its offline.. Any traffic 2 or from pfsense in last 20 minutes would mean the mac is in the arp cache... This times out after 20 minutes, and gets dropped off - so if pfsense has not seen any traffic for more than 20 minutes then yeah it would be to pfsense that its offline.. Does mean it actually is - just pfsense doesn't have it in its arp cache. https://forum.netgate.com/post/1151863

@d1novak said in Keep DNS Resolver running when interface goes down: I do run alot of dnsbl in pfblocker. Do the test : [image: 1708932837992-9c22a1a9-63f7-4f6e-8e2b-d4b0e75a2ae1-image.png] If the actual unbound stop and start takes more then 'several seconds', then you have a choice to make : Go for a big "Intel Iron", with loads of memory, SSD all over the place, Or Lower the number of total DNSBL entries. When the DNSBL files are refreshed/reloaded, they are all placed in one big file, sorted out, doubles removed, and formatted so the python module can actually use them. This is done using PHP web script language, not a great language to do huge file handling tasks. Throwing hundreds of thousands of DNSBL line at it, that's fine. But millions ? That a a no-go as it leaves your system for a very noticeable moment without DNS. Added to all this, the PHP process is memory upound. It can't all the system memory that is available, their is an 'upper floor'. Example : These : Take a second or two to get sorted, and unbound restarts in a second or so. I'm using a using a [image: 1708933425726-1941ca36-4eaf-407d-afc6-cf77d811c597-image.png] when I add more feeds, bringing the total of DNSBL entries over a couple of millions, my system becomes what I qualify unusable / not stable.

@Gwen29 I wrote a python script that reads an isc dhcp static map and moves it into the kea reservations. I create a merge.xml and it does not touch the original config file. Unfortunately this use case is for opnsense and not pfsense. U can look at my repo. https://github.com/patrick0525/Python-Opn-isc-kea

@patrick0525 yes. And you can always switch back if you find an issue with the Kea preview.

@viragomann Flashed my spare d-link dir-615 with openwrt and after watching a couple of videos I've managed to get it working. It's now running 4 vlans each with there own said and thus means each AP has its own rules making it much easier to split up my network. Thanks for the help.everyone

@rjcab well that refused when you did a dig screams acls.. Manually set it to allow your network to query.. I am not 100% sure if just creating one overrides auto, etc.. So you might want to disable the auto, and just create your own [image: 1708816160043-acl.jpg]

@mooncaptain said in after updating host override - resolver takes over 2 minutes to come back online.: I really loaded up pfb when I installed it. How big are the files? I’d guess you’re more CPU limited than disk limited. Run top while restarting unbound.

@johnpoz You're correct - I mis-spoke. Just finished setting up cloudflare - pretty easy to do. I had overlooked that they had a free offering for just DNS. Thanks for the feedback.

@maverickws said in Status / DHCP Leases: Wouldn't it make sense to add a default sort option here? Indeed it would. I suggest you submit this as a feature request or flag it as a possible bug. Ted

@johnpoz Currently I have it set up so every client gets filtered by pfblocker then uses CloudFlare DNS specified in general settings. What I am trying to accomplish is for this particular client to get filtered by pfblocker, then use a different DNS server than CloudFlare (say Google for testing purposes). I still want everyone else to use CloudFlare. If possible, I would also like this particular client to not use unbound to resolve any cashed DNS queries but still have pfblocker filter it.

@SteveITS Sadly same issue on the old backend as well.

@IzaacJ I am using cloudflare ddns - I just did a forced update of one of them, and don't see any issues. [image: 1708519054372-cloudflare.jpg]

^ exactly.. While I am a fan of longer lease times in my setup, why would you want more traffic for no reason.. I think I have my lease currently at 7 days.. Lets say you have 200 IPs to hand out.. How many clients do you have? If only a few it shouldn't ever be a problem, even if you had a 2 hour lease, and some box was off for 6 months.. Now if you have in total 210 clients, then yeah you can have problems if your leases are too long, or you could get clients switching Ips. Once a device gets a lease, it should maintain that IP going forward, since it will just renew it at the 50% mark of its lease.. And lets say you turn that off for long time, when it comes back that lease should still be there even if it expired and the client should get that same IP back, even if doesn't specifically ask for that IP in its request.. The only time you could see a problem is if you have a bunch of clients, more than your pool size and you have some lease that expired and some new client comes on and the dhcpd says oh shoot I don't have any free leases, let me start handing out expired leases.. Normally dhcpd will run through all its free leases before it starts to look into expired leases to re-issue. You should notice this as your IPs either count up from the low end of the lease 1, 2, 3 etc.. or it counts down 254, 253, 252 etc. One problem I can see with really long leases, is client normally not going to get any changes or new things you might of added to the dhcp scope.. Lets say you had a 30 day lease, and you say changed the dns server your clients should use.. Possible you have clients that don't get that new info for 15 days.. Also I am a fan of reservations - if I want to make sure client X always has 1.2.3.4, I just set a reservation for that client. Doesn't matter if he off 1 hour, or 30 days.. That client will always get 1.2.3.4 from the dhcpd.. And the dhcpd will not hand that IP out to anyone else..