@youcangetholdofjules Thank you very much for your reply. I managed to get the system stable again by following your suggestion.

The first time I tried it, only the DHCPv4 file got populated, so I tried again. The second time, I completely disabled all of the DHCPv4 and DHCPv6 settings. Then I rebooted the system and re-enabled them. After that, both files were populated.

Now, the GUI is stable and it seems that I can make changes to the reservations.

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

curious why it, ISC DHCP, has been deprecated from pfSense

Because it was deprecated by ISC

https://www.isc.org/blogs/isc-dhcp-eol/

Its been in pfsense release notes going back a few versions now. They even had a blog post about - couple I think.

Here is the first one.

https://www.netgate.com/blog/netgate-adds-kea-dhcp-to-pfsense-plus-software-version-23.09-1

Why the change is necessary

The Internet Systems Consortium (ISC) distributes two full-featured, open-source, standards-based DHCP servers: Kea DHCP and ISC DHCP. ISC announced the End of Life (EOL) of the ISC DHCP server, and ended maintenance on it at the end of 2022.

As to google AI - this is not complete info,

DHCP and UniFi Adoption:
UniFi access points use DHCP to obtain an IP address and discover the UniFi controller. They rely on DHCP option 43 to point them to the controller's IP address for adoption.

Yes it can use dhcp option - but only needs to do that for L3 adoption - not when they are on the same L2. The rely on dhcp option is a hallucination - it ONLY needs that if your device and controller on not on the same L2 network.

https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

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

Hello all,

Thanks for pursuing this for months and years. I am finally returning to pfSense+ after time away because of things like this being fixed!

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