@johnpoz said in About blocking DNS 53 on WAN interface: unless he was doing a floating rule on wan interface in the outbound direction, which is what I think he was doing. Exactly what I am doing. Everything out on WAN using dest port udp 53 is blocked.

At suggestion of Xfinity rep, I exchanged the DB7 modem/router for newer DB8. Now when I enable Bridge Mode all works fine. I pulled an IP address from a completely different block of IP addresses. Not sure how they go about assigning the IP addresses. Now the issue with DDNS running in non-Bridge Mode is a moot point. Thanks again for your assistance.

@baah If DNSSEC is activated, a helper app ( unbound-anchor ) is started to retrieve the DNSSEC root key file first. Try this for yourself : /usr/bin/su -m unbound -c '/usr/local/sbin/unbound-anchor -a /tmp/key -F -v' I've added the switches -F and -v for more verbose output. Take note : after running "unbound-anchor -h" : I presume that unbound-anchor does it's own resolving, using DNS root server hints (the IP addresses are hard coded in the executable so it can boot trap resolving itself as no DNS resolver is available yet on the system). It's a modern app : it will use IPv6 first, and fall back to IPv4 if that doesn't worked out. If you suspect IPv6 issues, add a "-4" here, right after the "-a", to force IPv4 usage. edit : Welcome to Netgate pfSense Plus 23.01-RELEASE... No core dumps found. ...ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/freeradius-3.0.25 /usr/local/lib/ipsec /usr/local/lib/mysql /usr/local/lib/perl5/5.32/mach/CORE 32-bit compatibility ldconfig path: done. >>> Removing vital flag from php81... done. External config loader 1.0 is now starting... nvd0p1 nvd0p2 nvd0p4 Launching the init system...Updating CPU Microcode... CPU: Intel(R) Atom(TM) CPU C3338R @ 1.80GHz (1800.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506f1 Family=0x6 Model=0x5f Stepping=1 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x4ff8ebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x101<LAHF,Prefetch> Structured Extended Features=0x2294e283<FSGSBASE,TSCADJ,SMEP,ERMS,NFPUSG,MPX,PQE,RDSEED,SMAP,CLFLUSHOPT,PROCTRACE,SHA> Structured Extended Features3=0xac000400<MD_CLEAR,IBPB,STIBP,ARCH_CAP,SSBD> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> IA32_ARCH_CAPS=0xc69<RDCL_NO,SKIP_L1DFL_VME,MDS_NO> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics Done. done. Initializing.................. done. Starting device manager (devd)...done. Loading configuration....done. Updating configuration...done. Checking config backups consistency.................................done. Setting up extended sysctls...done. Setting timezone...done. Configuring loopback interface...done. Starting syslog...done. Starting Secure Shell Services...done. Setting up interfaces microcode...done. Configuring loopback interface...done. Configuring WAN interface...done. Configuring LAN interface...done. Configuring IDRAC interface...done. Configuring PORTAL interface...done. Configuring CARP settings...done. Syncing OpenVPN settings...done. Configuring firewall......done. Starting PFLOG...done. Setting up gateway monitors...done. Setting up static routes...done. Setting up DNSs... <==== 3 seconds or so Starting DNS Resolver...done. Synchronizing user settings...done. Configuring CRON...done. Bootstrapping clock...done. <==== this took a couple of seconds Starting NTP Server...done. Starting webConfigurator...done. Starting DHCP service...done. Starting DHCPv6 service...done. Configuring firewall......done. Starting captive portal(CPZONE1)... done <==== this took 10 seconds or so, as several portal users were connected while I decide to restart .. Enabling voucher support... done <=== strange, voucher support is disabled Generating RRD graphs...done. Starting syslog...done. Configuring filter for dynamic IPsec VPN hosts... done Starting CRON... done. Starting package AWS VPC Wizard...done. Starting package IPsec Profile Wizard...done. Starting package Netgate Firmware Upgrade...done. Starting package acme...done. Starting package Cron...done. Starting package Notes...done. Starting package nut...done. Starting package System Patches...done. Starting package OpenVPN Client Export Utility...done. Starting package freeradius3...done. Starting package Shellcmd... done. Starting package Avahi...done. Starting package Filer...done. Starting package Backup...done. Starting package pfBlockerNG-devel...done. Starting package OpenVPN Client Import Utility...done. Starting package Service Watchdog...done. <==== WTF : forgot about this one, have to remove it asap. Starting /usr/local/etc/rc.d/munin-node.sh...done. Starting /usr/local/etc/rc.d/pfb_dnsbl.sh...done. Starting /usr/local/etc/rc.d/pfb_filter.sh...done. Starting /usr/local/etc/rc.d/shutdown.nut.sh...done. Netgate pfSense Plus 23.01-RELEASE amd64 Fri Feb 10 20:06:33 UTC 2023 Bootup complete The entire reroot sequence : from kernel loaded to boot menu shown : 30 seconds ? I've several pfSense packages, notably FreeRadius

Dear Gertjan, First of all: thank you very much for the time spent on your part, I highly appreciate that . I will reply below: @gertjan said in iPhone w/ manually configured IPv4 - not in DHCP leases list: The thing is : When you set manually the IP details like IP, gateway and DNS, you de activate the DHCP (client) process. The device needs IP info to use a network. It can use DHCP, and this is the default method. Or you do it manually. It one or the other. Quite right. UniFi works differently and does list devices with IP set manually-in-device. Like you said, I have now come to understand that pfSense only shows actual leases (i.e. issued by the pfSense DHCP Server service) on the "DHCP leases" page. Oh well. Furthermore, devices with manual IP configured-in-device actually do function properly and firewall rules with exceptions based on IP actually do work for these devices too, even though we can't see them in the leases list. But I like seeing them so I'm back to all DHCP now. Discover the magic : [image: 1684393496234-c41ca5ca-c22a-44ba-99ed-89e5955c7235-image.png] Yes I am familiar with this setting and I've used it successfully in the past for quite some time. Rogue IP lease monitoring At some point, couple of years ago, I went back to "Allow all clients" because I wanted to monitor the leases list to make sure there weren't any rogue IP clients popping up on the grid. So because all my devices have static mappings, basically all was well as long as no new leases in the DCHP pool would come up. But then Apple introduced Private WiFi - randomized MAC and of course new leases popped up for every iOS device, hence the attempt to revert to manual-in-device IP configuration (see above). It took a while for me to discover (my bad) that the Private WiFi option is selectable per WiFi network so initially I let it play. Soon after that, I figured out I can set their devices to Private WiFi OFF for the home WiFi SSID and ON for everywhere else. Great insight. So I set all family iOS devices to Private WiFi OFF and reworked the static mappings list. So far I have still kept DHCP settings at "Allow all clients" for this particular VLAN to be able to monitor new devices connecting. But there must be a smarter way to do this Of course I could re-enable "Allow known clients from only this interface" and rely on the firewall to let no other devices connect in the first place, which is what others on this page do. When they, kids etc, decide to delete the Wifi profile I suppose by deleting the WiFi profile you mean they tap the network and then tap "forget this network"? , and re connect from scratch, [...] So, no need to explain what so ever to the wife or kids : it's an auto learning process. Ah yes, now I know for sure that is what you meant - forget this network. They do something wrong, they assume the consequences. Okay, I am now very seriously considering to turn on "Allow clients from only this interface" again. But... @cabledude said in iPhone w/ manually configured IPv4 - not in DHCP leases list: Is there any way to receive alerts from pfSense in case someone tries to get in? There are many options. Use the LAN interface for yourself, and only accepts trusted devices on this network. Everybody else : on another (OPT1) interface, where you simply block all traffic that wants to go the the OPT1 IP (= pfSense): Block port 22, 80 an 443, and you'll be fine. I created separate VLANs, which may or may not be what you mean, but VLANs are effective. However my own "trusted" devices currently are in the same VLAN as the other family phones, pads, laptops. like you did, I may move my own to the LAN, thanks for the suggestion. Use a difficult password. Obviously got that, it's in my iCloud Keychain. See what System > Advanced >Admin Access => "Login Protection" can do for you. Added some fields there, thanks. So far I have used OpenVPN to access pfSense from outside the firewall and that is the most secure. I am now considering using Synology reverse proxy (with domain name and certificate) to allow for easy access to pfSense, outside and inside. But something is holding me back. HTTPS should be secure but attackers can get to the login screen easily. I disabled the admin account, but still... Please confirm that you right now.

@42sec This is what I use. https://github.com/markster17/unbound/tree/main

@johnpoz said in Unbound DNS resolver - high latency at resolution of local mappings: @carpet said in Unbound DNS resolver - high latency at resolution of local mappings: I do not understand why local DNS entries are checked against pfblocker blacklists with unbound You understand how it blocks is it creates local entries for say baddomain.tld points to 127.0.0.1 If you have 10,000 entries in your local db, then looking for fw01.localdomain takes a bit longer.. vs looking through 100 records.. I understand now. I expected unbound only checking blacklists as a second step (and not creating these entries at the same level)

@steveits thanks - that's interesting. I'm not forwarding to quad 9 but I'll check and see if disabling aslr makes a difference.

@t__2 For me it wasn't the upgrade so much as a clean install after the upgrade. Has been totally fine since the flash install.

@panjali-ganiyev hmmm, other than looking back through logs of dhcp I am not aware of a way to know that. static leases don't show up in the dhcpd.leases file If you handed off your logs to some syslog server it should be quite easy to look up some mac or IP for when the was the last time it got a lease.

@spacebass The only way I found to do it is to use samba's DHCP server (isc-dhcp-server) with the following script: https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records In pfsense, if you have other networks, you would need to enable DHCP relay option. Perhaps there is another way of doing it that I'm currently not aware of. You would use the samba's DNS server too. There is a very nice discussion about the DNS side of it here: https://forum.netgate.com/topic/176888/using-pfsense-as-firewall-and-windows-server-as-dhcp-and-dns-server-re-hash?_=1683907911478

@penguinpages said in DHCP - Long Lease Allocations: Kea https://redmine.pfsense.org/issues/5413#note-49

@jerryf72 Did you install the patches from the System Patches package and restart? There is one to disable unneeded 3am cron jobs that (per other long threads) filled up ZFS ARC memory. The cron jobs are disabled in 23.05.

@g0rck yeah how exactly are lan_guest and lan_home isolated.. You have 1 as a vlan? You have a vlan switch? You have them plugged into 2 different switches. Making to interfaces with different IP ranges and them into some dumb switch doesn't isolate the networks.

@cappie Thanks a lot. Think all should be ok now.

@mrpete the part further down: Disable Enable DNSSEC Support if enabled. DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures.