[Kea-users] kea-dhcp4 server in hybrid environment (dhcp-socket-type raw vs udp)
Darren Ankney
darren.ankney at gmail.com
Sun Sep 13 23:16:03 UTC 2026
Hi Bogdan,
I have been thinking about this and I wonder if the IPSEC tunnel is
the reason. Kea, with "dhcp-socket-type": "raw" (default), must
construct and send packets itself. It doesn't use the Kernel to do so
(you can infer this from the ARM here:
https://kea.readthedocs.io/en/stable/arm/security.html#raw-socket-support).
I don't know for sure, but I suspect Kea would have to support the
IPSEC tunnel (or maybe that isn't even possible ...). I think that
what may be happening here is that Kea simply doesn't support the
IPSEC tunnel such that you *have* to use "dhcp-socket-type": "udp"
regardless if you have local clients. Please can you try this without
the IPSEC tunnel in a test lab to see if it works for both local and
relayed clients?
A couple of possibly relevant GitLab issues:
- https://gitlab.isc.org/isc-projects/kea/-/work_items/3405
- https://gitlab.isc.org/isc-projects/kea/-/work_items/3610
Note that you could probably use "dhcp-socket-type": "udp" and still
server local clients by setting up a local relay to send the traffic
to Kea.
Thank you,
Darren Ankney
On Thu, Sep 10, 2026 at 3:59 AM Bogdan Veringioiu <bveringioiu at amano.eu> wrote:
>
> Hi Darren,
>
> thank you for answering.
>
> Running kea in a local network works fine with the config I show below.
>
> I am trying to adapt this config to work in an IPSEC environment, where on one side there is a debian trixie server that has a public IP and serves clients connected over IPSEC tunnels.
> On the other side there are Draytek routers which connect the clients to the server over IPSEC.
>
> Scenario:
> <debian trixie VM (public IP)> -----------IPSEC tunnel------------------ <draytek router 1>
> 192.168.64.0/24 (left subnet) 192.168.1.0/24 (right subnet)
> |-----------IPSEC tunnel------------------ <draytek router 2>
> 192.168.2.0/24 (right subnet)
>
> - 1 Debian trixie server running kea + strongswan (IPSEC). The server has a public ip and an internal one 192.168.64.60 used as the left side in the IPSEC tunnel.
> - multiple Draytek routers, each routing the 192.168.x.0/24 to the server 192.168.64.0/24 and relaying the dhcp to 192.168.64.60 (server internal IP)
>
> Configs:
> Server IP config:
> $ ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether ........ brd ff:ff:ff:ff:ff:ff
> altname enp3s0
> altname enx0050568c54aa
> inet <public ip>/26 brd x.x.x.y scope global ens160
> valid_lft forever preferred_lft forever
> inet 192.168.64.60/24 brd 192.168.64.255 scope global ens160:1
> valid_lft forever preferred_lft forever
>
> $ ip route show
> default via <public gateway> dev ens160 onlink
> <public subnet>/26 dev ens160 proto kernel scope link src <public ip>
> 192.168.1.0/24 via <public gateway> dev ens160
> 192.168.2.0/24 via <public gateway> dev ens160
> 192.168.3.0/24 via <public gateway> dev ens160
> 192.168.4.0/24 via <public gateway> dev ens160
> 192.168.64.0/24 dev ens160 proto kernel scope link src 192.168.64.60
>
> Kea:
> $ cat kea-dhcp4.conf (showing here just one subnet)
>
> "Dhcp4": {
> ..
> "interfaces-config": {
> "interfaces": ["ens160"]
> },
> ...
> "shared-networks": [
> {
> "name": "xxx",
> "subnet4": [
> ....
> {
> "id": 6,
> "subnet": "192.168.1.0/24",
> "server-hostname": "xxx",
> "next-server": "192.168.64.60",
> "reservations-global": false,
> "reservations-in-subnet": true,
> "reservations-out-of-pool": true,
> "reservations": [
> {
> "hostname": "myhost",
> "hw-address": "FF:FF:FF:FF:FF:FF",
> "ip-address": "192.168.1.11",
> "option-data": [
> {
> "space": "dhcp4",
> "name": "host-name",
> "code": 12,
> "data": "myhost"
> },
> {
> "name": "tftp-server-name",
> "code": 66,
> "data": "192.168.64.60"
> }
> ]
> ...
> },
> ...
> "option-data": [
> {
> "space": "dhcp4",
> "name": "subnet-mask",
> "code": 1,
> "data": "255.255.255.0"
> },
> {
> "space": "dhcp4",
> "name": "broadcast-address",
> "code": 28,
> "data": "192.168.1.255"
> },
> {
> "space": "dhcp4",
> "name": "routers",
> "code": 3,
> "data": "192.168.1.1"
> }
> ]
> }
> }
> }
>
> Using the above configuration, I get the DHCP queries from clients, but the answers don't reach them.
>
> 2026-09-03T16:47:25.694138+02:00 myserver kea-dhcp4[3254371]: 2026-09-03 16:47:25.693 INFO [kea-dhcp4.dhcp4/3254371.140661017962176] DHCP4_QUERY_LABEL received query: [hwtype=1 FF:FF:FF:FF:FF:FF], cid=[01:FF:FF:FF:FF:FF:FF], tid=0x2600e1ad
> 2026-09-03T16:47:25.694606+02:00 myserver kea-dhcp4[3254371]: 2026-09-03 16:47:25.693 INFO [kea-dhcp4.packets/3254371.140661017962176] DHCP4_PACKET_RECEIVED [hwtype=1 FF:FF:FF:FF:FF:FF], cid=[01:FF:FF:FF:FF:FF:FF], tid=0x2600e1ad: DHCPDISCOVER (type 1) received from 192.168.1.1 to 192.168.64.60 on interface ens160
> 2026-09-03T16:47:25.694643+02:00 myserver kea-dhcp4[3254371]: 2026-09-03 16:47:25.694 INFO [kea-dhcp4.leases/3254371.140661017962176] DHCP4_LEASE_OFFER [hwtype=1 FF:FF:FF:FF:FF:FF], cid=[01:FF:FF:FF:FF:FF:FF], tid=0x2600e1ad: lease 192.168.153.20 will be offered
> 2026-09-03T16:47:25.694669+02:00 myserver kea-dhcp4[3254371]: 2026-09-03 16:47:25.694 INFO [kea-dhcp4.packets/3254371.140661017962176] DHCP4_PACKET_SEND [hwtype=1 FF:FF:FF:FF:FF:FF], cid=[01:FF:FF:FF:FF:FF:FF], tid=0x2600e1ad: trying to send packet DHCPOFFER (type 2) from 192.168.64.60:67 to 192.168.1.1:67 on interface ens160
>
> It is only when I added "dhcp-socket-type": "udp", it all started to work.
>
> "interfaces-config": {
> "interfaces": ["ens160"],
> "dhcp-socket-type": "udp"
> },
>
> But If I keep "dhcp-socket-type": "udp", then I cannot run kea where clients are local.
> My goal is to have a unified config that can server both type of clients: direct and relayed. While for the IPSEC scenario I could easily switch to udp, for mixed envs (I have those too), I need to keep raw as dhcp-socket-type I believe.
> With isc, I just defined the subnets/pools/reservations, the routers and the server interface to bind to. This used to work in all possible scenarios we had.
>
> Bogdan
>
>
> ________________________________________
> From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Darren Ankney <darren.ankney at gmail.com>
> Sent: Wednesday, September 9, 2026 10:50
> To: Kea user's list <kea-users at lists.isc.org>
> Subject: Re: [Kea-users] kea-dhcp4 server in hybrid environment (dhcp-socket-type raw vs udp)
>
> Hi Amano,
>
> You can certainly answer both directly connected and relayed clients
> simultaneously. There is not enough information here to address any
> specific problem that you have, but, you may have encountered one or
> more of these pitfalls:
>
> - You may have to specify the relay agent ip address in the subnet or
> shared-network that should be selected for the client traffic
> (https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#local-and-relayed-traffic-in-shared-networks
> and https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#using-a-specific-relay-agent-for-a-subnet).
> - You may have to specify the specific IP address for Kea to listen
> upon (if you have more than one on the interface(s)) as it picks one
> on it's own (https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#interface-configuration)
> which may not be the one you wanted.
>
> There may be others but more information would be needed. Please provide:
> - Your configuration (redact any sensitive information such as
> database passwords, of course).
> - Logs of both types of clients.
> - A PCAP obtained with `tcpdump -w <filename> port 67` containing both
> types of clients would be quite helpful.
>
> Thank you,
> Darren Ankney
>
> On Tue, Sep 8, 2026 at 6:50 AM Bogdan Veringioiu <bveringioiu at amano.eu> wrote:
> >
> > Hello,
> >
> > I have recently migrated isc-dhcp-server to kea-dhcp4 (debian trixie).
> > After doing this I realized that I could not run kea the way I used to run isc, meaning:
> > - Local clients (directly connected, same lan), this works fine with the default dhcp-socket-type = raw
> > - Relayed clients (routed networks or clients connected over vpn tunnels) work fine with dhcp-socket-type = udp
> > - Hybrid environments where kea should manage subnets with directly connected clients and routed subnets (relays) simply do not work. Kea needs to have either raw or udp for dhcp-socket-type.
> >
> > All 3 above scenarios used to work fine with isc with a single unified config. The way I understand it, scenario 3 is not possible with Kea.
> > Can you please confirm this, or advise how can I use kea as a drop in replacement for isc ?
> >
> > I am working on a solution to run 2 kea instances, but it complicates things.
> >
> > Thank you very much
> >
> > --
> > Bogdan Veringioiu
> >
> > Amano Parking Europe N.V.
> > Uersfeld 24
> > 52072 Aachen, Germany
> >
> > e-mail: bveringioiu at amano.eu
> > web: www.amano.eu
> >
> > --
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > Kea-users at lists.isc.org
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
>
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
More information about the Kea-users
mailing list