Is this a bug or a very needed feature? Changing interface LAN IP locks use out!
-
you keep using the phrase locked out - I think you're better off saying something like "unable to directly access." Locked out implies pfsense is denying you access, which is not true.
Forcing the user to visit the DHCP service page is intelligent in my opinion, this way the user has to skim over the DHCP settings to make sure everything (not just the scope) is to their liking. Then if you run into networking issues later you know without a doubt it's not the DHCP daemon, because you just verified its settings.
Since you're not truly locked out, and about 2 minutes of work of setting your local IP to static can fix the issue - the DHCP auto-updating is not really much of an issue if at all. I use pfsense in my lab enviroment, and I'm always screwing around with the subnets, I rather prefer to be forced to go there and verify everything.
Though maybe as a compromise, there could be a setting like there is for NAT rules to auto-generate/update related fields… I'm not sure who is the larger base of users, business or personal - but depending on that answer I would decide whether that should be default on or off. Think it would make since that option is available under the DHCP settings of each interface.
Anywho, my two cents.
-
@heavy1metal:
you keep using the phrase locked out - I think you're better off saying something like "unable to directly access." Locked out implies pfsense is denying you access, which is not true.
Forcing the user to visit the DHCP service page is intelligent in my opinion, this way the user has to skim over the DHCP settings to make sure everything (not just the scope) is to their liking. Then if you run into networking issues later you know without a doubt it's not the DHCP daemon, because you just verified its settings.
Since you're not truly locked out, and about 2 minutes of work of setting your local IP to static can fix the issue - the DHCP auto-updating is not really much of an issue if at all. I use pfsense in my lab enviroment, and I'm always screwing around with the subnets, I rather prefer to be forced to go there and verify everything.
It's not "Forcing" the user, it's running the procedure that should run which will make user HAPPY. You didn't make a point as to why not change DHCP to automatically reflect the interface. Other than Relay we do not have a reason so far per this discussion. Even for business users, I am not seeing a use case. Also, 2 minutes is a waste of time if it happens but it's longer than 2 minutes when there is no access to serial console or when you are on a mobile site with a laptop and no serial console….etc. Again not to get into philosophical side of things as agreed above there is a need for a check-box at the very least or change the behavior all together.
Thanks for the input.
-
It's not that easy. The user must decide what the new settings will be, an automatic choice would only be correct in the simplest of cases.
Before you assume it's a simple thing to do, stop and consider that not everyone uses /24's, or could change between a /24 and something larger or smaller as well as changing the subnet.
If you need to change the LAN subnet and DHCP and such together and need your hand held, just run back through the setup wizard and do it that way.
-
The problem I have with it is not that I need my hand held, but that you cannot change the DHCP scope before you apply the changes like you could in previous versions. I'm sure other changes dictated this behavior and it's a minor inconvenience, but it it made it easier when you could change the LAN ip, go over to DHCP and adjust the settings, go back to LAN to apply the settings, the refresh the workstation ip and re-connect. Now you can't change the DHCP scope until the LAN changes have been applied.
-
The problem I have with it is not that I need my hand held, but that you cannot change the DHCP scope before you apply the changes like you could in previous versions.
Ah, that changes things quite a bit. If that's true then I must have either not noticed or, more likely, not had cause to run into it yet. That certainly elevates this to at least 'very inconvenient'.
Steve
-
I just succeeded with this procedure on a stock 2.1-RELEASE test system:
Starting LAN IP of pfSense test system was 192.168.42.1/24 - DHCP server giving out 192.168.42.10-245
Connect to WebGUI at 192.168.42.1 from PC with DHCP-received IP 192.168.42.10/24
Interfaces->LAN - change LAN IP to 192.168.48.1 and press save
Ignore the Apply button for now
Go to Services->DHCP Server - change DHCP range to 192.168.48.10-245 and save/apply, it copes with that.
Go back to Interfaces->LAN - it remembers there is an Apply pending. Press Apply. Now the LAN IP changes, the screen does not come back.
At the PC, renew the DHCP lease. On Windows:ipconfig /release
ipconfig /renew
I got an IP address 192.168.48.10/24 - great thing
Go to the WebGUI at the new LAN IP 192.168.48.1 and play…So it is possible to make this change "on-the-fly" without needing to ever give the LAN-side PC a static IP.
-
That would explain why I've not run into it then. ::)
Steve
-
The problem I have with it is not that I need my hand held, but that you cannot change the DHCP scope before you apply the changes like you could in previous versions. I'm sure other changes dictated this behavior and it's a minor inconvenience, but it it made it easier when you could change the LAN ip, go over to DHCP and adjust the settings, go back to LAN to apply the settings, the refresh the workstation ip and re-connect. Now you can't change the DHCP scope until the LAN changes have been applied.
I have problem with same.
Jimp: Setup wizard is simply scary to do when doing something remote and think of the so many NEXT NEXT NEXT that have to be pressed to simply change the LAN DHCP. Please consider this as a very strongly needed feature for a check box. I do not see how the current process is useful to over 90% of your users/clients right now - unless you have huge clients who requested this to be that way. Some of the basic defaults are probably best to have a list online and allow the user base comment on it so that simplicity and efficiency is at maximum when it comes to pfSense. I would suggest the warning to change to this:
"Your DHCP range was change to reflect the change that you are just making on this interface. If you would like to change that, go to DHCP Server options and change it after applying this proces"
Here is another thing: I can NOT set a different DHCP Range in SERVER DHCP settings anyways. It will give me an error and will say that my DHCP range has to reflect the interface IP. So, why on earth wouldn't that change???????
-
If you are doing it remotely, you don't have to care about losing your LAN IP before you change your DHCP settings. If you're local, use the wizard. Nothing scary about it, it will fill in the current settings as you go.
As others have pointed out if you follow the procedure as noted, it works. See the post a few up by phil.davis. It works fine if you do it that way locally.
-
I'm guessing something changed since the introduction of 2.x. When I first started using it, I remember not being able to change the DHCP range until applying the LAN settings. I started using the console to change the LAN when staging a box and haven't tried it since. I just checked on 2.1 and it indeed works fine.
<rosannerosannadanna>Oh, Ok. Nevermind</rosannerosannadanna> -
If you are doing it remotely, you don't have to care about losing your LAN IP before you change your DHCP settings. If you're local, use the wizard. Nothing scary about it, it will fill in the current settings as you go.
As others have pointed out if you follow the procedure as noted, it works. See the post a few up by phil.davis. It works fine if you do it that way locally.
Jimp: as a very active user of pfSense I and others on this thread have tried to give input on this broken process (to my opinion). It's up to devs to decide whether this takes priority or not. There is enough reason for it to work in a simple way and to allow everyone to enjoy the feature without headache. I DO know how to change LAN subnet using the current procedure and I DO know how it works but that is NOT the point of this thread.
Thanks for all the input.
-
It is fine as is. Let's say I have a 192.168.0.0/23 interface, and only have a DHCP scope defined for 192.168.1.0/24. If I decide that I only need a /24 and change my interface address to 192.168.0.0/24, what should happen to that DHCP scope? Should it automatically be changed to 192.168.0.0/24? What if there's something on that range conflicting? There are too many variables to have it automagically switch the scopes, because there is no mind-reader module yet.
-
It is fine as is. Let's say I have a 192.168.0.0/23 interface, and only have a DHCP scope defined for 192.168.1.0/24. If I decide that I only need a /24 and change my interface address to 192.168.0.0/24, what should happen to that DHCP scope? Should it automatically be changed to 192.168.0.0/24? What if there's something on that range conflicting? There are too many variables to have it automagically switch the scopes, because there is no mind-reader module yet.
Sounds like you DID NOT read my first post. Please go ahead and read it.
Back to your reasoning, why does the wizard automatically pickup a "192.168.0.10 - 254" range right now? Is that a VERY GOOD practice? Why 10? Why 254? There are no standards to these things and that has not been my argument all along. In your case maximizing the number of IPs to reflect the full subnet potential minus the first 10 maybe a good idea. Also go ahead check and see what the wizard picks for your /23. And how come you don't have a problem with that???
My main issue with this is that the box locks if you forget to change the DHCP Server range. I have said that many times and answer I am getting is be careful - well, why create a door lock with warnings all over it to put the key in only one way or it will never open easily? why do that when we can allow for a key to insert any way or have a better lock where it won't be so fussy?
-
It does not lock the box. You can manually set an IP and get in.
The defaults are just that – defaults. Once the user changes a setting, the defaults no longer apply and any automatic method of trying to "guess" a new range will be inherently flawed or confusing. End of discussion.
