Problem with DHCP Static Mappings

[Kallex]

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.

[franco]

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

[Kallex]

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.

[chemlud]

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)...

[Patrick M. Hausen]

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.

[Kallex]

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.

[Kallex]

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.

[franco]

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

[Kallex]

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.

[Kallex]

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.

[beyondzero]

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.

[marjohn56]

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.

[beyondzero]

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.

[marjohn56]

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.

[Vasco]

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