Hello,
I have a question regarding what DNS servers are assigned to IP addresses that are statically assigned within a DHCPv4 pool.
I have an active DHCPv4 pool on my OPNsense firewall. Within that, I have custom DNS servers defined in the main DHCP page for that VLAN/subnet that are not the interface IP (for example, using 8.8.8.8 or 1.1.1.1). When creating a static IP within this pool, do I also need to define the same custom DNS servers that are referenced on the main page of the DHCP pool? I want to make sure the statically assigned IPs within the DHCP pool do not receive the interface IP as the DNS server.
Thanks.
I'm a bit unclear as to what you're saying so let me try and add some examples.
You have an interface at 192.168.1.1 and your DHCP range is configured for 192.168.1.50 to 192.168.1.100.
Are you attempting to set static leases inside the pool such as 192.168.1.75? If so, don't do that. It causes all kinds of problems.
If you are setting static leases outside the pool such as 192.168.1.125 then they will get the same DNS servers as the pool would. If you don't want this to happen then you can define the DNS servers for each client under the static lease settings.
Gotcha. I thought problems with setting static IPs within the pool had been fixed a little while back? The static assignments I have are for the most part all within active DHCP pools (I have hundreds of static IPs across multiple VLANs). What problems would I run into with this?
But yea, my main question was are those devices that are statically assigned (within a DHCP pool range that contains custom DNS servers) going to receive the same DNS servers when the static IP assignment has a blank DNS server, or are they going to receive the interface IP as the DNS server since nothing is defined in the static IP assignment for DNS.
You are going to run into duplicate leases. Static assignment must be outside the dynamic pool. That's a feature of ISC-DHCPD.
The DNS servers are taken from the pool configuration if you don't add any to a particular static host. All options are - should you have set any.
So what happens when DHCP send out a lease to a client and then I click the button under the leases page to statically set it? Does that option just not work properly?
So regardless of static IP being in or outside of the DHCP range, the DNS settings (when left blank under the IP static assignment) should default the DNS settings within the DHCP settings for that subnet?
Quote from: starfer on November 28, 2023, 06:58:41 PM
So what happens when DHCP send out a lease to a client and then I click the button under the leases page to statically set it? Does that option just not work properly?
That works, but it will happily hand out that address again to a different client, because it's in the dynamic pool. Just don't do it. The "
- " option is there you can quickly get to the menu to add a static entry but you must change the IP address to something outside the dynamic range. Documented behaviour of the DHCP server, not going to change.
It's deprecated, any to be replaced, anyway. Possibly Kea will behave differently.
Quote from: starfer on November 28, 2023, 06:58:41 PM
So regardless of static IP being in or outside of the DHCP range, the DNS settings (when left blank under the IP static assignment) should default the DNS settings within the DHCP settings for that subnet?
That's what I wrote, yes.
HTH,
Patrick
Thanks. And what about "additional pools". If I have to configure those to avoid device I want statically assigned, will those need the custom DNS servers configured in there or will the main DHCP page be referenced?
Options like DNS servers are
Global > Subnet > Pool > Host
Everything that is not explicitly specified is inherited from the next higher layer.
Thanks for the info!
Just to clarify. I am referring to DHCP Static Mappings within OPNsense.
These need to be outside of the DHCP pool range in order to not be taken by something else?
Quote from: starfer on November 29, 2023, 09:31:02 PM
Just to clarify. I am referring to DHCP Static Mappings within OPNsense.
These need to be outside of the DHCP pool range in order to not be taken by something else?
Ye-esss ...
In ISC-DHCP static assignments must be outside the dynamic range.
So the point of these DHCP reservations is for outside of the active DHCP scope only? I haven't had any issue with collisions on other firewalls in the past by using reservations within an active scope. Is this an OPNsense specific issue?
It is not an issue it is a property of the DHCP server that is used in OPNsense: ISC-DHCP. Other systems might use other DHCP implementations. Like e.g. Fritzbox. No idea what that uses internally but obviously not ISC-DHCP.
Gotcha, just seems like an odd concept to me. I would have figured DHCP static mapping implies that it is a reserved IP within a DHCP scope.
Just a thought, but if a static mapping needs to be out of the DHCP range to function properly then how would you even provide "DHCP" to that host your are assigning in "DHCP static mapping" that is outside the range of an active DHCP pool? Is the recommended method typically letting devices pickup DHCP then statically mapping it to something outside the range?
I think the name DHCP static mappings is just a bit confusing because "DHCP" is in the name. If the static mapping isn't in a DHCP pool then why is DHCP even in the name?
There are no "pools" on that level in ISC-DHCP. What you name a "pool" is in fact a subnet that dhcpd serves. Within that subnet you have some hosts with static assignments and a range - which says "if you don't have a static assignment for this MAC address then just pick a free one from this range."
You might have servers with real static configuration (not "dhcp static") and you want to make sure there's addresses that are not handed out by DHCP.
You can omit the dynamic range. Then only hosts with a static assignment will be served. That's the "Deny unknown clients" setting in the OPNsense UI.
What are we talking about? I really don't get how we can go over a dozen posts about such a simple concept.
You have a subnet: 192.168.1.0/24
You have a pool/range of addresses for dynamic DHCP clients, e.g. 192.168.1.100-255
You definitely don't want dhcpd to serve addresses from the entire subnet, because 192.168.1.1 is your firewall ...
dhcpd does not monitor what is active on your network. It doesn't know if the configured default gateway or DNS server make any sense. It receives requests and hands out leases and options. It maintains a database of what it already handed out and how long it's valid. But it doesn't have a clue about your actual network structure.
So let's assume you have an overlap in your range and some static assignment.
A request from an unknown client comes in and by accident that also statically assigned address is the next in the list. So the client is served that and a lease put into the database.
Next you power on your statically assigned client. Hey, I know that MAC address, no need to go for the dynamic range and the database - here you go, sir.
Boom!
This is a straightforward reliable implementation with the documented property that you as the operator are supposed to avoid conflicts via correct configuration. A lot of early Internet era building software works that way. You can shoot yourself in the foot - your own fault if you do.
This particular product is 24 years old!
I understand what you are saying. I am just ranting a bit and noting that the terminology is confusing. It is just not super clear based on the naming being "DHCP static mappings". Based on the naming, I would have assumed that setting a specific MAC to an IP address (even within an active range) would make it so that the firewall will not hand out that IP via DHCP unless it is to the MAC address you have defined for that IP address. However, it seems that is not the case and that is good to know.
I understand that it's a reasonably expected feature of some software in 2023 to handle edge cases like this in a graceful manner.
The problem is that the underlying implementation is of the old-fashioned "garbage in - garbage out" kind. It's your responsibility as an operator to ensure a consistent configuration.
OPNsense - and I am by no means belittling the effort of Franco, Ad and colleagues - is technically "just" a UI on top of a big bag of completely unrelated open source projects. So to enforce what seems to be a problem in the UI without the bottom layer even recognising there is a problem would of course be nice, but think of the effort that would take and how many more urgent if not problems then calls for features they have on their desk.
So if at all this could be a call for better documentation. I just checked the docs and it seems static assignments are not mentioned at all, at least not in the main DHCPv4 section.
Then again they (the developers) are in the midst of replacing ISC-DHCP with ISC-Kea. So I would not even expect that. Writing documentation that is obsolete in about half a year is even less fun than writing documentation. ;)
Kind regards,
Patrick
Gotcha, appreciate the help and info.