Is this a bug or a very needed feature? Changing interface LAN IP locks use out!
-
No one is stopping you from setting manually a static IP in the new subnet you configured.
After all the GUI even warns you that you needed to change the DHCP config.
If you forget it, you have to live with the consequences. -
I hear what you are saying and it's about what is in place already. What I mentioned was an improvement that users can appreciate.
Without getting into philosophy (which I don't like) below are the reasons why I say this should change:
1- Initially when the board is configured the range is not asked. You do pick /24 or whatever but you don't pick from .10 to .240 for example. That procedure gives the user the assumption that changing the LAN subnet means that IP range will be smart enough to change automatically. This virtually happens on all off-the shelf routers.
2- What possible use is there for DHCP range that is different from LAN subnet?
3- User does get locked out easily - this can happen when someone is working with many boxes - despite all the warnings.
4- How is this NOT an improvement? please stick to logical reasons.
Thanks for feedback everyone.
-
I am on the road currently - but I do have access to quite a few different devices that provide dhcp services.. Be it a windows server, linux server, soho router running native firmware or dd-wrt, tomato, openwrt, etc. And can always fire up a different firewall/router distro that is sim to pfsense.
But if you are warned about dhcp when you change your interface ip/network – what else do you expect to happen.. It seems logical to me that if your changing the lan interface that your dhcp server is running on that you will need to also need to modify your dhcp scope being served from this interface - a warning is much better than actual automatic change. Because it is also possible that I don't want to alter the dhcp scope - maybe this scope is being served to clients via a relay, etc..
Its up to the admin -- the one changing the lan IP to understand what his/her dhcp server is going, etc.
-
With respect, I think the only point you make is this, "Because it is also possible that I don't want to alter the dhcp scope - maybe this scope is being served to clients via a relay, etc..". However, I am not familiar with relay. Can you please explain a bit?
Also, if the example you give is an often used one, then why not (again suggesting as an improvement) add a check box beside the warning / apply button so that it can be checked to automatically change the range to reflect the changes.
Thanks for the reply.
-
I agree, that for most people in smaller environments an automatic adjustment of the range would make sense.
The idea for a checkbox reading "auto-adjust DHCP range" next to the notice that one needs to adjust the range sounds sane.Edit:
However i'm not sure what the logic behind this "automatic" change would look like, and if it's even possible. -
I agree, that for most people in smaller environments an automatic adjustment of the range would make sense.
The idea for a checkbox reading "auto-adjust DHCP range" next to the notice that one needs to adjust the range sounds sane.Thanks for the reply. Should I create a feature improvement or a bug for this? or a dev can add this?
-
IIRC, In 1.2.x you would get an opportunity to change the dhcp range before applying the interfaces changes so you wouldn't lose access (or at least could refresh your dhcp and regain access). In 2.x, I use the serial console when I have to change the LAN address.
-
IIRC, In 1.2.x you would get an opportunity to change the dhcp range before applying the interfaces changes so you wouldn't lose access (or at least could refresh your dhcp and regain access). In 2.x, I use the serial console when I have to change the LAN address.
Thanks for the feedback. And that was a good method probably - now it's all about getting locked out. Serial console is not always readily available and adds to the headache. Some of the defaults are best left to how they are rather than complicating. I am assuming those who want to use Relay or something out of ordinary can go and change the DHCP range however they want. So, at the very least - if not making my suggestion a default - it's best to add a check box to change DHCP automatically. And keep the check box checked by default :o
-
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.
