DHCP - Setting "Gateway" to "None" On a Specific Device Does Not Work #6343
Comments
|
Hmm, I'm not convinced about the "requirement" here and the "fix". The none was introduced in #4843 but it just mimics what empty selection does... DHCPd will likely still inherit from the pool setting so you can't unset a previously set gateway anyway... |
|
PS: It would be nice to have a link to the forum post in the ticket as well... |
|
https://forum.opnsense.org/index.php?topic=32319.new;topicseen#new
If that's all their "fix" did, then they missed the point of that previous GitHub ticket. If there is no "none" functionality present, then it should not be in the description. It says the exact same thing as the description of "gateway" under the DHCP interface context. I don't know why it wouldn't work the way the description states, though - I would expect the fields under the per-device context to accept any input as the per-interface context. |
I really don’t agree with this. |
"A DHCPv4 service on an interface allows setting 'gateway=none' globally. When creating a static DHCP assignment for a single host/ip/mac, under gateway overrides for that host 'gateway=none' throws an error. This is seen as unexpected, I should be able to override this one host's gateway setting that may be global. "none" works when set at interface level - therefore an override should be possible at host level." Quote from previous ticket. They say the functionality of "gateway=none" works as expected "globally" (in the Interface context) - for anyone that reads the "Gateway" description, them tests it, it is clear that this does exactly what it says - it does not assign a "gateway" to DHCP clients. They then say that this does not work on a per-device context. I don't know how much more clearly they could have stated it. For someone to then just change the description to say it will do exactly what is done at an interface context, then allow it to just ignore the setting instead of doing what the description very clearly says, they obviously missed the point. Though I don't understand the code well enough to know whether that is what the change did. For all I know, they could have fixed it, then it been broken on a subsequent update. EDIT: I just went and looked back at the changes made in context. I believe you are correct that they just disabled the error without changing any real behavior. They did just miss the point of the ticket. |
|
Honestly, just let me know what configuration in dhcpd.conf you want vs. what you currently get. I suspect there is a problem in the lease info given out to the client containing a router and you want to get rid of it, but I am unsure you understand what you are asking. I'll quote for emphasis:
|
Let me try explaining it another way... Just to be clear, in case I wasn't, when I or the previous ticket are saying "none," we aren't meaning that the field should be left blank - we are referring to a string of "none" (without quotes) being entered into the "Gateway" address. This should result in the DHCP response being sent by OPNSense omitting the existence of the "Default Gateway." This is how it works at the DHCP global/interface context (under Services>DHCPv4>[LAN]). This is not how it is working under when, on that same page, you create a new or edit an existing DHCP static mapping - it is just ignoring an input of "none." I (and the previous person that asked for this) want it to work on a per-device context the same way it works on the global/interface context. Screenshots showing how it works when "Gateway" is configured on the DHCP settings at the global/interface context: Global="none" Screenshots of how it is working when it is instead set at the device context within the specific device's DHCP Static Mapping context: Global="none" As you can see in the second screenshot, when the value of "Gateway" was set to "none" on a DHCP global/interface context, the "Default Gateway" field is blank. In the 4th screenshot, when the exact same setting was configured within the one device's DHCP Static Mapping context, it ignores it and just sends a Default Gateway value anyway. This, instead, should be blank. |
|
you can find the generated dhcp config at |
|
Thanks for pointing me to that file @AdSchellevis . I believe I'm seeing what is meant by "DHCPd will likely still inherit from the pool setting so you can't unset a previously set gateway." I see that you can override the "option routers" value with another valid IP, but I'm not sure whether there is a null value or something you can use to override the pool's "option routers" value with a blank value. Is there any way to manually edit the dhcpd.conf file and not have it get overwritten when the DHCP service is restarted? Even when I change "option routers {ip}" to a different valid IP, the settings are not holding when I restart the service. I'd like to try some things (like "option routers null;" "option routers ;" and find whatever a "null" character would be and put that after it, to see if any of these options are available). I don't see any reference to being able to do so in the documentation @AdSchellevis linked, so it may not be possible. If that is the case, then the description in the device context shouldn't tell us we can - if this is the case, the changes in #4843 should be reverted (and, ideally, a description instead saying "a value of "none" cannot be set in a "Static DHCP Mapping"" to pre-emptively answer the questions for others). That, or a feature request to dhcpd. |
|
It looks like this can be accomplished by editing the dhcp-parameter-request-list to specify which DHCP fields are sent back to a client (and, by extension, allowing you to omit the "router")... If there is a way to expose this option in the GUI, then that could work as well. |
Not very user-friendly, but you could kill the service manually and start it in a similar way as the script does: core/src/etc/inc/plugins.inc.d/dhcpd.inc Line 1213 in 08fb2ea As mentioned in the other ticket (#4843), "none" is only added for consistency, the effect is the same as empty. core/src/etc/inc/plugins.inc.d/dhcpd.inc Lines 1116 to 1118 in 08fb2ea |
|
Not sure why sending rockets to the moon is a good idea. Just add a pool where your static mapping IP is in range and then set gateway "none" for that pool and leave gateway in static mapping empty? |
Good thought, but I am running into the same problem as adding it on the per-device context - it is still globally defined (within the "subnet" context, which I'm now seeing is a higher context than even "pool"), and thus inherited by the Additional Pool.
If I switch Gateway to "none" to omit it from the global context, then set an Additional Range for the usual DHCP range and configure the Gateway to 10.0.10.1 in there, it does work. However, any devices with static mappings outside of the pool will need the Gateway added to them individually. I am also getting a "[wifi SSID] has no internet access" showing up in a notification on my Android device when it is configured, despite being able to reach the internet on it.
Consistency of messages is not ideal if the message is misleading from an end user's perspective. Now that I understand what this is doing behind the scenes, I can understand why it would be thought of as consistency - however, from what an an end-user sees in the WebUI, it appears to be a bug. Entering "none" in both of these contexts, as far as the configuration goes, does similar - it simply omits the "option routers" parameter in these two contexts. However, they effectively do very different things: In the global pool context, it blocks inheriting of the gateway address, whereas in the per-device DHCP mapping context, it does nothing. To an end user (i.e. me) reading the description, "Type "none" for no gateway assignment" seems be pretty unambiguous in stating that the client being configured will not receive a default gateway address. Then when one reads that exact same description in the global/interface context, and sees it behave in the expected manner (no gateway address being sent to clients), then this appears to be a bug. |
I can fix the help text in a second, but it's not the solution you want. I really need you to stay on point which is how dhcpd.conf can be adjusted accordingly. Everything else is just demotivation or waste of time. Cheers, |
Agreed - that won't fix the underlying behavior. In the end, though, if this is a limitation of dhcpd and a workaround is not going to be implemented, the message needs to be addressed. Ok, I think I've found a value that works in the dhcpd.conf. Thank you for referring me to the way to start the service @AdSchellevis . While the WebUI appears to be pulling the values it shows from somewhere else, I see that the changes I make in the dhcpd.conf are being applied to clients when starting it using the recommended method for testing. Default: Adding "option routers null;" to the specific device: One potential concern with this, is that this is likely just assuming any non-IP values in there are hostnames. Since "null" isn't a hostname I have configured in DNS, it is getting back a blank IP, and so the DHCP value passed out for Default Gateway is blank. When I put a valid hostname in there, though, that is the IP that gets passed. I would assume that a device having a hostname of "null" would be bad practice anyway, so this could potentially be a way to handling "none" values to keep a default gateway blank. Technically this could be anything, so using something like "option routers opnsense-null-hostname" (or something else that will never be a hostname in anyone's environment) would work as well (just tested it, and it does). So, if a value of "none" on a client's DHCP Static mapping can drop "option routers opnsense-null-hostname;" (or some other similarly-unused "hostname" in there), that should get this working in a manner consistent with the description, and allow users to not have a Default Gateway assigned to clients. Note that this could also be done in the "Additional Pools" section, as the "Gateway" values within additional pools behave the same as DHCP Static Mappings. |
|
Spent some time this afternoon figuring out PHP and Github pull requests, and submitted a PR for this issue: #6425 |
|
This issue has been automatically timed-out (after 180 days of inactivity). For more information about the policies for this repository, If someone wants to step up and work on this issue, |
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
I see that this was previously brought up a couple years back (#4843), but that was when this was initially added (because it was not available). At this point, the feature looks to no longer be working.
Describe the bug
I am attempting to set a static DHCP mapping for one of my clients without a gateway (this is on a dual-NIC device, and to ensure anything outside of the NICs' local subnets get routed out a specific NIC, I want the secondary NIC to not receive a gateway when pulling DHCP). When I set the "gateway" of that device's static mapping to "none," as specified in the "gateway" description, it still gives it a gateway. If I set this same setting to "none" on the DHCP interface context, it is correctly applied (i.e. no gateway assigned when pulling DHCP on client).
The current OPNsense version where the bug first appeared: Currently running OPNsense 23.1_6-amd64
The last OPNsense version where the bug did not exist: Don't know. I've only been running it since the previous version, and it wasn't working there too.
The exact URL of the GUI page involved (if any): https://10.0.20.1/services_dhcp_edit.php?if=opt3&id=0 (installation-specific. To get there go to Services>DHCPv4>[select interface]>Edit existing DHCP client).
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No gateway assigned to DHCP client.
Describe alternatives you considered
None available, aside from setting static IP.
Screenshots
Relevant log files
n/a
Additional context
n/a
Environment
Software version used and hardware type if relevant, e.g.:
Client: Windows 11
OPNSense version: OPNsense 23.1_6-amd64
The text was updated successfully, but these errors were encountered: