A few OPNsense releases ago, I migrated from isc-dhcp4 to kea. This mostly works, however there is one nagging issue: Every once in a while, after a reboot, kea appears not to be running. In the logs, the message 'no interface configured to listen to DHCP traffic' is shown. After a manual restart all is well.
The error is not readily visible on the OPNsense dashboard, as kea appears to be running, it just isn't doing anything.
As this doesn't always happen, it seems to be a timing-sensitive issue. Are other people seeing this?
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface igb0 is not running
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:35:01 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcp4.0x834bcb000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-07-11T15:34:57 WARN [kea-dhcp4.dhcpsrv.0x834bcb000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
Not sure but:
> failed to open socket: the interface igb0 is not running
The interface wasn't in UP state when the Kea server started running which then ended up deciding it was giving up on the interface (a bit odd).
Cheers,
Franco
Now that I think of it: the LAN interface kea is running on has a fixed IPv4 address which is inherently stable, but it uses 'track interface' for IPv6.
Can this process of assigning an IPv6 address momentarily cause some kind of interface flapping, disrupting IPv4 service, which causes kea to quit?
My guess would rather be on Suricata IPS mode or Zenarmor binding to the interface causing it to flap.
But it's worth a try to switch off tracking WAN temporarily as an added data point.
Cheers,
Franco