@patient0 that was my exact issue

Okay, in playing around with this, I just learned the behavior which is new from the previous version of PFSense. If you have an alternate address entered for it's monitoring IP address (to ping instead of DHCP's default gateway on the WAN interface), PFSense then takes that as fact and that IP must not be valid or alive. This would be the case for disconnected WAN interfaces that have a public IP address set as their alternate IP address. When I removed that line or changed it to a different public IP address for monitoring, it "released" 1.1.1.1 and allows pings through. So this must be by design, but an interesting change from the previous version. There is a case where I have to use something other than the WAN interface's default gateway to determine if traffic should be routed to it in a WAN interface group I have, and this is where it was coming from. So please disregard, hopefully this info is helpful to others. Thanks

@Videonisse said in DHCPv6 Static Leases - how to assign a unique address per interface not per system: Has anyone tested this with KEA and the new pfSense CE v2.8.0? If support for IAID isn't in the GUI, is it possible to add it using json? The problem exists with 2.8.0 and KEA. I'd be happy to try a work-around using JSON, but I'm not sure of the syntax.

@lazaro said in Seeing Kea DHCP Issues after upgrade to 24.11: of /var/run/kea4-ctrl-socket That is where it is told to be / should be : [25.03-BETA][root@pfSense.bhf.tld]/root: ll /var/run/kea4-ctrl-socket srwxr-xr-x 1 root wheel 0 Jul 2 07:46 /var/run/kea4-ctrl-socket= This : 25.03-BETA][root@pfSense.bhf.tld]/root: grep -R 'kea4-ctrl-socket' /usr/local/etc/kea/* /usr/local/etc/kea/kea-ctrl-agent.conf: "socket-name": "/tmp/kea4-ctrl-socket" /usr/local/etc/kea/kea-ctrl-agent.conf.sample: "socket-name": "/tmp/kea4-ctrl-socket" /usr/local/etc/kea/kea-dhcp4.conf: "socket-name": "/var/run/kea4-ctrl-socket" /usr/local/etc/kea/kea-dhcp4.conf.sample: "socket-name": "/tmp/kea4-ctrl-socket" tells us that, for example, the "kea-ctrl-agent" process, that uses /usr/local/etc/kea/kea-ctrl-agent.conf as its config file, is told that the shared kea4-ctrl-socket is here : /tmp/ but ... the kea-ctrl-agent process isn't sued / started by pfSense. [25.03-BETA][root@pfSense.bhf.tld]/usr/local/etc/kea: service kea status DHCPv4 server: active DHCPv6 server: active DHCP DDNS: active Control Agent: inactive Kea DHCPv4 configuration file: /usr/local/etc/kea/kea-dhcp4.conf Kea DHCPv6 configuration file: /usr/local/etc/kea/kea-dhcp6.conf Kea DHCP DDNS configuration file: /usr/local/etc/kea/kea-dhcp-ddns.conf Kea Control Agent configuration file: /usr/local/etc/kea/kea-ctrl-agent.conf keactrl configuration file: /usr/local/etc/kea/keactrl.conf Note : I used the "DHCP DDNS" process also. That's of my own doing, and not yet implement in the offiacal pfSense.

@patient0 said in Unbound does not start: @1brad1 if I stop unbound with pfSsh.php playback svc stop unbound and start it with your command I don't get the umount: /var/unbound/dev: not a file system root directory. Did you upgrade from an earlier version or a clean installation? And are you using ZFS or UFS as filesystem? Anything in /var/log/resolver.log that stands out? I upgraded from 2.7.2 which was a fresh install with a restored config from 2.7.1 (to switch to ZFS, but also had an issue where I couldn't upgrade due to, I think it was, the EFI partition being too small). Looking through the log file I see no error messages of any kind.

@bmeeks said in Errors transferring zone between Windows Server and pfSense Plus: @aaronouthier said in Errors transferring zone between Windows Server and pfSense Plus: DNS resolution to local resources only works on non-windows devices, as they are using pfSense directly for DNS. Everything trying to use the 2 Windows Servers, including said servers themselves, are not resolving local records. This is because of the way you have chosen to configure your network with regards to DNS. If you refer to all local hosts on the Windows clients using their FQDN (hostname.domain), and set up your Windows AD to forward lookups for non-authoritative domains to pfSense, then it will work. But using simply hostname without a domain qualifier will not work because Windows AD DNS and the Windows clients will attempt to append the AD domain to the hostname and thus the lookup will fail as it won't be forwarded to pfSense and your other clients' DNS records do not exist in the Windows AD DNS server's database. I never use hostnames only for services, only FQDNs. this is true for both local and Internet services. Earlier, I added the domain override to point to my primary server, but still no dice. If you want your non-Windows hosts to be able to resolve Windows clients' IP addresses, then you must configure a domain override pointing to your Windows DNS server for the AD domain and open appropriate firewall rules allowing TCP/UDP traffic on port 53 (DNS). The only client machine that requires to access services on windows systems is my Windows 11 Laptop. The windows servers are just test machines. Their sole purpose is for learning. I'm beginning to suspect I have fouled something up by changing DNS settings so many times. I'm going to have my laptop leave the AD Domain, and then tear-down the Windows server VMs so I can rebuild them from scratch.

@DrSKiZZ I was able to fix it by wiping and re-installing PFsense strangely. I also might've turned off some of those remote management features in the BIOS during the wipe that was turned on before the wipe.

@nobugswanted Use pfBlocker Python Mode for DNSBL. We are aware of this issue and have a solution in the works for 2.8.1

@hydn said in New "settings" tab in 2.8.0: Enabling registration has any downsides? One .... it doesn't adhere to KIS concept. Best practice would dictate : If you don't need dhcp-into-dns registration, don't activate it. On the other side : help Netgate testing this new solution : one more user is one more occasion to find possible issues. Many user will thank you later. For other, we've been waiting for this thing to work for a decade or so.

Yup, and more improvements should possible with the new fast-reload capability.

@aGeekhere When I read several "unbound access-control-view" I'm pretty certain that "access-control-view:" needs to be placed in a server: block : server: access-control-view: 192.168.1.100/32 unrestricted_youtube access-control-view: 0.0.0.0/0 restricted_youtube .... What I'm not sure about : you use IPs fro youtube resources. This : local-data: "youtube.com A 216.239.38.119" might be true for one moment, and the next moment it's another IP, as Youtube uses many (like : a lot) of IPs so they can do load sharing, prtect against DOS, update/upgrade their servers in real time. And : protect themselves against people that try to limit the access to their services ^^

Sorry to invade the post in this way, but I would like to know if in version 2.8 it is already feasible to switch ISC for KEA, observing who uses 2 pfsense appliances in HA CARP?

@sunni Had the same issue with 2.8.0 I'm guessing since the Comcast-provided gateway IP is not pingable. Seems to be working fine again after disabling gateway monitoring as a workaround.

@4o4rh why doesn't it like match-clients server: Define views for each interface subnet module-config: "iterator" LAN clients view: name: "lan_view" match-clients: { 192.168.4.0/24 } local-zone: "net.lan" transparent local-data: "ipfw.eapenet.lan. 3600 IN A 192.168.4.5"

@mpossari said in Issues starting BIND (DNSSEC) after upgrading pfSense from version 2.7.2 to 2.8.0: The issue was that the outdated "auto-dnssec maintain" directive was being reinserted by pfSense. pfSense itself doesn't know what 'bind' is. pfSense doesn't come with bind. You probably installed the pfSense 'bind' package, and that one pulled in the latest original FreeBSD' bind, and the GUI part so it can work with pfSense. The issue is : bind - the FreeBSD package itself was updated, but not the pfSense GUI package part that creates the bind config files. The pfSense bind package maintainer should be informed.

@hydn Appreciate the heads-up. In general settings, I’m using Quad9 over DoT. The network uses the DNS Resolver with pfBlockerNG and DNSBL, listening on the network interface addresses. This all works fine. What I’m now trying to do is to isolate part of the network by using a VLAN and route all its traffic—including DNS—exclusively through the VPN. From a privacy perspective having VPN traffic and DNS within the VPN seems to be the safest approach. I’m fine giving up some control and filtering provided by pfBlockerNG and popular public DNS. I’m still not quite sure how to set this up properly. I tried configuring the VLAN’s DHCP server to hand out the VPN’s internal DNS IPs (10.2.1.1 and 10.2.2.1) for the 10.10.99.0/24 subnet. It looked like it was working earlier, but now DNS queries are timing out. I have disabled DNS Resolver on the vlan 99 interface. The 2 Gateway VPN IPs are used as dns servers on my host /etc/resolv.conf [image: 1749543360986-86bc21ae-69f8-41da-b82e-35ce06810538-image.png] [image: 1749542520957-7a22fe03-c791-4d75-8e5c-58fd80df1c49-image.png] nslookup timeout [image: 1749543276693-501415eb-3e40-4f1e-a0e2-d80f1b446853-image.png] Traffic going out from VLAN to VPN DNS [image: 1749543253891-59e063d0-febe-4c03-9e10-a8b6afb26eaf-image.png] traffic seems coming back from the VPN (this is correct as I have 1:1 NAT on 10.2.0.2 to 10.2.1.1) [image: 1749543558991-0b095dd3-f8e9-4b14-a431-1069c9cb85f6-image.png] I suppose on the VLAN I should see traffic response coming in from 10.2.1.1 but I do not and that is why I see "timed out". The nat seems to work I think. I am confused on why the DNS response is not properly routing back to the client my 1:1 NAT [image: 1749544902974-217c0de8-17cd-4d0c-81e1-0ef5ba5b32e2-image.png] my outbound [image: 1749544886917-48ab8aed-4cd5-4edb-82b2-78c13dece434-image.png]

More or less, SNAT I believe. Tailscale offers a mesh-based Wireguard tunnel to access (for example) devices on your LAN without the bother of doing any router-side config. The device you're using outside the LAN (my iPhone) connects directly to public sites without going through the tunnel, but since I'm advertising my own LAN-based DNS to the whole Tailnet (the mesh), and that DNS is not itself running Tailscale, connections to that DNS system are routed from another system that IS running Tailscale on the LAN. The system being used in this case is pfSense, as what Tailscale calls a subnet router, so its IP shows up as the source of the DNS query on the DNS (AGH) system. Turns out there's a way for Tailscale to preserve the original IP, so I'm going to try that out. And so... Guess what happens when you set AGH to drop connections from pfSense? :) Yeah, no DNS on your mobile - which I ran into today as I tried, and failed, to stream music after just starting my drive.

@ITSGS_ thanks for this, just checked the notes for CE 2.8.0 here: and it looks like they have moved from API to PAT in this release: Users of the Gandi Dynamic DNS service must change their current API token to a Personal Access Token (PAT) as Gandi now requires this authentication method for Dynamic DNS updates. For uninterrupted Dynamic DNS service, create a new PAT and save that PAT value in Gandi Dynamic DNS entries before upgrading to this release.