I think I got a new one "wack-o-mole" cf-images.us-east-1.prod.boltdns.net → Cloudflare + AWS region (us-east-1) + their Boltdns infrastructure. I have a wild ipv6 setup that is now caching ipv6 traffic and with my mime blocks I am seeing so many new ipv6 DoH servers its crazy fun but I am finding lots of new ones hidden in ipv6

@SteveITS said in Filterdns has stopped resolving hostnames in firewall aliases: https://forum.netgate.com/topic/185901/pfblockerng-not-blocking-some-foreign-sites-using-geoip/8 Was not aware. Thanks for the share. Tangentially related—but as does CIDR aggregation when using a combination of IP blacklists (i.e., 'action' Deny) and whitelists (i.e., 'action' Permit).

@jbariyo said in DHCP Lease Pool Exhausted and Disabled Leases not deleted: ... when you go to someone's pc it shows no dhcp server found Then you can "click on some buttons, and press some keys" and you have the answer you're looking for on your screen. Go to this "someone's pc", armed with your own device that has access to the pfSense GUI, and SSH. Open a SSH, option 8 - and (if you use ISC DHCP) : tail -f /var/log/dhcpd.log as this shows you the dhcp server activity in real time. On the "someone's pc" go command mode (cmd.exe) and execute : ipconfig /renew and look at what shows up in your SSH access, the 'tailed DHCP log'. You saw nothing ? Ok, the request never even reached pfSense (the pfSense DHCP server). So not a pfSense issue. (I suggest : VLAN problems) You saw : DHCPOFFERED (or something like that) : the lease was offered. The PC didn't receive it ? Not your problem ^^ A message that says : POOL full ? Make the pool bigger. Etc. Share what you've found. DHCPv4 lease duration : 2 hours or 120 minutes, for networks with not frequent or not permanent visitors is fine. These device will auto renew if they are still there. If the device is gone, the IP will be available after 2 hours max. A pool with "200" or so lPs will cover your "80" devices easily. Btw : If you use kea (you 'should'), the lease info isn't in the DHCP server log anymore. Bummer ... So, do this. read the entire thread [10 minutes]. Then copy paste this on the "Services > DHCP Server > Settings" page : { "loggers": [ { "name": "kea-dhcp4.leases", "output-options": [ { "output": "/var/log/kea-dhcpv4.log", "maxver": 8, "maxsize": 204800, "flush": true, "pattern": "%d{%j %H:%M:%S.%q} %c %m\n" } ], "severity": "INFO" } ] } This is what I use, and now I have a dedicated, auto pruned "DHCPv4 lease log file". Tail it with : tail -f /var/log/kea-dhcpv4.log

@Antibiotic Does Unbound support RPZ ?and the official nllabs = unbound author manual and documentation. I tend to say : yes.

@JKnott Of course it's not required. However, when you have lots of devices of the same brand/model, especially IOT, the name they show up as in both pfSense and Unifi by default is not distinctive. Sometimes even duplicate. I have over 40 TP-Link KP125 smartplugs that all showed up as "KP125", for instance. It is mpossible to tell which is which in the controller. The 218 Wiz light bulbs use wiz_last 6 of the MAC. So, I created DHCP reservations for each of them, and described them in pfSense. The tool ensures that the description matches. Otherwise, it is a manual process - you have to update it in 2 places. And if you forget, it is very confusing. Especially if you move and repurpose a devicex which happens a fair bit with the smartplugs. With 302 Wi-Fi clients, double manual edits did not cut it. Hence why I created the tool.

@Gertjan Thanks for the hint! I saw that I had TCode wrong, but even with the example, PCode still gets truncated: { "option-data": [ { "name": "time-offset", "data": "3600" }, { "name": "tcode", "data": "Europe/Zurich", "always-send": true }, { "code": 100, "data": "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00" } ] } This is what Wireshark sees: Option: (100) PCode Length: 8 TZ PCode: EST5EDT4 Option: (101) TCode Length: 13 TZ TCode: Europe/Zurich Option: (255) End

@johnpoz said in Custom options in unbound (dns resolver) cause syntax error: include wouldn't be part of it Oops. I corrected my post.

@pftdm007 not quite - if you are not in forwarder mode, unbound resolves what was asks from the roots down.. It doesn't send the query anywhere - it resolves vs forwards. And not so much pfsense passes it to unbound, unbound is listening on 53, and as long as your firewall rules allow it - unbound will get the query directly. When you resolve - you don't need anything in the general setup at all. If pfsense itself needs to resolve something it will ask itself (unbound) via the loopback address 127.0.0.1 the only time something like 8.8.8.8 would be used if you have it in general is if pfsense itself wanted to lookup something and unbound wasn't answering. Or you were in forwarding mode, be that either native (just 53) or in dot mode (853 with encryption of the connection via tls) Now that you know normal dns works - you could go back to forwarding if you want. I personally not fan, but sure if you want to forward forward.. Only thing I would suggest if you forward is uncheck to do dnssec. It can only be problematic if you forward - where you forward either does dnssec already or it doesn't, if it doesn't telling unbound to do dnssec is just going to cause extra queries, and could cause problems. Also forwarding to different services can be problematic as well - especially if they do filtering, and the filtering could be different. Since you don't really know which one will be forwarded to when you have more than 1 service.. You are not sure which filtering you would get.. Its best if you forward to pick 1.

@TonyB972-0 said in WAN seems to be getting next hop IP address, not public IP address: 192.83.xxx.1 address that was not. 192.83 is public IP. Your maybe thinking of 192.168 which is rfc1918 btw - not sure where your using some 208.93.xxx.xxx, because your not talking to pfsense with that IP, nor does your history ever show you connecting with an IP that starts with those 2 octets.

@ayansaari Check your ACL configuration to see what IP Ranges are allowed to use the resolver service [image: 1762934081170-8c991ce8-5581-4d2f-9fa3-a9b88e14c490-image.png]

@mcfly9 said in ipv6 compatible checkip service?: I traced the code further, then I found the problem: dyndnsCheckIP returns false if the gateway is marked as down. My gateways don't respond to pings, hence pfsense marked them as down. As soon as I disabled gateway monitoring, it all started working. @Gertjan, @WN1X, thanks for the help! Change your gateway monitoring to something further upstream that pfSense can ping. Problem solved!

@helviojr said in Can pfSense's DHCP server update Microsoft DNS?: I miss the custom DHCP options that would be very helpful. I could do it hard-coded in the config generation script, but I'm sure it will be available in GUI soon enough. Which DHCP option ? Read again the page where ISC announced they stopped the famous 'dhcp' project, and restarted form scratch, rebuilding the DHCP server again. On the non-official page you'll find the reason : over the years, options were added. thousands of them. Some were written, debugged, and stable since. Some were changing all the time. Hardware vendors didn't stop adding and modifying them .... It had became a software-maintenance hell. ( a bit like the openvpn project, or have a look at the absolute champion : postfix - or the black angel, freeradius : that one is just frighting). So, they created a framework and a manual, and left it up to 'us' the user (a very special user : it's us, the admin users, so we need to admin stuff ones in a while, and this includes type in stuff) to know what option data is needed, and place it in a nice JSON format (yet another text file format with a very precis syntax, probably more strict as XML), test it ... and forget it. Believe me : it isn't that hard .... A (pfSense) GUI facility for every option would be best, of course, but I don't think Netgate will fall in this rabbit hole. Writing a GUI (pfSense or not) that handles all the DHCP option ? (and does all the verification and checking of consistency etc ..) ... you might be waiting a long time. Right now, imho, the kea v4 and v6 pfSense implementation is rock solid. Some support for DNS registration, static leases and even HA is possible. The option I needed were - surprise - asked in pfSense redmine, and examples were proposed. From there on, as I sa working examples, I made some of my own. Anyway, I know, I'm rambling a bit. Just saying : you can do it ^^

Wow... ok figured it out. The links provided in @Gertjan post put me on the right path. It seemed strange that only Ubuntu Server hosts were affected so I started digging on that. Turns out that by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6) not by RDNSS. So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and just like that, by magic the hostname is properly registered in Unbound...

.... or zap the legacy 127.0.0.1 and embrase the future : ::1 ** ** some restrictions may apply.

Hi again, @Gertjan Quick update, looks like the following config will do what I want: 'loggers' => [ [ 'name' => 'kea-dhcp4', 'output_options' => [[ 'output' => 'syslog' ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ], [ 'name' => 'kea-dhcp4.leases', 'output_options' => [[ 'output' => '/var/log/kea-dhcp4.log', 'maxsize' => 512000, 'maxver' => 7 ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ] ], Thanks again for your help! :)

Looks like this works now with KEA in 25.07.1 .