switch over from ISC DHCP to Kea DHCP

[RyanM]

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

[SteveITS]

@RyanM see the Kea notes in section:
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#general

[Patch]

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

[HuskerDu]

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.

[Gertjan]

@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 ' ?

[HuskerDu]

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

[Gertjan]

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

[HuskerDu]

@Gertjan Thanks, that was what I was looking for.

[RyanM]

@Gertjan Is this required if I have a Unifi controller? Or just for certain configurations w/ Unifi?

[KOM]

Hilarious that you have to hack up some JSON just to add common DHCP options. Truly, the future is here today!

[bmeeks]

@RyanM said in switch over from ISC DHCP to Kea DHCP:

@Gertjan Is this required if I have a Unifi controller? Or just for certain configurations w/ Unifi?

My understanding is "No", this DHCP option is not required. You can also simply put a DNS host override in DNS that points to the controller's IP. A user on the "other *Sense" forum posted with similar concerns about Kea on that platform and the lack of DHCP option 43. Turns out that Unifi devices will try several ways to find the controller, and a simple DNS lookup is one of them. Here is the relevant link: https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3.

And here is the DNS information:

You'll need to configure your DNS server to resolve unifi to your remote UniFi Network Application.

There are two methods of specifying the machine running the Network Application:

IP Address: http://ip-address:8080/inform
Fully Qualified Domain Name (FQDN): http://FQDN:8080/inform

[Finger79]

Just upgraded from 2.7.2 to 2.8.0. After the upgrade, switched the DHCP backend from the ISC DHCP to ISC Kea and also enabled both the "DNS Registration" and "Early DNS Registration" options. Finally!

The only thing missing is the ability to add Custom DHCP Options! With the legacy ISC DHCP web interface, we had:

Number:
Type:
Value:

That is no longer present in the WebUI. Looking through this thread, it seems the workaround is to figure out how to format all that in JSON?

[Gertjan]

@bmeeks said in switch over from ISC DHCP to Kea DHCP:

@Gertjan Is this required if I have a Unifi controller? Or just for certain configurations w/ Unifi?

My understanding is "No", this DHCP option is not required. You can also simply put a DNS host override in DNS that points to the controller's IP.

That's why I mentioned the first "easy solution" (see above) :

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.

(with images)

..... and done.
I've tested this : it works.

@KOM said in switch over from ISC DHCP to Kea DHCP:

Hilarious that you have to hack up some JSON ...

Hack ?
Remember the before pfBlockerng times ? When we wanted to use DNSBL files to be used by the resolver (unbound) ?
When you had to enter many lines of config for the Resolver here :

Some settings are global, per "server:", and some are per interface:, and so on.
It was easy to make a syntax error, or worse, the settings were accepted by unbound, and the final behavior was different as what was intended.
unbound has some option not covered in the GUI. About 90 or so. As you can see I use one of them, as I collect stats from unbound to see what it is doing.

DHCP (server) : there are .... dono, many DHCP options that exists. And all use another format, nothing is standardized. Close to impossible to have them all added to the GUI.
The JSON format helps the user to create something with some basic syntax error checking build in : JSON.

Btw : I do think that 'basic' options will be build into the GUI, but on the other hand, kea is there since .... 24.03 ? and initially, no options what so ever.
I needed some special DHCP options, as other early pfSense kea users - and I counted .... 3 ?!! See forum posts and redmine. And when I say 'I needed' it's actually for my hotel captive portal visitors, as all recent phones, PCs etc have RFC8910 build in, and people tend to connect to (free) "wifi" whenever they can.

Rfc8910 Captive portal support is why I needed a DHCP option, so at first I patched it in myself, but a Netgate author created a redmine and promptly wrote a JSON entry box and that worked right away :

The first block is for the portal login page URL, and the second for my portal APs, so they can find the controller (192.168.1.9).

Another advantage of using a controller - and announcing it's IPv4 it on your networks, is that when you add a new AP, you hook it up and done. Installation is done with the controller's GUI : you can "adopt" it, and then apply settings to it.

@RyanM said in switch over from ISC DHCP to Kea DHCP:

@Gertjan Is this required if I have a Unifi controller? Or just for certain configurations w/ Unifi?

Noop.
I think it isn't, but I never used my APs in "stand alone mode".
For Unifi camera, a controller is probably mandatory, but I never sued these, neither the other Unifi stuff (doorbells and so on).
I do use a Unifi POE switch, so my APs have no individual power bricks anymore. Power is no centralized, power back upped with an UPS. This switch is also managed by the controller.

Unifi APs have no GUI access, just a SSH access with very few options : nearly no bells and whistles. You can set the SSID, a password, channel used and add a controller manually, that's about it. The setup is done with a phone app nearby, using bluetooth.
As I'm using my 6 APs for a hotel, a captive portal, I went for the centralized setup, the controller. At first, I used the free (!) software solution as I have a (Windows) PC that is always turned on, but a NAS with a VM or docker (?) can also be used, or some Linux VM.
I didn't retain the Cloud based solution (with a monthly fee).
I finally when for the :

