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

[obiwantoby]

Looks great with the latest release. Oddly, I had to power cycle the device, which is odd. Not likely a scenario in which folks would get this patch when updating though.

[franco]

The loopback initialization is only called on boot and when using console option 13. So the patch apply works, but not easily called.

Hotfix is already out and upgrade paths have been adjusted. Release notes follow later tonight. That will hopefully give more people the opportunity to test.  :)


Cheers,
Franco

[readr00m]

I use DNSmasq and it is fixed for me too, very quick! In my case I had, in error, added loopback in my vlan alias, so firewall rules based on that alias either allowed absolutely every IP, or blocked every single IP. Other than that no issues for me so far.