OPNsense Forum
English Forums => 24.1 Production Series => Topic started by: chemlud on January 19, 2024, 01:40:26 pm
-
Hi!
No 24.1 board yet, so posting in 23.7 forums.
I read in the release notes for 24.1 RC1:
ISC DHCP functionality is slowly being deprecated with the introduction of Kea as an alternative. The work to replace the tooling of ISC DHCP is ongoing, but feature sets will likely differ for a long time therefore.
Would be quite helpful to know which problems might araise from this, which use cases might not be covered when moving to 24.1. Is a new installation recommended for 24.1 due to this?
-
The old DHCP still exist, you are not "mandated" to switch to Kea.
-
Yes, ISC remains the same. There are a lot of tweaks and advanced extras in ISC that don't have immediate equivalents in Kea so it's going to be a slow crawl towards feature parity if that will even ever be reached (expecting some older advanced ISC features are no longer in use).
Created the board for 24.1 now and moved this here.
Cheers,
Franco
-
Hi and thanks for clarifications. If I use, let's say, MAC-reserved IPs for different IPs and not much more, what will the process of transition to KEA look like?
Install the new KEA plugin (?) and move (manually? automagically?) my current DHCP config to the new plugin?
Many thanks in advance.
-
Dynamic leases "just work". There is an interface for static reservations that I have not yet tested.
What's definitely missing, at least from the UI, are custom options like "Unifi Controller address" etc.
Only:
- gateway
- DNS server
- NTP server
- TFTP server
are offered in the pool settings.
Registration of dynamic leases in Unbound works - yeah! :)
-
There's a cosmetic bug which becomes visible with WiFi devices when power saving is enabled, and you'll end up seeing multiple entries in the leases tab for the same device even though the previous lease is valid. The issue is already reported on GH.
Static reservations work fine, one just needs to pay attention to the VLAN the entry is created on.
There were no plans for migrating the existing DHCP data to Kea as far as I now.
Kea and the old client can run in parallel on different vlans. Simply disable the old server on a vlan, copy all reservations/useful data to a text editor, go to Kea and set up the vlan in Subnets, add the Reservations, then to Settings to have Kea run on the interface.
Should there be a need, disable Kea on the interface and reenable it on the other side.
-
I am running into an issue where I configure a DHCPv4 subnet with a DNS server IP other than the opnsense IP, save the subnet, and when I view the subnet the DNS server has been overwritten as the opnsense server IP. I can confirm that the opnsense server IP is being handed out by kea.
-
@bbin
you have to uncheck Auto collect option data in the subnet settings
@Patrick M. Hausen
how you get the leases to register in unbound ?
i stopped isc and start kea, reserved leases come in, but unbound wont resolve them.
-
@Patrick M. Hausen
how you get the leases to register in unbound ?
i stopped isc and start kea, reserved leases come in, but unbound wont resolve them.
Disabled ISC DHCPv4, enabled Kea DHCP, created subnet, pool etc.
Service > Unbound DNS > General > Register DHCP Static Mappings [X]
Pull cable from my Mac, plug back in.
I then got a successful DNS lookup for <my Mac>.localdomain - but seemingly I cannot reproduce it just right now. Hmmm ...
-
...
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 tried using kea without luck so far... Even though I disabled the ISC server on my vlan 630, stopped and started ISC to make sure it frees up the listening on port 67 on 192.168.63.1 but kea still complains it's unable to start properly
WARN [kea-dhcp4.dhcpsrv.0x83359d000] 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?
Checking netstat, I see *:67 so I guess ISC is listening on *:67 and prevents kea from running side-by-side.
Still trying to see if there is a way around this...
-
When kea starts (I stopped ISC first) it properly bind to only the IP it needs to
udp4 0 0 192.168.63.1.67 *.*
But if I stop kea and starts isc (even though it's not enabled on all interfaces) it binds to everything and thus blocks kea from working
udp4 0 0 *.67 *.*
-
Binding to things is a bit of a grey area for DHCP servers.
You might find out that ISC binds to a low level socket that handles all DHCP packets, regardless of if it should or not. Which is the reason we found it impossible to run multiple ISC DHCP servers on one host.
In KEA it is possible to disable that behaviour, but I'm not sure if that actually works in a non-relay environment.
In short, it might be that it is not a good idea to run multiple DHCP servers on one host, depending on the specific implementation in opnsense and your network.
-
I've run into an issue with it. Now I'll be honest, I forget how ICS works, and I'm not sure how it's been implemented into opnsense. Does it fork for each interface?
A concern I have is that I have 3 active internal interfaces. Maybe I'm old school, but I was trying to figure out how to set it up per interface, and then I realized, you just put them all into one line. It gives me anxieties, and I wonder... anyone assess it for possibilities of it leaking all of the subnets it serves? I don't offsec as great as i want to. Or... great at all. By ANY context of the word. 🫢
I did hit a problem with it. It was only serving my LAN interface, despite having the appropriate subnets entered. I can tear into it but is there by chance someone who's already done it? I went back to ICS right now because I was down nearly all day. Fwiw, I had just done a clean, fresh install of 23.7 before changing to the dev branch. I had an anomaly routing issue that was preventing one of my interfaces from having a functional wan connection, and it was easier to reinstall than continue tearing apart the config. Note: there are still some issues with configuring opnsense using a combination of console and webui. I'll document those this weekend if I have time.
Regarding:
Binding to things is a bit of a grey area for DHCP servers.
When did this become a thing? Most modern daemons that are likely to have bindings for segmented services, are either expected to run multiple instances (granted, most of the time it's dockerized) or forks itself for each configured instance.
In short, it might be that it is not a good idea to run multiple DHCP servers on one host, depending on the specific implementation in opnsense and your network.
I assume that a majority of opnsense deployments are currently serving DHCP to more than one interface. It's highly probable. It's kind of a thing that an advanced router would be desired for. Im asking this with all sincerity. Do you have alternate suggestions for serving multiple interfaces that would allow it to be brought up or down easily on that interface (with settings preserved)? I'd appreciate a better understanding, also, of why binding it to the interface is a grey area. It's just that I've never heard that. But opnsense is the only software I've ever had to run FreeBSD, so I'm pretty ignorant on BSD particularities. I use just about every flavor of Enterprise Linux (RHEL/centos/fedora/rocky/alma/etc) and Debian or Ubuntu when I have to (thankfully docker has saved me from that mostly). Anyway, I'd love to hear more on this please.
-
Btw, I do understand the need to transition, and It might make configuration simpler for many people. I understand the UI isn't final form yet either. But DHCP is one of those things you expect to "just work" and when it doesn't, and you can't find a logical reason, it's frustrating. I'll give it a try again this weekend at 2am when I'm the only one awake, and I'm not blaming anyone or angry about it, I'm.. I guess I'm disappointed by kea so far. But I've never used it. I'll deep dive it and hopefully it won't feel like a regression.
-
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.
-
Then don't lol.
Current DHCPB is not going away (yet).
I'm very happy to see them implement KEA as it's the way.
-
I was about to make the switch in my home lab when I found you cannot even serve the domain name to clients. Sorry, that is not going to fly.
-
Hello all,
Upgraded from 23.7.12 to 23.7.12_5 and then immediately to 24.1_1.
Running 4 physical interfaces with separate networks on each, 2 wan, 2 lan with DCHP service.
Switched from ISC to Kea DHCPv4
Transitioned to the Kea DHCPv4 service was simple but seems to be an all or nothing issue.
Attempting to get Kea listening on interface 1 would not work with ISC DHCPv4 listening on interface 2 (seems the ISC DHCPv4 server locks the port on all interfaces).
Once I had both subnets defined (you can do them separately for clarity) and disabled the ISC DHCPv4 instances Kea was able to start as per the logs and as per GUI.
I would be happy to test the Kea implementation further.
Thanks
-
Have not attempted to use the new KEA
Have used ISC to do static reservations, and enable the Dynamic DNS feature to external BIND (Primary & Secondary), and finally just got all of the /24 subnetting squared away necessary for the Reverse DNS portion of the protocol to do its thing (/24s for each zone). All subnets populating, no syslog errors for DHCP registrations (also cleared up my pools - the static assigned used / dynamic pool space)!
This is to comment excitement for the new feature, I've been interested in using an IPAM, and setting up details that allow auto subnetting / DHCP pool expressions - seems this might enable that future quite nicely.
Of current transition to KEA primary need is:
- serve domain name
- serve domain suffix search
- enable dynamic dns with config of master bind, domain key, more or less the dynamic dns functionality that exists for ISC in OPNSense now
There's probably a reasonable list of features others have used for BOOTP/etc. though I'm not trying to swim in that pool that deep right now and cannot comment to their use or have any testability in that space.
-
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.
-
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.
-
Kea and the old client can run in parallel on different vlans. Simply disable the old server on a vlan, copy all reservations/useful data to a text editor, go to Kea and set up the vlan in Subnets, add the Reservations, then to Settings to have Kea run on the interface.
Should there be a need, disable Kea on the interface and reenable it on the other side.
But how are you associating VLAN >> Subnet? Does it just guess based on the interface IP address? I don't see any option to associate a subnet to a VLAN in the Kea config whereas ISC there's a direct mapping to VLAN/Interface >> DHCP Subnet.
-
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 :)
-
I am unable to set the correct DNS server in the subnet configuration. I input the correct IP address for my DNS server, which is not on OPNsense, save & apply, but when I go back into the subnet configuration screen, the IP address has been overwritten with that of the OPNsense LAN interface. I have not tested any further to see what address would actually be provided to the client, though. Bug?
-
Untick Auto collect option data on the subnet
-
To the original question --
You'll need adjust your ruleset for UDP 67 & 68 on whichever interface(s) you expect to support. Apparently, OPNsense automatically sets up a rule for ISC dhcpd when it's enabled on an interface, but not for KEA dhcpd. (In the logging, the ISC rule shows up with the label "allow access to DHCP server").
On missing features --
OPNSense's web interface for KEA doesn't cover logging options. (Or, if it does, I haven't found it yet.) Remote syslog to a centralized server is kinda key. Mr. Google helpfully finds examples on how to set this up manually for KEA. So, it seems the KEA dhcpd has this capability.
-
To the original question --
You'll need adjust your ruleset for UDP 67 & 68 on whichever interface(s) you expect to support. Apparently, OPNsense automatically sets up a rule for ISC dhcpd when it's enabled on an interface, but not for KEA dhcpd. (In the logging, the ISC rule shows up with the label "allow access to DHCP server").
It is coming in 24.1.1, it can be added now if needed:
https://github.com/opnsense/core/commit/b1685d8e467d755fa1cf7203a82b63f2a115cb05 (https://github.com/opnsense/core/commit/b1685d8e467d755fa1cf7203a82b63f2a115cb05)
opnsense-patch b1685d8
-
I was about to make the switch in my home lab when I found you cannot even serve the domain name to clients. Sorry, that is not going to fly.
Has anyone tried kea and verified that it does not serve the routers domain name? Even thou it is not configurable in kea.
-
I tried using kea without luck so far... Even though I disabled the ISC server on my vlan 630, stopped and started ISC to make sure it frees up the listening on port 67 on 192.168.63.1 but kea still complains it's unable to start properly
WARN [kea-dhcp4.dhcpsrv.0x83359d000] 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?
Checking netstat, I see *:67 so I guess ISC is listening on *:67 and prevents kea from running side-by-side.
Still trying to see if there is a way around this...
I have multiple vlans and was getting the same type of error messages. What worked for me was stopping the ISC DHCP service and then starting the KEA DHCP service. Before shutting down ISC DHCP service (clicking the red square button) I only disabled the particular VLAN interface within ISC DHCP that I wanted to test in KEA DHCP. I thought that was enough but it wasn't because ISC DHCP was still running and binding to the VLAN interface eventhough I had disabled listening on it in ISC DHCP.
-
...
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
/usr/local/etc/kea/keactrl.conf
# Start DHCP DDNS server?
dhcp_ddns=no
change to
/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
-
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 ?
-
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
-
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.
-
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
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.
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?
-
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.
-
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?
-
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
-
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 !
-
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.
-
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)
(https://i.ibb.co/hHmvTN8/wer.png) (https://ibb.co/d65yHvK)
This is the only device (out of 50) that does this?!?
-
> 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
-
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:
ip_address,hw_address,hostname,description
EDIT 2: Looks like its /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 ^
-
This can help you with manual configs, but not with config generation glue from GUI settings.
Cheers,
Franco
-
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.
-
Open the ur config-OPNsense*.xml, the reservation uuid is unique per reservation and should have one subnet uuid if they belong to that subnet.
</reservations>
<reservation uuid="6a688941-02f8-46aa-abc6-8121fa434809">
<subnet>7046c7cb-a9fb-4a50-8a49-3b6e77d42809</subnet>
<ip_address>192.168.1.100</ip_address>
<hw_address>90:a1:b1:c1:d1:e11</hw_address>
<hostname/>
<description/>
</reservations>
-
> 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
As a software developer/engineer myself, when including new features that *typically* gets put into an alpha or beta build or some other testing environment - NOT the mainstream/stable one. That is bad practice. As for the "obvious" points, they were mainly from other users.
Kea IS CLEARLY not ready, as it can't replace the original ISC DHCP.
I can understand you want feedback, but you also see where I'm coming from right? I can symbolise.
Please talk to me as an human being.
-
Open the ur config-OPNsense*.xml, the reservation uuid is unique per reservation and should have one subnet uuid if they belong to that subnet.
</reservations>
<reservation uuid="6a688941-02f8-46aa-abc6-8121fa434809">
<subnet>7046c7cb-a9fb-4a50-8a49-3b6e77d42809</subnet>
<ip_address>192.168.1.100</ip_address>
<hw_address>90:a1:b1:c1:d1:e11</hw_address>
<hostname/>
<description/>
</reservations>
But that shouldn't even required - as OPNsense is mainly a web-based OS. Mentioned about his before.
-
below is an example of from the config file.
looks ok to me. Still not sure why the reservations are being ignored. The client camera is set to DHCP, as it should be.
<reservation uuid="de71a788-801a-450f-b238-9ed0c4ee8656">
<subnet>19b11319-3d95-40c0-8668-56b15a05a6c0</subnet>
<ip_address>192.168.1.241</ip_address>
<hw_address>9c:8e:cd:1e:xx:xx</hw_address>
<hostname>amcrest1080</hostname>
<description>amcrest1080</description>
</reservation>
(changed MAC address to xx:xx at the end. No other changes made to the code.)
-
Hansen97124
Is it in between <reservations> and </reservations> tags?
Does the reservations show up in the kea reservation gui?
Are u sure the reservation subnet uuid is correct for your network?
Search on the subbnet uuid. 19b11319-3d95-40c0-8668-56b15a05a6c0
It should match ur network u declared earlier.
-
EDITED: I Figured it out!!
Previously, I Had a problem with KEA DHCP reservations being ignored. (several posts above)
Simple mistake. For subnet I entered
192.168.1.0/24 instead of
192.168.1.1/24
I honestly thought it needed to be "zero" at the end, and not "one" for subnet name. The docs section for KEA DHCP even uses 192.168.1.0/24 as the prime example.
Maybe someone may be able to explain why mine has to be 192.168.1.1/24 in order to get reservations to work. <please>
Live and learn. Back to using KEA DHCP.
Thanks all for the help!!
-
Hansen97124
Search on the subbnet uuid. 19b11319-3d95-40c0-8668-56b15a05a6c0
It should match ur network u declared earlier.
It didn't match. This was the major hint that I needed to get to the solution described in the post just above this one.
Thanks again.
-
Hi and thanks for clarifications. If I use, let's say, MAC-reserved IPs for different IPs and not much more, what will the process of transition to KEA look like?
Install the new KEA plugin (?) and move (manually? automagically?) my current DHCP config to the new plugin?
Many thanks in advance.
I wrote a utility to make that migration painless.
https://github.com/EasyG0ing1/Migration (https://github.com/EasyG0ing1/Migration)
Mike
-
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.
https://github.com/EasyG0ing1/Migration (https://github.com/EasyG0ing1/Migration)
-
I was about to make the switch in my home lab when I found you cannot even serve the domain name to clients. Sorry, that is not going to fly.
You assign the domain name to the subnet in the Kea service, though you are correct you cannot assign a domain name that is different for each static mapping. Though I'm not sure why anyone would want different domain names for IP addys that are on the same subnet...?
Also, check this out for migrating your statics
https://github.com/EasyG0ing1/Migration (https://github.com/EasyG0ing1/Migration)
-
switching from isc to kea worked fine for me.
- as reported I could not continue using isc and kea in combination (I have different vlans)
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?
-the easiest way for me to solve: leave subnet / pools empty
-
switching from isc to kea worked fine for me.
- as reported I could not continue using isc and kea in combination (I have different vlans)
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?
-the easiest way for me to solve: leave subnet / pools empty
I didn't know this was an option ... I assumed that subnets were mandatory for Kea so that it knows which IP pools to draw from when an inbound request for an address happens where it gets a request for an IP address, looks at the subnet that it came from, matches that subnet to one that is defined in Kea, then pulls an IP address from one of those pools. Are you saying that it will still do that correctly for multiple subnets without defining the subnet specifically within Kea?
-
And if you don't like neither, you may use dnsmasq. Yup, you can run both dnsmasq and unbound (on different ports), e.g. dnsmasq forwarding calls to unbound.
-
I didn't know this was an option ... I assumed that subnets were mandatory for Kea so that it knows which IP pools to draw from when an inbound request for an address happens where it gets a request for an IP address, looks at the subnet that it came from, matches that subnet to one that is defined in Kea, then pulls an IP address from one of those pools. Are you saying that it will still do that correctly for multiple subnets without defining the subnet specifically within Kea?
no. subnets need to be defined, but within the subnet page you can leave the pools section empty. in that case only predefined clients (reservations) are served. This is similar to "deny unknown clients" in isc.
Others asked to implement this option in kea but I do belive it is included that way.
-
Hi all,
I'm not really sure where to post this, but for my own purposes I rewrote the `unbound_watcher.py` script to ingest DHCP leases from kea instead of dhcpd and create DNS registrations. This breaks dhcpd compatibility but for me it brings the added bonus that I now have synced DNS registation on both my HA opnsense nodes. It's far from perfect, but I hope someone finds this useful?
https://gist.github.com/h3krn/17c6610281e585d6b4efb43d1395802d
Grtz, Harm
-
It's far from perfect, but I hope someone finds this useful?
https://gist.github.com/h3krn/17c6610281e585d6b4efb43d1395802d
Grtz, Harm
Thank you very much! This is most missing feature of KEA DHCP for me. You should try to upstream this into OPNsense.
I adjusted it little bit because it gave me double domain for some hosts: https://gist.github.com/pkejval/49ff234bb81da59fde6ca1b03f4d4240/revisions
-
Thnks for the feedback pkejval. I already found several more issues with my version.
- when kea cleans the memfile, the inode nr does not change. So the tailing stops.
- sending a break, stops csv.dictreader from tailing the file.
- need to add parsing of the kea config to assign the correct dns domain to a range.
I'll try to improve over time, but for now its a WiP. Once I have something that's actually running, we can try to get it upstream.
It's far from perfect, but I hope someone finds this useful?
https://gist.github.com/h3krn/17c6610281e585d6b4efb43d1395802d
Grtz, Harm
Thank you very much! This is most missing feature of KEA DHCP for me. You should try to upstream this into OPNsense.
I adjusted it little bit because it gave me double domain for some hosts: https://gist.github.com/pkejval/49ff234bb81da59fde6ca1b03f4d4240/revisions
-
@pkejval, I've just posted a update to my gist that should tackle points 1 and 2.
Now I need to add some logic to parse the kea dhcp ranges to pull the dns domains.
Thnks for the feedback pkejval. I already found several more issues with my version.
- when kea cleans the memfile, the inode nr does not change. So the tailing stops.
- sending a break, stops csv.dictreader from tailing the file.
- need to add parsing of the kea config to assign the correct dns domain to a range.
-
in pfsense 24.03 you can easily switch dhcp backend from ISC to KEA (and vice versa) with 2 click. I wish Opnsense would implement something similar. reservation and so on are still in place.
see attachment.
-
in pfsense 24.03 you can easily switch dhcp backend from ISC to KEA (and vice versa) with 2 click.
I heard more nuanced feedback from this approach to be honest, but I agree it is easy from a user perspective as long as it works. ;)
However, it's never easy especially with DHCP being one of the most complex pieces of code in the projects and people having discussed how to get rid of this code for over a decade already.
Cheers,
Franco
-
I have struggled getting Kea HA to work - it seems it only works for me, when I configure the Peer/HA ports to be the same as the Control Agent port. (contrary to what the GUI says).
When I run the CA on port 8000 and the Peers on port 8001. I can connect to the Peer HA port with telnet/curl from the local device only - it does not work from the remote/partner device. The traffic is not blocked by the firewall.
I can confirm with netstat -a that it is listening on port 8001, but it does for some strange reason not work...
Running everything on port 8000 works like a charm.