switch over from ISC DHCP to Kea DHCP
-
@johnpoz said in switch over from ISC DHCP to Kea DHCP:
Kea has support for this feature and others.. it has just not been integrated into pfsense as of yet.
The "current:" message
ISC DHCP has reached end-of-life and will be removed in a future version of Netgate pfSense Plus. Visit System > Advanced > Networking to switch DHCP backend.
does not make it "explicit:" that pfsense kia has lmited functionality.
Pfsenes must change the above message to something meaningful to say something to the effect "pfsense kea is in experimental stage and fully not implemented " - You need to look at the GUI and messages with a GENERAL USER hat not a NETWORK USER imho
-
@netboy dude pretty sure everyone agrees the wording could of been done a bit better.. Move on already.. This horse was dead long time ago - its time to stop kicking it.
-
@Gertjan -- Just commenting on your post relative to my questions on what changes -- Not asking for help just commenting relative to what you said.
Lease statistics/graphs I refer to these from time to time.
"Note: If you have assigned hostnames to devices on your network using static leases, or rely on dynamic lease registration in DNS, switching to Kea DHCP results in those hostnames being ignored. The static lease configuration is kept, so switching back to ISC DHCP will restore the functionality."
Since I do have assigned hostnames with static leases, such as our file server, our HP printer/scanner, etc. [These devices are expected to be at the IP address manually assigned (from prior LAN software I used prior to PFSense going back to NT 4.0 days)].
As a result, I am interested in what is happening with Kea DHCP and when it will support prior functions I use or provides an equivalent that we can migrate to "automatically" if possible. I've tried to avoid becoming a network person. Unfortunately, the Peter Principle is prevailing despite all attemps to avoid it.
-
I came across this topic when seeing the notice on my pfsense instance. Rather than create a new topic, I figure I continue the discussion to see if things have changed.
I've been using pfsense for several years now and I typically do not change any settings unless necessary.
If I change from ISC DHCP to Kea DHCP, is there any that needs to be done beforehand besides making a backup?
Are there any other settings to change besides clicking the KEA DHCP radio button and clicking Save?
If I choose to keep using ISC DHCP, is there any harm in doing so? (security issues?) -
@pulsartiger I wouldn't switch to kea yet.. Just turn off the warning if it bugs you. Kea is not at feature parity yet.. And no there are no real security issues with just continuing to use ISC..
-
@pulsartiger re: updates:
https://www.netgate.com/blog/improvements-to-kea-dhcp -
@SteveITS said in switch over from ISC DHCP to Kea DHCP:
@pulsartiger re: updates:
https://www.netgate.com/blog/improvements-to-kea-dhcpYep. That info is still hiding in plain site.
( Just an idea : put the RSS at the top, and you stat auto-informed )
-
After I tried to switch to KEA, no ip address for my pc over LAN and WLAN.
For some reason my laptop still worked, so I could take a look into my pfsense.
No leases shown under "status - DHCP leases".
After switching back to ISC everything works fine again.
DO NOT USE KEA! -
@kuchenmann I have been using Kea since it was added to pfSense 24.03 without any issues at all on my 4200. YMMV.
-
problem is, that if ISC is configured with NTP-servers using names,
KEA fails to start, because it only accepts IP-addresses as NTP-servers.
WTF?
Never heard about pool.ntp.org? -
@kuchenmann dhcp has never accepted fqdn for ntp.. Before pfsense would resolve that to put the IP into the dhcp server.
Pretty sure that is one of the things added in the 24.11 release.
-
@kuchenmann The NTP servers provided via DHCP option 42 must be IP addresses, per RFC2132.
-
@kuchenmann Why don't you set pfSense to use pool.ntp.org and set DHCP to provide the IP address of your LAN as the NTP server?
-
I know this is an old topic, but seems to be the most relevant. I use static DHCP leases and that they are registered in DNS (unbound). I know the original blog stated this was a known limitation, however, this blog post (https://www.netgate.com/blog/improvements-to-kea-dhcp) seems to indicate this may be present in 24.08?
Any idea when this will become available in CE? I am on CE 2.7.2, which has a build date of 2023. I see there is an RC for 2.8.0. Maybe I will look around at how stable that is and consider upgrading...
-
@RyanM see the Kea notes in section:
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#general -
@RyanM said in switch over from ISC DHCP to Kea DHCP:
I use static DHCP leases and that they are registered in DNS (unbound). ... Any idea when this will become available in CE?
That's a good question. Or better again "Has pfsense Kea DHCP implementation reached feature parity with pfsense ISC DHCP implementation"?
The reason this is a good question is Netgate messaging on the subject has been atrocious in the past. Made worse as somehow they tried to argue miss leading messaging was OK because if you knew it was miss leading you could go to another source, read it carefully and excused them as they left a caveat there.
My reading of the release notes https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#general suggests Netgate's pfsense Kea implementation has improved but I'm not sure if it has reached feature parity yet.
The warning
ISC DHCP has reached end-of-life and will be removed in a future version of pfSense.
Is relevant to Netgate internal Kea development prioritization but blatantly inappropriate IMO in an inbuilt pfsence warning without their Kea implementation reaching feature parity or at least including a link to a comparison table in the warning.
Hopefully they have reached feature parity now so this concern is no longer relevant.
-
I've just upgraded from 2.7.2 to 2.8.0.
So far it has run smoothly, so that I've decided to give KEA a try. At first glance, it is fine, except from the DHCP option point of view.
I would imagine I'll have to dig in the JSON part to complete that point.
-
@HuskerDu said in switch over from ISC DHCP to Kea DHCP:
give KEA a try. At first glance, it is fine, except from the DHCP option point of view.
'kea' = (a) DHCP (server).
Can you detail your 'except ' ? -
@Gertjan said in [switch over from ISC DHCP to Kea DHCP]
Can you detail your 'except ' ?
I am pointing my Unifi devices towards their controller through DHCP Option 43. With KEA, it is no longer directly possible via the GUI, I'm assuming I would have to add it with JSON.
-
@HuskerDu said in switch over from ISC DHCP to Kea DHCP:
I am pointing my Unifi devices towards their controller through DHCP Option 43. With KEA, it is no longer directly possible via the GUI, I'm assuming I would have to add it with JSON.
Oh ... but I can help you with that.
I've a Cloud Gen 2 Plus whatever device, and a load of Unifi APs.Easy solution - the one that works without the help of DHCP :
As per Unifi documentation :
Create a host override (bottom part of General config of the resolver) called 'unifi' and let it point to IPv4 of your controller.I called it "a_unifi" so it gets sorted on top.
You should "unifi" of course.Btw :
as "bhf.tld" is the domain of my pfSense.
as Unifi devices, if they didn't get the controller info with option 43 in the lease from a DHCP server, they will do a DNS request for "unifi" and use that IPv4 as the controller IPv4.
Using Kea and options :
It is possible - and I'm using that right now :On the kea DHCP server settings page :
put this in place :
{ "option-def": [ { "name": "unifi", "code": 1, "space": "vendor-encapsulated-options-space", "type": "string" } ] }
and on every LAN where you have unfi stuff, (APs cameras etc), put this :
{ "option-data": [ { "name": "vendor-encapsulated-options" }, { "name": "unifi", "space": "vendor-encapsulated-options-space", "csv-format": false, "data": "C0A80109" } ] }
Btw "C0A80109" = 192.168.1.9 because my controller uses 192.168.1.9 - adapt yours for your controller IPv4.
See also : [Adding Custom Configuration in Kea DHCP Server with pfSense+ 25.03](Adding Custom Configuration in Kea DHCP Server with pfSense+ 25.03)
More info : Kea DHCP Custom Configuration Support (IPv4 and IPv6)
Let's test :
Packet Capture :
On a LAN, using UDP, port 67 and 68, with juicy details - and Start.
Using my Unifi, I restart a AP.
After a moment : the DHCP lease request :16:40:51.945823 0c:ea:14:44:4a:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 0c:ea:14:44:4a:38, length 300, xid 0x76ea1f4d, secs 51401, Flags [none] (0x0000) Client-Ethernet-Address 0c:ea:14:44:4a:38 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover Client-ID (61), length 7: ether 0c:ea:14:44:4a:38 MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Vendor-Option (43) Vendor-Class (60), length 4: "ubnt" Hostname (12), length 11: "U6ProBureau"
You see the option 43 request ?
The kea dhcp server answer :
16:40:51.948326 90:ec:77:29:39:2c > 0c:ea:14:44:4a:38, ethertype IPv4 (0x0800), length 362: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 348) 192.168.1.1.67 > 192.168.1.253.68: [udp sum ok] BOOTP/DHCP, Reply, length 320, xid 0x76ea1f4d, Flags [none] (0x0000) Your-IP 192.168.1.253 Client-Ethernet-Address 0c:ea:14:44:4a:38 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.1.1 Domain-Name-Server (6), length 4: 192.168.1.1 Hostname (12), length 8: "ub6prob2" Domain-Name (15), length 20: "bhf.tld" NTP (42), length 4: 192.168.1.1 Vendor-Option (43), length 6: 1.4.192.168.1.9 Lease-Time (51), length 4: 21600 Server-ID (54), length 4: 192.168.1.1
and the AP got the controller IPv4 :
Vendor-Option (43), length 6: 1.4.192.168.1.9
so "192.168.1.9"