24.1 - DHCP server moves to KEA - implications?

[vinfra-dude]

...

ok i did the same , i unchecked and checked both options leases and static in unbound and restart unbound, but wont work.
Maybe you still had remnants of the isc in the unbound host entries.

I found this setting to be set to no .. may be you can try to set it to yes and restart kea-dhcp and see of ddns registration with unbound for dhcp works

default

Code: [Select]

/usr/local/etc/kea/keactrl.conf
# Start DHCP DDNS server?
dhcp_ddns=no

change to

Code: [Select]

/usr/local/etc/kea/keactrl.conf
# Start DHCP DDNS server?
dhcp_ddns=yes

i am still trying to figure out how i can import my isc-dhcp config migrated to kea-dhcp4.conf json file using KeaMA into opnsense

[MiRei]

Many thanks for the great work done in this project!

In ISC DHCP it was possible to activate "Deny unknow Clients" and "ARP-Table".
Will there also be this possibility in KEA in the future ?

[franco]

Whatever ISC offers and Kea does too we can eventually implement. But mind you decades of work went into the current ISC integration so playing catch-up is going to take a while. Feature requests in GitHub will be handled in order of simplicity and need-to-have basis.


Cheers,
Franco

[MandyBaxter]

Just sharing a few items.

First, I'm fairly certain this has been reported previously --
The web tool for KEA apparently produces malformed JSON syntax in kea-dhcp4.conf. At issue is an extra comma after the second to last closing square bracket. As syntax checking is a core function of a web tool, this is hopefully on somebody's ToDo list.

WARN [kea-dhcp4.dhcp4.0x834b11000] DHCP4_CONFIG_SYNTAX_WARNING configuration syntax warning: /usr/local/etc/kea/kea-dhcp4.conf:85.10: Extraneous comma. A piece of configuration may have been omitted.

Second --
If KEA is disabled on the interface, the config file /usr/local/etc/kea/kea-dhcp4.conf goes to 0 bytes. Re-enable gets the file clobbered, re-written with the bad syntax. Turning the service off via the dashboard button doesn't do this, at least. (Maybe this is typical behavior with opnSense and I just haven't noticed; haven't previously had to root around tinkering config files before.)

Third --
I haven't yet gotten KEA to actually put out a lease. The closest is that the daemon seems to prepare to do so. But, the client never receives it. Presumably, the log should next note a client acknowledgment. (Or, I might be mis-remembering the basics of the protocol; it's been two decades since I spent this much time futz'ing around with a dhcpd.)


INFO [kea-dhcp4.leases.0x835789400] DHCP4_LEASE_ADVERT [hwtype=1 18:fd:cb:b0:03:ce], cid=[no info], tid=0x22348769: lease 192.168.50.202 will be advertised

Fourth --
Thanks to all putting in the effort on getting KEA integrated. Frankly, it's a Good Thing these teething issues are getting surfaced now, given the original ISC dhcpd is going to stick around for the time being. For now, I have to fall back. I'll re-try after an update or two are accomplished.

[RedVortex]

DHCPd opens a raw interface on all network interfaces. I don't think it is possible (at least with ISC DHCPd) to use two different DHCP daemons on one host simultaneously.

Correct for ISC-DHCP.

As previously stated, ISC-DHCP and KEA can run in parallel on different interfaces. I've done the transition on production systems with no downtime - as follows:


1) Create Subnet and Reservations for VLAN X in Kea

2) Go to ISC DHCP and disable it on VLAN X -- leaving it running on the other VLANs

3) Go to Kea and enable VLAN X in Settings

4) Validate and continue with the next VLAN in scope were Kea can run without missing any ISC functionality


QED

Unfortunately this isn't true. You were simply lucky that your dhcp leases continued to work while you transition.

KEA and ISC cannot coexists. ISC can only bind to *:67. While that is happening either you're unable to start KEA (it will show as green but will not run in reality) of if you are able to start both (you need to start KEA first and then ISC), they will start conflicting and you will not be able to reload/restart KEA after ISC has started anyways.

Here's what you'll get if you are able to run both at the same time

Code: [Select]

root@opnsense:~ # sockstat -4l -p 67
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
dhcpd    dhcpd      61078 13 udp4   *:67                  *:*
root     kea-dhcp4  964   14 udp4   192.168.22.1:67       *:*
root     kea-dhcp4  964   16 udp4   192.168.42.1:67       *:*
root     kea-dhcp4  964   18 udp4   192.168.62.1:67       *:*
root     kea-dhcp4  964   20 udp4   192.168.63.1:67       *:*
This will prevent both from working properly.