stand-alone 250 $ solution.
It has a build in 1 GB disk that I don't use - I guess it's for camera images/video's.
Now I have a nice GUI that controls all my AP's, nice charts and many buttons to click on

@Finger79 said in switch over from ISC DHCP to Kea DHCP:

The only thing missing is the ability to add Custom DHCP Options! With the legacy ISC DHCP web interface, we had:

Number:
Type:
Value:

Look at the image I showed above.
These are now called "name", "data","space" and there are many (!) more formats.
You have to use the { and }, and commas - these should be placed with space science precision (JSON !), you are not allowed to F-up.

@Finger79 said in switch over from ISC DHCP to Kea DHCP:

it seems the workaround is to figure out how to

Nah ... an admin has to do some work for a living ^^
Remember : why you buy (chose) that device that needs special, totally none standard settings, then, by your choice, you have to support it. pfSense can not be made aware of all existing possibilities out there. So : you'll be needing the device's docs, and you'll be good.
It won't take long time that device that need special DHCP lease options will have JSON examples as more then half of the planet will be using kea after all (it will eventually replace ISC).

There are of course good candidates for total pfSense GUI integration, like the RFC8910 portal support. All the info needed is available in pfSense, so it could be a "one check-box DHCP solution".
DHCP options are invented by the maker of a device that uses DHCP as a client.
The DHCP server has to make (offer) this DHCP option. So it needs to be very flexible, as everybody (device constructor) wants something else. There are no standards.
To enforce validity of these parameters, in stead of plain text, JSON is now needed (also plain text btw).
See it as a sophisticated classic linux (Windows INI ! or even config.sys or autoexec.bat file) config file, the ones we used for the last 50 years or so, and it evolved from these to somewhat better, that can be 'checked' as kea (pfSense) uses lint before it accepts your JSON entry

Now everybody can add whatever DHCP option he wants, if he is willing to look up how to do so. And as said, the alter is always

All of this is very 'imho' and 'afaik'.
pfSense is flexible, so I flex it.

[HuskerDu]

@Gertjan said in switch over from ISC DHCP to Kea DHCP:

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.

Doesn't seem to work with Flex Mini, only Option 43.

Neithertheless, many many thanks for your help (I'm still digging into static mapping, I think the ISC->KEA breaks it, lost some hours on it).

EDIT : 89% packet loss on some hots with static mapping....

[johnpoz]

@HuskerDu said in switch over from ISC DHCP to Kea DHCP:

EDIT : 89% packet loss on some hots with static mapping....

That has zero to do with how something got an IP - that is completely unrelated.. Doesn't matter if you set the IP static on the device, or via dhcp, or via a dhcp reservation. Has zero to do with if your using isc or kea or something else to hand out your IPs

[HuskerDu]

@johnpoz Agreed, except my unifi controller has a static mapping and I've spent ages to access it ;-)

Still got some strange behaviour with the host of the controller on the native interface (controller is on a VLAN) with 87 to 93% packet loss....

[johnpoz]

@HuskerDu and if your looking to dhcp or static IP your going down the wrong rabbit hole is what I am saying.. Are you pinging wireless or over wire? Look to either the device itself or the network to why your seeing packet loss.. It has zero to do with how some got its ip.

I would sniff on the destination device your pinging - do you see all the requests and it sending replies.. Sniff on your sender of the pings do you see it not getting replies that were sent via sniff you did on what you were pinging.

Is this traffic even routed through pfsense? Devices on the same network don't go through pfsense talking to other device on the same network, etc.

On the pings you do get answers for - what are the response times.. Something pinging something local should be 1ms over wire, and via wireless should be at worse a few ms..

[HuskerDu]

@johnpoz Let me dig more into it tomorrow.

PFsense

• LAN1
  --native
  --vlan1
• LAN 2
  --native
  --vlan2

From LAN1 native to LAN2 vlan2 : no issue, no packet loss
From LAN1 native to LAN2 native : 90ish% packet loss, traffic trigger rules on LAN2 vlan2.... which was not the case before.

[SteveITS]

@HuskerDu said in switch over from ISC DHCP to Kea DHCP:

From LAN1 native to LAN2 native : 90ish% packet loss, traffic trigger rules on LAN2 vlan2.... which was not the case before

? Packets starting on LAN1 should not be arriving on LAN2 VLAN2, sounds like something is cross connected. Rules apply as packets arrive on an interface.

[johnpoz]

Yeah how exactly do you have that connected together.. as @SteveITS points out, if you are pinging from some client on lan 1 native to a device on lan 2 native - you sure shouldn't be seeing any hits on some rule on lan 2 vlan..