Kea DHCP leases incorrectly categorized under "Loopback" interface

[obiwantoby]

Hi everyone,
I'm seeking some insight into an issue I'm experiencing with the Kea DHCP service on my OPNsense setup. After a recent migration to new hardware, I've noticed that several active leases are being categorized under a "Loopback" interface in the "Services: Kea DHCP: Leases DHCPv4" view, rather than their respective VLAN interfaces.

Environment:
OPNsense 26.7 RC2
Service: Kea DHCP
Symptoms:

While devices are receiving IP addresses and network traffic is routing correctly across my VLANs, the GUI lease table consistently shows multiple devices, including those with static reservations grouped under "Loopback."

Configuration Details:
I have verified that the interfaces are correctly assigned and enabled in the GUI, and the physical VLANs are showing as "Up" under Interfaces > Assignments.
However, looking at the generated configuration file (/usr/local/etc/kea/kea-dhcp4.conf), the interfaces array is as follows:

Code Select Expand

"interfaces": [
    "vlan01",
    "vlan02",
    "ixl0"
],


Questions:
Is it normal behavior for leases to appear under "Loopback" in the Kea DHCP GUI when the interface is not explicitly listed in the generated kea-dhcp4.conf?
Are there any known issues regarding the synchronization between the OPNsense GUI interface assignments and the Kea configuration generator?
Any guidance or troubleshooting steps to ensure these leases map correctly to their actual interfaces would be greatly appreciated.

Thanks in advance.

Before my migration, and on the last stable release, leases were sorted by VLAN.

[OPNenthu]

Are these issues possibly related? https://github.com/opnsense/core/issues/10512

I'm only making the connection because of the loopback device.  At least in the linked issue @franco attributes it to a possible OS regression.

Editing myself... I don't think leases have much to do with routes.

[obiwantoby]

Yeah probably not. Though I assume the config.xml would be translated somehow to the kea config. Though I am not entirely sure why it is grouping it this way yet. It is peculiar, but out of box, so maybe a bug, maybe not related here to the release but hard to know.

[Monviech (Cedrik)]

The loopback device might have a network that overlaps with a network of a normal interface.

eg if loopback has 192.168.0.1/16 and your real LAN interface has 192.168.1.1/24 all DHCP leases would probably show as loopback owned.

[franco]

I think something associating actual addresses with loopback in 15.1 is a real thing of unknown proportions. It's definitely not core code doing this.


Cheers,
Franco

[Monviech (Cedrik)]

For KEA the lease script uses ifconfig to assume the interface of a lease. If there are overlaps in the network it will probably show the wrong interface.

https://github.com/opnsense/core/blob/1c2b98a92b1e07dc822a45b47afbf9be1e401fd2/src/opnsense/scripts/kea/get_kea_leases.py#L37-L48

So an "ifconfig" and the raw output of the above script should show whats going on.

[obiwantoby]

ifconfig

Code Select Expand

lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
    ...
    inet 127.0.0.1 netmask 0x0

The netmask for lo0 is 0x0.

Now, look at how that python script matches an IP lease to an interface:

It loops through all system interfaces from ifconfig. Because lo0 has a wildcard netmask of 0.0.0.0 (/0), every single IP address in existence mathematically matches the loopback interface.

Because the script processes lo0 and matches everything to it, it overrides the correct VLAN mappings for vlan01 (GamingVLAN) and vlan02 (IoTVLAN). I think 192.168.2.x (LAN) leases escape this because ixl0 is processed first or has a direct physical match that takes precedence in the sorting, but the VLANs are getting completely swallowed by the loopback's wildcard netmask.

So this is the cause , did 15.1 introduce lo0 0.0.0.0/0 ?

[Monviech (Cedrik)]

Loopback should be 127.0.0.0/8 if I remember correctly, not /0.

Thats really weird, thanks for sharing.

[franco]

# opnsense-patch https://github.com/opnsense/core/commit/6e18d2f5c

[patient0]

Just to confirm, that lo0 has netmask of 0x0 on my RC2, too. A fresh installed VM with FreeBSD 15.1 doas have the regular netmask of 0xff000000. It's already fixed, thanks @franco