you can work around this by using linux namespaces and/or virtual
interfaces (and keep dnsmasq still running).
there is already a ticket about this:
https://gitlab.isc.org/isc-projects/kea/-/issues/3006
for a workaround see comment
https://gitlab.isc.org/isc-projects/kea/-/issues/3037#note_600694
hope this helps.
Razvan
------------------------------------------------------------------------
*From: *Razvan <[email protected]>
*To: *Stuart <[email protected]>
*Cc: *Kea <[email protected]>
*Date: *Saturday, 21 February 2026 1:52 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
configured bridged network
you can simply try 'killall dnsmasq' and see if you get traffic.
regards,
Razvan
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
*To: *Razvan <[email protected]>
*Cc: *Kea <[email protected]>
*Date: *Saturday, 21 February 2026 1:43 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not working on newly
configured bridged network
There is an instance of dnsmasq running on virbr0, which is
the default "nat" interface for kvm vms not using bridged
networking. The virbr0 network is supposed to be isolated from
the rest of the network, but it is possible; According to the
output of netstat -lntup"
tcp 0 0 127.0.0.1:8000 0.0.0.0:*
LISTEN 2707/kea-ctrl-agent
tcp 0 0 192.168.1.104:5357 0.0.0.0:*
LISTEN 2732/python3
tcp 0 0 0.0.0.0:37099 0.0.0.0:*
LISTEN 2718/rpc.mountd
tcp 0 0 192.168.100.1:53 0.0.0.0:*
LISTEN 3028/dnsmasq
...
udp 0 0 192.168.100.1:53 0.0.0.0:* 3028/dnsmasq
udp 0 0 127.0.0.54:53 0.0.0.0:* 1548/systemd-resolv
udp 0 0 127.0.0.53:53 0.0.0.0:* 1548/systemd-resolv
udp 0 0 0.0.0.0:67 0.0.0.0:* 3028/dnsmasq
That last line is a bit of a worry, I think kea DHCP4 would be
running on 0.0.0.0:67 if it were running. I'll just check....
tcp 0 0 192.168.1.104:8003 0.0.0.0:*
LISTEN 845230/kea-dhcp4
When I started dhcp4 the only record netstat-lntop had of it
was tcp rather than udp, but i thought that kea ran on udp by
default unless specified. I actually think the 8003 port is
where the stork server communicates, so perhaps the dnsmasq is
blocking kea from udp.
When I disconnect virbr0 and start kea-dhcp4-server I still
get dnsmasq on 0.0.0.0:67 udp, even though dnsmasq is not
installed on my computer and only runs as part of qemu-kvm. I
will look into this further in the morning.
Regards
Stuart MacGregor
On 21/2/26 21:17, Razvan Becheriu wrote:
netstat -lntup
is dnsmasq running/binding to same iface/addr/port?
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
<mailto:[email protected]>
*To: *Razvan <[email protected]> <mailto:[email protected]>
*Cc: *Kea <[email protected]>
<mailto:[email protected]>
*Date: *Saturday, 21 February 2026 12:57 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not working on
newly configured bridged network
Razvan,
I tried adding interface "br0" to both my subnets a
few days ago, there was no measurable change so I
removed the lines again.
On 21/2/26 20:48, Razvan Becheriu wrote:
can you add “interface”: “br0” to each of your
subnets?
set logging to DEBUG and level 99
you can overwrite logging temporarily by passing
KEA_LOGGER_SEVERITY="DEBUG" KEA_LOGGER_DBGLEVEL=99
KEA_LOGGER_DESTINATION="stdout"
before ./kea-dhcp4 -c …
------------------------------------------------------------------------
*From: *Stuart <[email protected]>
<mailto:[email protected]>
*To: *Kea <[email protected]>
<mailto:[email protected]>; Razvan
<[email protected]> <mailto:[email protected]>
*Date: *Saturday, 21 February 2026 12:35 PM EET
*Subject: *Re: [Kea-users] Kea DHCP4 not
working on newly configured bridged network
Razvan,
The secondary kea server is on a completely
seperate computer. My home network
infrastructure consists of on decent (ish)
server and several, old, second hand computers
I bought cheap. One of these runs the
secondary server. It binds to the standard
ethernet port of that machine and then
services the network via the router. As I said
the main server is connected to the router
through br0. It connects to the internet and
to other computers on the network (e.g. it
shares files via samba). It even contacts the
secondary dhcp server to ask it to turn off
when I restart kea-dhcp4-server. It then just
doesn't offer leases. The VMs connect to the
router via the Bridged Network and then
receive dhcp DORA from the secondary server
via the router, so long as the main server is
off and failover is complete.
There are no files at all in /var/log/kea.
There is also no fles called kea-dhcp4.log in
/var/log, where the config file indicates it
should be. I think my logging parameters are
screwed up, perhaps I need to change the debug
level or severity, perhaps there is a stupid typo.
Regards
Stuart MacGregor
On 21/2/26 20:10, Razvan Becheriu wrote:
Hi,
How is it that the vms acquire ip using
secondary server? does the secondary bind
on the same interface at the same time?
Logs should be under
/kea/install/path/var/log/kea
I think that only one of your servers
successfully binds to the interface and
because the server uses reuse port/address
the secondary if starts second will
receive traffic.
------------------------------------------------------------------------
*From: *Stuart
<[email protected]>
<mailto:[email protected]>
*To: *kea-users
<[email protected]>
<mailto:[email protected]>
*Date: *Saturday, 21 February 2026
3:31 AM EET
*Subject: *[Kea-users] Kea DHCP4 not
working on newly configured bridged
network
Good Morning,
I am running Ubuntu 24.04, Kea 2.4.1.
I have been using Kea without major
issues for a year or two, isc-dhcp for
a couple of years prior. During recent
kernel updates I decided I was sick of
Virtualbox compatibility issues, so I
created a bridged network so that I
could move my vms (Nextcloud, Stork)
to KVM. I am somewhat incompetent, but
after about 100 attempts I have
managed to setup a bridged network
that connects my server to the rest of
the network and to the internet. My
new KVM VMs are joining the network as
if they were real devices. My problem
is my kea DHCP4 server. I guess have
done something stupid, either with
selecting the interface in
kea-dhcp4.conf or with configuring my
bridged network (br0). At this stage,
when I start kea-dhcp4-server, it
communicates to my HA standby to to
take control of DHCP but then
completely fails to provide ip
addresses itself. So, the network
currently looks like this:
/dad@macserver:~$ 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
inet6 ::1/128 scope host
noprefixroute
valid_lft forever preferred_lft forever
2: enp34s0:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc fq_codel master br0 state
UP group default qlen 1000
link/ether 2c:f0:5d:2d:88:35 brd
ff:ff:ff:ff:ff:ff
3: br0:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc noqueue state UP group
default qlen 1000
link/ether 42:4c:23:6c:4d:7f brd
ff:ff:ff:ff:ff:ff
inet 192.168.1.104/23 brd
192.168.1.255 scope global
noprefixroute br0
valid_lft forever preferred_lft forever
inet6 fe80::e54c:73f4:f662:95fb/64
scope link noprefixroute
valid_lft forever preferred_lft forever
4: virbr0:
<NO-CARRIER,BROADCAST,MULTICAST,UP>
mtu 1500 qdisc noqueue state DOWN
group default qlen 1000
link/ether 52:54:00:5b:e6:4e brd
ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd
192.168.100.255 scope global virbr0
valid_lft forever preferred_lft forever
5: vnet0:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc noqueue master br0 state
UNKNOWN group default qlen 1000
link/ether fe:00:27:dc:06:7e brd
ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:27ff:fedc:67e/64
scope link
valid_lft forever preferred_lft forever
6: vnet1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc noqueue master br0 state
UNKNOWN group default qlen 1000
link/ether fe:54:00:80:eb:73 brd
ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe80:eb73/64
scope link
valid_lft forever preferred_lft forever/
The key sections (eliminating all my
lease reservations and such) of my
dhcp4.conf look like this:
/{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "br0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 2,
"packet-queue-size": 14
},
"client-classes": [
{
"name": "homeauto"
},
{
"name": "normal",
"test": "not member('homeauto')"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "domain-name",
"code": 15,
"data": "skfaf.servesarcasm.com"
},
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "broadcast-address",
"code": 28,
"data": "192.168.1.255"
},
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "subnet-mask",
"code": 1,
"data": "255.255.254.0"
}
],
"valid-lifetime": 43200,
"renew-timer": 21600,
"rebind-timer": 32400,
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
"dhcp-ddns": {
"enable-updates": false
},
"authoritative": true,
"hooks-libraries": [
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [ {
"this-server-name": "macserver",
"mode": "hot-standby",
"heatbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"sync-timeout": 60000,
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
},
"peers": [
{
"name": "macserver",
"url":
"http://192.168.1.104:8003/";
<http://192.168.1.104:8003/>,
"role": "primary"
},
{
"name": "oldhp",
"url":
"http://192.168.1.110:8003/";
<http://192.168.1.110:8003/>,
"role": "standby"
}
]
} ]
}
}/
//
/],
"shared-networks": [
{
"name": "macnet",
"subnet4": [
{
"id": 1,
"subnet": "192.168.1.0/24",
"pools": [
{
"pool": "192.168.1.124 - 192.168.1.198",
"client-class": "normal"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
}
]
},
{
"id": 2,
"subnet": "192.168.0.0/23",
"pools": [
{
"pool": "192.168.0.150 - 192.168.0.175",
"client-class": "homeauto"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "192.168.1.1"
},
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "192.168.1.1"
}
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}/
I changed my "interface" to "br0"
because my previous setup (exerp
below) stopped working when I started
the br0 network.
/{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "enp34s0" ]/
Changing the interface to "br0" has
had exactly no effect.
I realise that I have missed something
fundamental and I am wasting your
valuable time. However I have been
trying to sort this out for days (in
whatever spare time is available) and
I have acheived nothing. Each time I
start kea-dhcp-server on my main
server it appears in Stork with no
errors, systemd says its running fine
and my HA standby stops providing
dhcp. Unfortunately if I then turn on
a device it simply does not receive an
ip lease. If I turn off DHCP on the
main server then eventually the
standby starts takes over dhcp again
and network functions return to normal
(though this takes a very long time &
sometimes requires a restart of
kea-dhcp4-server on the stanby server,
perhaps another error to fix later).
Even my new VMs receive ips seamlessly
from the standby server.
If you need to see some logs, please
tell me where I can retreive them
because I haven't been able to work
that out either (I think I need to
change my logging parameters in
kea-dhcp4.conf). I used Wireshark to
capture network coms before and after
turning on the main dhcp server but I
then realised that I was too
stupid/ignorant to work out what was
going on from the output. I can
provided the Wireshark output, but it
is a large file (ran it for too long
and filtered it poorly, I think) that
I won't inflict on you unless you wish it.
Please give me some ideas of what I
have to do to troubleshoot/fix this.
Regards
Stuart MacGregor
