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 typeTBNET 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
Is your static ip adress mapping an ip from the dynamic ip adress pool?
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.
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
Quote from: Kallex on July 26, 2021, 02:14:22 PM
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.
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
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?
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?
Quote from: Kallex on July 26, 2021, 02:14:22 PM
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.
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
PS: 100 addresses is small even for a private home network.
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.
Quote from: franco on August 13, 2021, 01:44:29 PM
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.
@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.
Quote from: pmhausen on August 16, 2021, 03:27:08 PM
@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.
To continue a bit more for the
security implication of this. When the "reserved IP device" comes online, whichever IP it might acquire:
- Either it collides with existing IP - breaking the network for those devices
- Or it gets a new one and again, is not within its firewall-ruleset bound to its "reserved" IP
So either-or its quite a problem.
Franky, I don't understand the fuzz without having laid out the proper research(1). What are we doing wrong here? Which line of code can we add to fix what you think is wrong? Are you sure the energy you put into trying to argue something here is going to resolve the unspecified problem(1)?
Cheers,
Franco
I'm not sure what you mean by research not done..? If my examples/tests above lack something, I can revisit and describe them better.
Simply put; I think you should either:
Disable the feature that allows to select static IP within the dynamic pool
- Which I understood, that you're likely not going to - and I agree here, its a desirable feature to have
or
Ensure that the reserved IPs are then not assigned to any other MAC
- If you can't guarantee this, you're opening a can-o-worms, including the firewall-security issue
Right now the current UI/documentation doesn't in any way indicate, that "You shouldn't try to reserve from within a pool".
The overlapping or just "stealing the reserved IP" also compromise firewall rules.
I can myself solve my own issue now that I know the behavior, by simply moving my needs to outside dynamic pool.
But I think you might want to revisit that part of firewall rule compromise, because I don't think its a small issue.
Quote from: Kallex on August 16, 2021, 04:51:44 PM
To continue a bit more for the security implication of this. When the "reserved IP device" comes online, whichever IP it might acquire:
- Either it collides with existing IP - breaking the network for those devices
- Or it gets a new one and again, is not within its firewall-ruleset bound to its "reserved" IP
So either-or its quite a problem.
Or it gets no IP with "no free leases"? Havve you tried?
For networks with specific rules for dedicated/reserved IPs based on MAC I don't hand out any IPs to unknown MACs (checkbox for DHCP). End of story (I guess)...
Other than that, don't build firewall rules based on IP address. They can be spoofed.
Design policies around zones, i.e. interfaces, and put all devices sharing a policy into the same zone. With VLANs you can practically have as many interfaces as you like.
Quote from: chemlud on August 16, 2021, 05:21:49 PM
Quote from: Kallex on August 16, 2021, 04:51:44 PM
To continue a bit more for the security implication of this. When the "reserved IP device" comes online, whichever IP it might acquire:
- Either it collides with existing IP - breaking the network for those devices
- Or it gets a new one and again, is not within its firewall-ruleset bound to its "reserved" IP
So either-or its quite a problem.
Or it gets no IP with "no free leases"? Havve you tried?
For networks with specific rules for dedicated/reserved IPs based on MAC I don't hand out any IPs to unknown MACs (checkbox for DHCP). End of story (I guess)...
Thanks, I tried to bee too clever here. I'll do the testing and report back to conclude and not left this hanging.
I tested it.
The DHCP gives the same IP for both the devices. Ping "almost works", its actually interesting behavior.
So the "reserved IP" is still handed to the device that it was initially kind of reserved for.
It might still be a sort of misconception at play here. So as long as the persistent lease database file carries the old lease it dynamically gave out before you added a static lease for the same IP it might just do what it was configured to do: give out the IP to both systems at will.
From a maintenance perspective have you tried to delete the old dynamic lease first from the leases status page?
Cheers,
Franco
That would make sense. Let me try that.
I also now understand what you mean by dhcpd being the ISC version. I tried to dig into their docs or limitations on this, it seems somewhere recognized "issue", but not so clearly that this kind of issue might explain it.
Didn't seem to help.
I removed the static entry and allowed DHCP to serve it dynamically. Then I turned off the client (let the lease go offline), restarted the DHCP server (to allow it be removed) - and removed the lease.
Then configured the Static entry for different MAC (my other VM) with that IP and started back the "wrong MAC" system, it still got the same lease, that's already been reserved for static use.
In my initial discovery, I had the original server long-running (months) and then turned it off for maintenance... and while adding new devices to IoT network, noticed them getting the server's IP. So there wasn't any dynamic leases competing with static then.
I try to see what way I can dig the system's dhcp.conf etc myself to see if I spot something.
I know this thread is old but I am so glad I found it. I was having the exact same issue/confusion. In my 25+ years of working with dhcpd (big-iron UNIX and Linux) I have never encountered an implementation that worked this way of 1) creating IP conflicts by giving out the same address despite a reservation and 2) giving out addresses outside of the pool. To some degree this is just confusion over terminology, perhaps because I come from working with dhcpd from earlier days but I interpret these terms to mean:
- static - addresses configured on a device manually and not using dhcp
- pool - range of addresses which dhcpd can select from
- reservation - an address within the pool that will only ever be given to one and only one MAC address
I am sure we are not the only two people who run into this issue. May I humbly suggest to the maintainers that for clarity the embedded help for DHCP service should include:
- Services/DHCPv4/[interface] "Range": the pool of addresses from which DHCP will select addresses. To avoid address conflicts, there should be no static assignments or reservations within the pool(s).
- Services/DHCPv4/[interface]/Static DHCP Mapping "IP Address":
If an IPv4 address is entered, the address must be within the interface subnet.
To avoid IP address conflicts, do not enter an IPv4 address that is within the pool(s).
If no IPv4 address is given, one will be dynamically allocated from the pool.
The documentation at https://docs.opnsense.org/ should also make clear how this DHCP implementation operates: The DHCP server will not respect reservations within the pool, but it can give out addresses outside of the pool; therefor reservation addresses should be outside the pool to avoid potential address conflicts.
I've been running ISC dhcpd for many years on the *senses I have a mix of dynamic and static addresses set up, never ever had a problem. Simple rule, always have the statics outside the pool range then there's no problem. As Franco said - having a static address inside the pool is fine, and dhcpd will give out that address providing nothing else is using it. It merely says if this device comes online give it this address; it does not say don't give this addess to any other device. So all my pool is 100 to 199. Switches etc live above 240, servers live below 20. Misc. devices I want as static 21 to 99, printers etc. This is also repeated accross VLANs.
As I said, never had an issue.
I am sorry but that is not entirely true. The opnsense dhcpd caused IP conflicts by giving out addresses that were already in use as reservations. That feels like a bug but if you are calling that expected behavior, we can agree to disagree. But even if you think dhcpd giving out reserved addresses to additional hosts and causing conflicts is a user error (because user configured a reservation from within the pool) it would improve user experience by making that clear in the help and documentation.
[edit]
Just to be clear, you are not having issues because you already know the "simple rule." Now that I do too I no longer have IP address conflicts. But since this rule is not intuitive to everyone, and I speak as someone with 25+ years IP networking experience and who has designed large-scale global networks, it would be kind to make it explicit in the online embedded help and the manual. Because opnsense will give out an address that is reserved to a random host, and then give it out a second time when the reservation-host does its DHCPREQ, causing a conflict.
I think it was last year when the change was made to allow static reservations within the pool. At the time I thought it was a bad idea, but like you I am just a user. It really depends on the OS dhcpd server being used. However, even if I was using Linux DHCPd, which does allow such use, I would still arrange the system with statics outside the pool. You can always go to Github and issue an update to the docs.
Just to add to the discussion, I'm having a similar but different problem. I migrated to opnsense recently so I'm new with it but I'm experiencing a weird issue. I'm trying the combined use of opnsense and pihole so decided to add another pihole in a sbc I had stored somewhere. Now comes the weird part, it was assigned a dynamic IP but I changed it to a static one outside my dynamic pool. Now I have 2 IPs for the same device (they don't appear both in leases) and I can ssh using any of the IPs. Also the pihole management page can be reached with both IPs. I tried to erase the dynamic IP in some places like "/var/dhcpd/var/db/dhcpd.leases" but it always comes back. I also tried to remove the static IP but the device still gets that IP even after reboot as I can reach it with through it. Probably because of this, if I set it as my only pihole it doesn't receive any hits and is bypassed.
I don't know what else to do (the sbc is running ubuntu 18.04).
Sent from my Redmi Note 8 using Tapatalk
Is it possible to add a UI element to have the option of forcing the previous behavior? IIRC, prior to 21.1 - if I tried to add a static mapping that was inside the designated pool ranges, I would get a warning that I couldn't do so.. Am I wrong here? Apparently, I missed the "dhcp: removed the need for a static IPv4 being outside of the pool (contributed by Gauss23)" release note from back then -- and I have assigned MAC address to IPs in my pool range -- only to discover that other devices were grabbing reserved IPs when the original mapped devices were powered off.
I'm not even sure what the rationale was of removing this requirement if the underlying DHCP service didn't actually reserve it.. Now I'm in the process of remapping my static maps and setting up new pool ranges -- and in the future reminding myself that I have to make sure myself that I dont statically map in those pool ranges.
Thanks