DHCP feature request: allow reservations outside of scope

[pricerc]

Currently, when adding a reservation, it must be part of the address range for the scope.

This seems like an unnecessary limitation.

I understand that it needs to be in the same subnet, but OpenWRT (for example) allows the reservation to be any IP.

In my case, I now have Technitium DNS/DHCP servers running on two Raspberry Pi 4's and would like to have non-overlapping DHCP scopes but with shared reservations for some systems (e.g. printer) on my network.

While I'm here. For the user-interface, I think the reservation entries should "lock" the subnet part of the IP address - although I realise that could get tricky if someone is using an 'odd' subnet boundary.

[ShreyasZare]

Thanks for the request. This limitation currently exists since scope selection is done based on the IP address during renewal. Will explore this thing once and see how it can be done.

While I'm here. For the user-interface, I think the reservation entries should "lock" the subnet part of the IP address - although I realise that could get tricky if someone is using an 'odd' subnet boundary.

Can you elaborate this a bit? Do you mean the subnet field in the scope at the top should be locked?

[pricerc]

Can you elaborate this a bit? Do you mean the subnet field in the scope at the top should be locked?

No, I mean the IP address for a reservation should not allow you to even type an invalid address.

When adding reservations, the IP address is a free text field.

So, even though my subnet is, say 10.10.0.0/16, there is nothing to stop me putting in an address of 10.100.2.3.

Ideally, the "10.10." part (the subnet) should be "locked" when I'm adding a new reservations, but I can't think of a good UX for that kind of behaviour. Especially if you want to support classless addressing, where someone could have a 10.10.0.0/20 subnet...

So perhaps it could just be validated and highlighted in javascript at the time of entry, rather than waiting until the admin clicks the 'save' button.

[pricerc]

Will explore this thing once and see how it can be done.

I should note that for my scenario, 'clustering' would be a more convenient scenario - I have two systems that I'd ideally like to have sharing a database.

[ShreyasZare]

So perhaps it could just be validated and highlighted in javascript at the time of entry, rather than waiting until the admin clicks the 'save' button.

This will need to implement the network address validation code in JS which is good to have and can be done later once pending features are implemented.

[ShreyasZare]

Will explore this thing once and see how it can be done.

I should note that for my scenario, 'clustering' would be a more convenient scenario - I have two systems that I'd ideally like to have sharing a database.

Clustering is planned feature. First the clustering support that is planned to be implemented will cover DNS parts only. Once that is settled that DHCPv6 and clustering support for it will be implemented.

[IconicLight]

I would like to add that I'm looking for this feature, in mostly the way described.

For instance I would like to assign a client an IP of 192.168.100.10, however my DHCP scope range is set to 192.168.100.200 to 192.168.100.250.

I'm ok with all octets being enforced except for the last one. I would like to preferably be able to set a DHCP static lease to a client outside of the 192.168.100.200-250 range which should be used by DHCP clients.

I've moved my DHCP from OPNsense to Technitium. OPNsense allows you to set a static lease for any IP on the last octet, would love if Technitium could do this feature as well.

[brokoler]

Until it gets added, there is a workaround.

Workaround: Static DHCP Lease outside DHCP range

1. For the Scope range, enter your full subnet:

2. Exclude the ranges you would not like to serve via DHCP automatically :

3. Add the reserved leases outside the usual DHCP scope, which is part of your defined exclusion range:

Works without any problems for me. Maybe this is useful for someone else.

[christianstrauch]

Here's how I solved what I believe is similar to the OP's problem:

My requirements:

• There shall be enough IPv4 addresses in my local network - I chose a 255.255.252.0 subnet.
• Three different types of devices shall be in three different IP Class C subnets, and in three different local subdomains in DNS (.example.local, iot.example.local, dyn.example.local)
• One of these three different types of devices shall be temporary DHCP leases (e.g., client computers, phones, TVs, ...,) they shall be put into the dyn.example.local domain; static leases for IOT devices (e.g., smart plugs, blinds, ...) shall be put into the iot.example.local domain; well known servers shall be in the example.local domain.

My solution:

• Created three DHCP scopes with "Starting Address" and "Ending Address" defined in the respectively required class C subnets and the 255.255.252.0 subnet mask
• Put the static leases proactively into the iot and servers scope using the devices' MAC addresses
• Checked "Allow Only Reserved Lease Allocations" for the iot and servers scope
• Set the "Offer delay time" to 0 for servers, 50ms IOT devices, and 100ms for the dynamic scope (although I should now be able to set 0 for IOT as well; I had to do this staggering of servers and IOT for migration purposes)
• Set the "Domain name" for the scopes to example.local, iot.example.local, dyn.example.local, respectively

This way, DHCP offers the reserved server leases first, then the reserved IOT leases, then dynamic leases as a fallback.