DHCP static lease reservations
-
-
So, has this been revisited? Clearly the cloud concept wasn't around when this feature was designed. It would be really nice to spin up a cluster of machines, let DHCP hand out an address, and convert those leases to reservations without messing with the range.
In fairness, the previous replies look like an attempt to justify for poor design choices...
-
@thelucasajackson said in DHCP static lease reservations:
let DHCP hand out an address, and convert those leases to reservations without messing with the range.
You mean assigning static lease in the pool, as the initial static leases list is empty, and all device will get an IP from the pool ?
The DHCP server is created, maintained and developed here.
pfSense uses the FreeBSD package based on that project.
Feel free to to contact them. -
Can the necessary dhcpd functionality (for supporting IP-vs-MAC reservations within the dynamic range of DHCP) be considered as supported upstream, based on the feature described here?:
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf#RESERVED%20LEASES
If so, maybe the user knows best whether mixing reserved and free IP addresses in the same range is a good or bad design choice in the particular circumstances at his/her site? There are so many different potential conditions out there, making it questionable for a product like pfSense to be too opinionated on that issue, IMHO. Most other routers handle this without problems, so pfSense seems to be the exception from a usability perspective (i.e. considering comparable router products, rather than *nix implementation details)
/Previously paying pfSense customer
-
@spiking said in DHCP static lease reservations:
Can the necessary dhcpd functionality (for supporting IP-vs-MAC reservations within the dynamic range of DHCP) be considered as supported upstream, based on the feature described here?:
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf#RESERVED%20LEASES
If so, maybe the user knows best whether mixing reserved and free IP addresses in the same range is a good or bad design choice in the particular circumstances at his/her site? There are so many different potential conditions out there, making it questionable for a product like pfSense to be too opinionated on that issue, IMHO. Most other routers handle this without problems, so pfSense seems to be the exception from a usability perspective (i.e. considering comparable router products, rather than *nix implementation details)
/Previously paying pfSense customer
IMHO, pfSense respects/implements https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf#RESERVED%20LEASES
What the GUI doesn't offer, is https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf#ADDRESS%20POOLS
This means : a pool with unknown DHCP clients, and a pool with known clients (aka : deny unknown-clients; is present in that pool).But why declaring a pool with known clients (aka : DCHP-static-MAC) ?
Say, your network is 192.168.1.0/24, pfSense being 192.168.1 - this is the default.
What about declaring a pool in pfSense like 192.168.200 -> 192.168.1.254. This 'dynamic' pool will get used for unknown LAN DHCP clients.
Logically, the range 192.168.1.2-> 192.168.1.199 is for your static IP setups and DCHP-static-MAC leases.
I don't see the need to a a separate pool for them ... just take whatever is outside the 'dynamic' pool.
(network riange) - (dynamic pool range) = what's for you to be assigned to devices with static IP settings - and DCHP-static-MAC leases. easy, no ? -
@gertjan I think what we’re all looking for is the functionality to select a device that has a DHCP address and tell PFSense to convert it to a reservation using the already assigned address.
Again, the way PFSense forces a users to choose a new IP address to be assigned to a new reservation is opinionated and bad design. Nobody wants to create a reservation and afterwards restart networking on the device to pull the new IP - it’s not even feasible in certain implementations.
-
@thelucasajackson said in DHCP static lease reservations:
to a new reservation is opinionated and bad design
Says who - you? Well oh my goodness - the devs should drop everything and get right on that fixing that because billy bob off the internet doesn't like it and thinks its bad design ;)
You don't create reservations inside your pool, not how it works.. But because you clearly are more versed in how it should be done.. Sure everyone is awaiting your code submission ;)
A pool is a range of IPs that can be allocated to dhcp clients.. If your saying client X always gets IP A, and no other client can have it.. it is no longer in the pool.. So sure you can create pool of ips before that, and a pool after that contain the IP ranges you still want to be able to dynamically assigned. So it seems that the IP have reserved for client X is inside your pool/range of IPs - but it is not..
Doing such a thing is bad design, and horrible idea because is makes for more complex configuration.. Create a pool of IPs you want to use lets say .50-250 out of your /24.. IPs that you want to hand out to specific devices via reservations can be .1-49 or .251-254... Clearly you can adjust as you see fit.
Because you want to click a button to assign some client that got .56 to always get .56 would mean you create 2 pools .50-55 and .57-250... When the user clicks the button.. But if you want to code that up.. Sure they would be more than happy for your code submission..
Not all that bad if you have 1 reservation.. But what happens when you have 22 reservations and none of them are adjacent IPs.. How many different pools do you have now?
But yeah that seems way better idea then just not letting reservations be created from inside the current pool space..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 25.07.1 | Lab VMs 2.8, 25.07.1 -
@thelucasajackson said in DHCP static lease reservations:
the way PFSense forces a users to choose a new IP address to be assigned to a new reservation is opinionated and bad design
This makes me wonder.
I have this impression you mean / say something that I don't understand.Option 1 : you chose nothing. Just hook up the device, and it will have an IP from the pool - the pool you have defined up front.
Option 2 : you want this device to have always the same IP, an IP you choose. So, you inform the DHCP server that that device, identified by 'this MAC' always should get 'this IP'.
Done. What is the bad design here ? You want something. You have to do something to obtain it.@thelucasajackson said in DHCP static lease reservations:
Nobody wants to create a reservation and afterwards restart networking on the device to pull the new IP
That why we should all do this( ;) ) : take the device, and locate the MAC address.
It's a sticker, a screen, on the box, on the network card, in the BIOS ....
Use this MAC addresses, and a chose an IP and host name an description and what ever, and make a MAC based lease.
Now, only now, hook up your device.
The IP will be good right away, nothing to restart.Btw : Now, be modern, and do a DHCP6 static lease.. which probably isn't based on the MAC, but made from variables generated and known at boot time. It's called a DUID ..... Your back to : hook up the device to your LAN, have it pulling a IPv6, now you create a IPv6 static lease with the DUID. With IPv6 you can't prepare anything up front.
-
The desired option here is option 3: You choose nothing, hook up the device, and it gets an IP address from the pool. Then you want it to be reserved for whatever reason, so you click a button that reserves that IP address for that MAC address. The address doesn't change, and nothing needs to be done to the endpoint (like rebooting or disconnecting/reconnecting the connection).
The IP address management system that is in use at the large enterprise company I work for does just this. We set aside a small range for manually configured static address devices, but when a printer is added, our facilities vendor connects it to the network and turns it on. It gets a DHCP address. Then the server team that manages the print queues clicks a button and reserves that address for that printer. Or if we have a user or server that needs a firewall exception, the network security team clicks a button to reserve that address for that device, and the user has to do nothing. This is for an enterprise with over 18,000 user endpoints, thousands of servers, and hundreds of printers at hundreds of locations worldwide.
Personally, I have no preference in this. My home network, where I use pfSense, is small enough that I can manage things the way it is now. But I definitely see why what is being requested here is desired. It may not be the "cleanest" way to do things, but it's quick and easy, for both the network admin and the user, and that's what is usually important in large enterprise.
-
@johnpoz I had a change submitted on my behalf a number of years ago for a different feature I wanted.. In this case, I ended up going with a different DHCP server. Good design isn't judged by developers or standards bodies - it's determined by the market. Every DHCP server I've used works exactly as stated; where you can convert a DHCP lease into a reservation in one click without the need to give it a different IP address than has already been assigned (see the post from @virgiliomi). The market has spoken.
@Gertjan Option 3 (what @virgiliomi) described is exactly what I'm talking about. Very well stated.
You cannot always rely on having the MAC address printed somewhere on the device or box it came in to create reservations prior to racking and stacking hardware (especially true with iot devices). In my case, I wanted to have the devices grab a DHCP lease and use it in perpetuity - hence the need for a reservation after getting a DHCP lease.
I'm using the entire subnet for my project, and I'm relying on my DHCP for IP allocation and management. I don't care what IP devices get, because I'll create DNS records pointing to them.
-
@thelucasajackson said in DHCP static lease reservations:
@Gertjan Option 3 (what @virgiliomi) described is exactly what I'm talking about. Very well stated.
Why not.
Nothing against option 3.
Normally, I don't even bother with(like rebooting or disconnecting/reconnecting the connection).
as leases get renewed in a couple of hours / a day maybe.
If I need an urgent access to the device, I just reach to the first 'hardware' point available, the master switch nearby pfsense for ewample, and rip our the device's cable a couple of seconds. That should take care of things ;)
Didn't I tell somewhere a couple of days ago that https://www.isc.org/dhcp/ should accept feature requests ? They are the authors of dhcpd used by pfSense.
The FreeBSD dhcpd package that pfSense is using comes from them. I don't think Netgate is going to rewrite the source, dhcpd server, or applying massive patches .... It should be implemented upstream.@virgiliomi said in DHCP static lease reservations:
This is for an enterprise with over 18,000 user endpoints, thousands of servers, and hundreds of printers at hundreds of locations worldwide.
These kind of big organisations do have complete inventories that do mention MAC addresses : a simple copy and past from this list will do for an initial setup.
Although, using pfSense managing xx thousands of DHCP leases...... I would ditch the concept of using a router/firewall with a GUI ....
A dedicated DHCP server, and chose carefully now ;) -
@gertjan I don't think the original ask that started this thread was to start a holy war over how to properly create DHCP reservations.
It's basic functionality that Microsoft DHCP, InfoBlox, Ubiquiti Unifi, Synology, Netgear, Linksys, etc... offer. Heck, entire systems such as Canonical MAAS require this concept to work properly (system PXE boots > is given IP > same IP is made permanent). I think the community is asking the same of PFSense. If PFSense doesn't want to implement, then we'll go elsewhere for our DHCP needs. I'm not sure if it's so much the upstream as it is a check in the UI that's preventing existing IP addresses to be used for a reservation (I could be wrong).
-
@gertjan
Thank you for your prompt response! I will try to describe an example from reality, to clarify what I mean.The site has many hundreds of computers/devices are active. Due to historic reasons, some ~100 of these devices have reserved IP-addresses, provided by the previous router (not pfSense) over DHCP, through a standard MAC->IP mapping table in the web GUI.
The reserved IP addresses are pretty much randomly scattered all over the place, making multiple ranges in pfSense problematic. Changing the reserved IP addresses is not feasible, since that would involve too much work and lead to risks not deemed acceptable. From an academic/pure networking point of view, I fully agree keeping the dynamic IP address range separate from the reserved range is cleaner in some sense, but in reality it is not important enough for existing sites, and not even desirable/possible in all cases. Anyways, regardless of the reasons, re-assigning the IP addresses just isn't on the table.
This leaves the option not to use pfSense at all, which is unfortunate since it has many other strengths IMO, or to create an excessive amount of hard-coded additional ranges, to cover as many non-reserved IP addresses as possible. I was a paying gold member, happily promoting pfSense, until I realized pfSense has this fundamental problem. I just cannot help thinking that this rather unfortunate show-stopper for pfSense is a somewhat unnecessary waste of an otherwise excellent product. But maybe it is just too narrow in its intended scope, which of course is up to NetGate to decide. It is just a bit uncommon for a business to not want paying customers due to such reasons as insisting on purity or nothing.
-
Just to point out/restate the usage case, Windows Server DHCP reservations are within the DHCP range. We have used this many times to assign a reservation to a PC or printer without having to reconnect PCs to the new printer IP or interrupt the user (close open files, or reboot or whatever). It is less intrusive to the user.
The different points of view here I think are "keep things working as they are already" vs "when one sets up the network, plan for this in advance" which are both valid points.
Mostly it's been a non-issue for us since for any Windows domain network we use their DHCP.
