switch over from ISC DHCP to Kea DHCP

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

[HuskerDu]

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

sounds like something is cross connected. Rules apply as packets arrive on an interface.

Cannot be the case, LAN1 is Switch 1, LAN2 is Switch 2, no cable between them.

[HuskerDu]

Thanks again for your help and patience.

End of the story, linked to DHCP but not only, the LAN 2 VLAN interface was assigned with the IP address of my ngnix proxy (which was not the case previously), that created a lot of mess !!!

Once found, no more issues !

[Unaired6288]

I am trying to tftp boot and my static mapped clients do not get the option 66 reply.
When I set the server IP in the pfSense UI the option 66 is set in the pool section of the config

        "subnet4": [
            {
                "id": 1,
                "subnet": "10.27.1.0/24",
                "option-data": [
                    {
                        "name": "domain-name-servers",
                        "data": "10.27.1.254"
                    },
                    {
                        "name": "routers",
                        "data": "10.27.1.254"
                    }
                ],
                "pools": [
                    {
                        "pool": "10.27.1.100 - 10.27.1.150",
                        "client-class": "pool_lan_0",
                        "option-data": [
                            {
                                "name": "tftp-server-name",
                                "code": 66,
                                "data": "10.27.1.33"

With this config the statically mapped clients do not boot and I only receive Option 67 in the DHCP packet.
With a dynamic ip client the option 66 is included.

Adding the option-data Option 66 to the custom configuration or to the config file directly in the subnet section make the DHCP server include the option 66 in the packets.
Am I missing something, is it by design or is it a bug?

[Gertjan]

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

tftp-server-name

https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html - look for tftp-server-name
and
https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/all-options.json - look for tftp-server-name

makes me think that "data" needs to be a host name like 'one.host.tld', not an IP(v4).

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

With this config the statically mapped clients do not boot and I only receive Option 67 in the DHCP packet.
With a dynamic ip client the option 66 is included.

Because you've defined the "tftp-server-name" in the scope of the pool.
Static defined lease don't get their IP( lease) out of the pool.

What about placing your '"option-data": ... for the "tftp-server-name" one level up ? (merge with the other already present "option-data" below "subnet4" ?

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

Adding the option-data Option 66 to the custom configuration or to the config file directly in the subnet section make the DHCP server include the option 66 in the packets.

Isn't that what you want ?

Edit : Found this ....

[Unaired6288]

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

https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html - look for tftp-server-name
and
https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/all-options.json - look for tftp-server-name

makes me think that "data" needs to be a host name like 'one.host.tld', not an IP(v4).

Good to know, I hadn't noticed. It used to work with ISC DHCP, I set this up a long time ago and hadn't realized this at the time
In the UI the subtext is the following:

Leave blank to disable. Enter a valid IP address, hostname or URL for the TFTP server.

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

Because you've defined the "tftp-server-name" in the scope of the pool.
Static defined lease don't get their IP( lease) out of the pool.

What about placing your '"option-data": ... for the "tftp-server-name" one level up ? (merge with the other already present "option-data" below "subnet4" ?

Thanks for the help, I do understand the issue with the config section and the difference, in fact I have a working setup it's just that it seemed a bit convoluted.

I was mostly looking for clarification regarding the TFTP Server setting in pfSense UI that sets it in the address pool range instead of the subnet, I was just wondering if I had missed something or if I was supposed to define the TFTP Server in the Custom Configuration to have them apply to Static Mappings while other settings do seem to apply to the static mappings when set in the UI.