Problem with DHCP Static Mappings

[Kallex]

For some reason my DHCP Server on OPNSense doesn't seem to respect the static mappings. Initially I didn't set the "ARP Table Static Entry" and thought that was the case, but the problem persists still:

Interface   IP address   MAC address   
Hostname   Description   Start   End   Status   Lease type
TBNET   10.27.4.101   00:15:5d:00:12:3d
kubehost               static   

TBNET   10.27.4.101   10:d5:61:7e:5c:59
2021/07/17 12:17:48 UTC   2021/07/17 14:17:48 UTC      active

The latter entry is fresh, getting the IP Address of static mapped server, that's not running right now (or hasn't been for a while, thus its lease was expired).

• DHCP Server has "Enable Static ARP" setting un-checked (= disabled).
• ARP Table Static Entry - for each entry is enabled

OPNSense version is following:

OPNsense 21.4.1-amd64
FreeBSD 12.1-RELEASE-p16-HBSD
OpenSSL 1.1.1k 25 Mar 2021

[hloiter]

Is your static ip adress mapping an ip from the dynamic ip adress pool?

[Kallex]

Yes it is. There is UI assistant on leases, that provides button for "add a static mapping for this MAC address", but that didn't seem to reserve the IP.

[Kallex]

Updated to newest Business branch version (21.4.2-amd64) and it still does this:

When different MAC 00:15:5d:00:12:3d has clearly reserved 10.27.4.101 it still offers and leases it out to 00:15:5d:00:12:38. The reserving MAC is offline at the moment.

Log:

2021-08-08T11:54:14   dhcpd[48908]   DHCPACK on 10.27.4.101 to 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:14   dhcpd[48908]   DHCPREQUEST for 10.27.4.101 (10.27.4.1) from 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:14   dhcpd[48908]   DHCPOFFER on 10.27.4.101 to 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:13   dhcpd[48908]   DHCPDISCOVER from 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:52:45   dhcpd[48908]   Server starting service.   

Leases:

TBNET   10.27.4.101   00:15:5d:00:12:38
Microsoft Corporation         2021/08/08 08:54:14 UTC   2021/08/08 10:54:14 UTC      active   

TBNET   10.27.4.101   00:15:5d:00:12:3d
Microsoft Corporation   kubehost               static   

[Patrick M. Hausen]

Yes it is. There is UI assistant on leases, that provides button for "add a static mapping for this MAC address", but that didn't seem to reserve the IP.

Make the range of your dynamic pool smaller and assign static addresses from outside that range. As far as I know that's how isc-dhcpd is supposed to work.

[franco]

Important question that Patrick raised implicitly: is the pool too small to begin with? DHCPD will give out all the leases it is allowed to especially if the static lease is not using it.


Cheers,
Franco

[Kallex]

The pool is 100 addresses, no shortage there.

Also I disagree how static MAC mappings are supposed to work in DHCP pool. There would be no point in having "Add static mapping" functionality in the first place. Assigning static IPs outside of the pool is completely different use-case - that simply separates DHCP from the static address range altogether.

IMO: The problem is quite obvious on the DHCP lease list itself. Why is it having two leases that its fully aware of, for the same address?

[Kallex]

Now after testing this moreover, can reproduce with varying the obvious settings, I think this is simply a bug.

Not opinion based feature or anything, just simply not working .

What's the proper way of reporting bugs? Create an issue in GitHub... to which repository?

[chemlud]

Yes it is. There is UI assistant on leases, that provides button for "add a static mapping for this MAC address", but that didn't seem to reserve the IP.

Not from the dynamic pool. Only if you reserve an IP within your subnet but outside the dynamic pool.

[franco]

Still not sure what the bug is. Raising a ticket raises the question: where? With us or DHCPD?

21.1 changed this:

o dhcp: removed the need for a static IPv4 being outside of the pool (contributed by Gauss23)

The rationale was that DHCPD supports it now as opposed to not doing it before at least if I remember right.

Was this change wrong? Not generally, no.

Does it have limitations? Seems so, yes.

Can we do something about it as OPNsense? Except for going back to the previous behaviour I don't think so.


Cheers,
Franco

[franco]

PS: 100 addresses is small even for a private home network.

[Kallex]

Thank you all for the patience.

I'm sorry - it took me a while to really understand the dynamic pool vs. "same subnet, outside dynamic pool ranges". So the DHCP server will then serve the addresses still outside its dynamic ranges..?

Which makes sense now, when I get what you mean.

My previous experience was with Asus RT-series and Ubiquiti Unifi - series, where there is alike functionality in UI, and where it indeed does reserve the current IP for that MAC address from dynamic pool as well.


I don't insist this being a bug, but the documentation and UI/current behaviour could use some better tooltips. And possibly rechecking if that "prosumer/consumer router" behaviour is indeed as I have experienced it, and if its something to be mirrored on OPNSense as well.

I'll experiment with the proper understanding now... and remove the IPs from dynamic pools (it does make sense that way too, for logical management perspective and all).


About the pool size:

I have several VLAN separated networks, the one where I spotted this issue is IoT specific net, 100 pool is plenty there when there are around 25 logical devices there now - explicitly being added. But I understand the point.

[Kallex]

21.1 changed this:

o dhcp: removed the need for a static IPv4 being outside of the pool (contributed by Gauss23)

But still thinking about this feature improvement; what would be point of this (to allow the static IP be within the pool), except to exactly give the dedicated IP to that MAC address - from the dynamic pool.

This is what I experienced without issues.

The problem was, that because there was no reservation, the address was given elsewhere when the reserved client was offline.

When looking from this perspective, this seems like a bug to me. The MAC/IPs listed within the pool, need of course be reserved to those MACs.

[Patrick M. Hausen]

@kallex You might be correct here but this is how the dhcpd works and nothing OPNsense could change. You would need to file a bug ticket with the isc-dhcpd project to get this fixed.

[Kallex]

@kallex You might be correct here but this is how the dhcpd works and nothing OPNsense could change. You would need to file a bug ticket with the isc-dhcpd project to get this fixed.

Do you mean this certain dhcpd implementation that OPNSense is bound to use?

I mean I can understand that this isc-dhcpd project might be the right place, but I'd like to argue that the feature as-it-is right now, is not working properly.


I mean I Googled around just generic "dhcpd static ip reservations" (just picked few random - seem to follow pattern);

https://serverfault.com/questions/768655/how-dhcpd-handles-static-ips-vs-dhcp-reservations
https://www.itsfullofstars.de/2019/02/assign-a-static-ip-to-dhcp-client/

Both circulate around "can be inside the scope or outside the scope depending the implementation", both also mention leases that dictate which MAC address has which IP. Both also happen to match my previous experience on alike feature on consumer/prosumer hardware (Asus and Ubiquiti Unifi).

Focusing on leases is where I can clearly point the reservation part of the issue: Why in my active leases list I have two different MACs for the same IP - that's quite an anomaly.


Bottom line; the feature as it stands now, as it leads to end-user assume dynamic pool reservation is OK its actually (quite severe) security issue.

The device that "steals" the reserved IP also gets all the firewall rules of the reserved IP device. One main use case for reserving IPs is exactly this - having custom security/firewall rules for them.