I have a reservation set and it's giving it out to the assigned host but it's also being given out to regular dhcp clients. Any idea what's going on? Thanks all
Hi,
just don't use ip for reservations from the dynamic range. This can lead to such effects.
KH
Quote from: KHE on October 28, 2021, 02:11:57 PM
Hi,
just don't use ip for reservations from the dynamic range. This can lead to such effects.
KH
If it does I would consider this a bug. I've not seen this behavior in my environment and I have reservations within my dynamic range. The DHCP server should consider reservations as active leases and not reissue those IPs to other mac addresses, regardless if they are in the current dynamic range or not.
^ +1
This is the whole purpose of reservations: static assignment of DHCP leases.
dhcpd should never hand out a reserved lease to any MAC address other than the one specified in the reservation.
This should be considered a serious security bug.
IMHO, running a DHCP server on a perimeter firewall is also poor security practice.
If you consider this a serious flaw then feel free to file a bug report with the ISC. There is nothing the OPNSense project can change here. The DHCP server is a 3rd party product. It's been behaving like this for decades. Simply define a limited dynamic range and put fixed assignments outside.
Quote from: pmhausen on October 29, 2021, 04:33:57 PM
If you consider this a serious flaw then feel free to file a bug report with the ISC. There is nothing the OPNSense project can change here. The DHCP server is a 3rd party product. It's been behaving like this for decades. Simply define a limited dynamic range and put fixed assignments outside.
"It's been behaving like this for decades." is a pet peeve of mine. Last place I worked (IT) this was my managers excuse to a lot of the problems there. It makes solving problems near impossible with that ideology. Because something has been broken for a long time doesn't make it any less of an issue. Your workaround is valid, but it's just that, a workaround.
Crikey. Did I light a fire...? :o
I believe the standard response has always been to check your config as the leasing of out-of-pool addresses is for tuning (reservations are not checked). IIRC, configuring dhcpd to use global reservations excludes the possibility of using in-subnet reservations where the default reservation-mode is to permit both in-pool and out-of-pool reservations.
As such, this security issue is potentially solvable in the way the configuration file is built. It could also be handled in GUI validation. Either way, the current OPNsense dhcpd reservation implementation leads to a potential security vulnerability.
As such, I disagree with the assertion that there is nothing the OPNsense project can change here.
Having said that, I don't have time to work on it myself. It also doesn't affect me because I don't use the DHCP server on OPNsense.
I agree that the OPNsense UI could prevent assigning in-range addresses statically. As for the behaviour itself that's definitely up to the ISC to fix.
https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf#IP%20ADDRESS%20CONFLICT%20PREVENTION
QuoteRESERVED LEASES
It's often useful to allocate a single address to a single client, in approximate perpetuity. Host statements with fixed-address clauses exist to a certain extent to serve this purpose, but because host statements are intended to approximate ´static configuration´, they suffer from not being referenced in a littany of other Server Services, such as dynamic DNS, failover, ´on events´ and so forth.
If a standard dynamic lease, as from any range statement, is marked ´reserved´, then the server will only allocate this lease to the client it is identified by (be that by client identifier or hardware address).
In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client is bound to it, expires, or is released, and any events or services that would normally be supplied during these events are processed normally, as with any other dynamic lease. The only difference is that failover servers treat reserved leases as special when they enter the FREE or BACKUP states - each server applies the lease into the state it may allocate from - and the leases are not placed on the queue for allocation to other clients. Instead they may only be ´found´ by client identity. The result is that the lease is only offered to the returning client.
Care should probably be taken to ensure that the client only has one lease within a given subnet that it is identified by.
Leases may be set ´reserved´ either through OMAPI, or through the ´infinite-is-reserved´ configuration option (if this is applicable to your environment and mixture of clients).
It should also be noted that leases marked ´reserved´ are effectively treated the same as leases marked ´bootp´.
"If a standard dynamic lease, as from any range statement, is marked ´reserved´, then the server will only allocate this lease to the client it is identified by (be that by client identifier or hardware address)." doesn't look like how this works is by design at least according to documentation.
I'm haven't experienced this issue before, so I'm not sure I'm in a place to submit a bug report. But that can be done here. https://gitlab.isc.org/isc-projects/dhcp/-/issues
I believe my comments above, quoted here, are more applicable to Kea DHCP (the ISC's long-term replacement).
QuoteI believe the standard response has always been to check your config as the leasing of out-of-pool addresses is for tuning (reservations are not checked). IIRC, configuring dhcpd to use global reservations excludes the possibility of using in-subnet reservations where the default reservation-mode is to permit both in-pool and out-of-pool reservations.
The main two advantages of using in-pool or in-range assignments are that you don't have to effectively manage two separate pools (one static and one dynamic) and also that dynamic leases can be reserved, i.e. made static, without needing to reassign an address from the static pool.
I presume OPNsense will move to Kea eventually per the ISC roadmap; I imagine the RESTful API could integrate well with MVC. I think Kea does a better job of handling all this and other issues too.
I do however remember, in days long since passed (in those decades that @pmhausen mentioned), that the ISC DHCP usually required an entry in the dhcpd.leases file too. IIRC, the required statements were
binding state active and
reserved (plus
hardware), e.g.:
lease 10.0.0.1 {
binding state active;
reserved;
hardware ethernet 01:23:45:67:89:ab;
}I think sometimes we also added
"end never" when using the
"infinite-is-reserved" global config statement.
Maybe a dev can confirm if OPNsense does this...