And if you look into your KEA logs, even if the process shows as green, in reality it is not working and you'll see this, for each interface you are trying to start in KEA, even if you disabled it first in ISC.

Code: [Select]

WARN [kea-dhcp4.dhcpsrv.0x833712000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface ix1_vlan630, reason: failed to bind fallback socket to address 192.168.63.1, port 67, reason: Address already in use - is another DHCP server running?


[newsense]

Unfortunately this isn't true. You were simply lucky that your dhcp leases continued to work while you transition.

Unfortunately it is true. Gamblers need not apply.


It takes 3 seconds to stop ISC DCHP on one interface and enable it in KEA.


Should one be so careless as to do changes from a DCHP client that happened to expire _exactly_ during the 3 seconds service swap a static IP can be temporarily set on the client.

[Azmodes]

In ISC DHCP it was possible to activate "Deny unknow Clients"

I'd imported all my subnets, settings and reservations, was about to make the switch when I noticed that this option was missing. Are there any plans to add it in the near future?

[Wrigleys]

Good morning everyone

After the migration to KEA DHCP I‘ve noticed that not always all DHCP leases where shown on the Leases Page.
Sometimes a lease showing up and some time later the same lease isn‘t listed anymore, but the corresponding client is still active/online.

Did you noticed missing devices on the lease page too?

All the best and thanks to the Devs for this awesome release!

regards,
Wrigleys

[xkpx]

Kea migrate was easy , thanks for implement.
I just miss one thing to remove clients from leases, it's maybe expected but it`s unknown to me why one i have the server on 0.74 , and i have new reservation to point again to 0.74 but kea gives me 0.150 on image bellow.
How you remove the old lease ?
Keep the good work!

~PS. After some time of refreshing the NIC , correct ip is set !

[knaggsy2000]

I've been a LONG time user of OPNsense, ever since m0n0wall suggested this alternative (back on WRAP hardware), many years ago.

Just registered for the first time to elaborate on some points (as I've just seen this in the changelog): -

• I know why Kea is being added as the older ISC DHCP package has been EoL'ed
  But, the UI for Kea (as provided by OPNsense) is NOT functionally equivalent to the original ISC DHCP in many ways, including not being able to exclude "known clients" and I don't even see a IPv6 option too.
• There DOES need to be the ability to move over settings from ISC DHCP, as like others mentioned earlier - I've got multiple interfaces/VLANS.
• Numerous users have also reported so many features NOT available so far.  For example, defining TFTP, DNS, NTP addresses, etc

Personally, I don't think Kea is ready to be added to OPNsense at this time.

Just my two pence.


Edit: To mention about the lack of services Kea doesn't.  At least in the OPNsense way.

[ProximusAl]

I have a very simplistic setup, so moved over from ISC to KEA.

The main thing I miss is the ability to update unbound with the leases, so currently, I do not have name resolution but other than that, its fine for me.

One little thing, on one of my reservations, I have a device called revo, but when I show it under leases it shows revo. (With a dot)



This is the only device (out of 50) that does this?!?

[franco]

> Personally, I don't think Kea is ready to be added to OPNsense at this time.

Fair enough, but stating 3 obvious points and concluding we should not ship it which means we will stop improving it in the first place is a bit strange IMHO.

If you meant to say it's not ready for your use your wording could benefit from improvements.

No disrespect, just stating the obvious (again).


Cheers,
Franco

[ndom91]

There were no plans for migrating the existing DHCP data to Kea as far as I now.

This certainly is a deal breaker. I do have more than 50 DHCP Static Mappings on about 20 VLANs. I am not really inclined to recreate all of them manually.

It looks like the ISC has put up a config file migration assistant. I took my `/var/dhcpd/etc/dhcpd.conf` and pasted the contents into the webapp and it kicked out a valid Kea config

https://dhcp.isc.org

EDIT: I couldn't find where the kea config was saved, i.e. where to paste in the new config. But I did find that they allwoed reservations imported via CSV in the opnsense Kea page. The format is:

Code: [Select]

ip_address,hw_address,hostname,description

EDIT 2: Looks like its

Code: [Select]

/usr/local/etc/kea/kea-dhcp4.conf
Be careful pasting it in directly though, the Kea migration assistant config doesn't include any interface info. You'll definitely have to go through and do some updates based on the autogenerated original kea config at the path above ^

[franco]

This can help you with manual configs, but not with config generation glue from GUI settings.


Cheers,
Franco

[hansen97124]

Is anyone else having issues with KEA reservations being ignored.

On my LAN, I have a win 10 PC and several IP security cameras that have a KEA reservation, but another (different) IP address is being automatically assigned.