Bug #4820
closed
Added by Andrew Houlne over 9 years ago.
Updated almost 8 years ago.
Description
At initial setup, 192.168.100.1 was used for the LAN IP and a DHCP scope of 192.168.100.0/24 appeared in the interface, but all addresses being handed out were 192.168.1.0/24 with gateway of 192.168.1.1. A restart of the DHCP service did not correct the problem. Issue was corrected once the entire server was restarted. Systems which already had an IP on the correct network were able to access the Internet.
How did you do the initial setup - using the webGUI initial wizard, from console menu selections, or?
And how did you specify the whole of 192.168.100.0/24 for DHCP?
The validation should be preventing a DHCP range that includes start/end IPs or the LAN IP itself.
- Status changed from New to Feedback
ditto Phil's question. The setup wizard in the web interface definitely doesn't do that, and I don't recall the console setup part doing that either. Once the LAN IP changes, dhcpd can't even launch on 192.168.1.0/24.
I set LAN and WAN IP info via the console, then completed setup via the webGUI using the wizard. The initial DHCP scope was set to 192.168.100.10 - 192.168.100.254 with pfSense having been assigned an IP of 192.168.100.1. I then adjusted the scope to start at .54 at which point I noticed that one of my systems was picking up 192.168.1.101 as an address with a gateway of 192.168.1.1, and no, I don't have any other DHCP servers on my network. The webGUI showed the correct DHCP scope, but was not using it for some reason.
Restarting the DHCP service then doing a release/renew didn't fix it, but rebooting pfSense corrected the issue. Is it possible that some config files are not written out during setup until a reboot happens? This isn't a big deal, and was easily addressed, but seemed like something the developers should know.
- Status changed from Feedback to Not a Bug
- Affected Version deleted (
2.2.3)
can't replicate any issues here. Change the LAN IP and DHCP scope at the console, and it immediately hands out IPs from the new subnet. Change it again, so a LAN host has a lease in the old scope in the leases file while the change happens, and upon renewal it has its renewal attempt NAKed and obtains an IP from the new subnet. Everything looks to be working fine here.
If you have a specific set of steps to replicate, please follow up.
Chris Buechler wrote:
can't replicate any issues here. Change the LAN IP and DHCP scope at the console, and it immediately hands out IPs from the new subnet. Change it again, so a LAN host has a lease in the old scope in the leases file while the change happens, and upon renewal it has its renewal attempt NAKed and obtains an IP from the new subnet. Everything looks to be working fine here.
If you have a specific set of steps to replicate, please follow up.
After testing this on 2.3.2, I have some reproducible steps, although this only looks to be a display bug.
1. Install 2.3.2 clean.
2. From the console, reconfigure the LAN IP to be something other than default. I selected 192.168.100.1.
3. When prompted to enable DHCP on the LAN interface, select yes.
4. Specify a starting IP with something other than 192.168.100.10. I selected 192.168.100.131.
5. Specify an ending IP. I selected 192.168.100.245.
6. After pfSense reconfigures the LAN IP and DHCP, the correct information is displayed in the console. Connecting a device to the LAN gives out the first correct available IP address of 192.168.100.131.
7. Log into the web UI and continue with the setup wizard.
8. When prompted to configure the LAN interface, leave the settings (will correctly display 192.168.100.0/24).
9. When the setup wizard completes, go to Services -> DHCP Server and you will see that the DHCP start IP will be 192.168.100.10 when it should be 192.168.100.131. Rebooting pfSense does not correct this. IPs will still be given out to devices correctly. You would need to change the start IP from the web UI to correctly display the start IP.
Confirmed this is still a problem in the latest 2.4.0-DEV 20161011-1023.
- Status changed from Not a Bug to Assigned
- Assignee set to Jim Pingle
- Target version set to 2.4.0
- Affected Version set to All
What appears to happen is that the wizard resets the range even if the existing range is valid. So if you have x.x.x.100 to x.x.x.199 and run the wizard, it will come out x.x.x.10 and x.x.x.245. If you started with that range, there would be no change.
Looks like adding a range check before changing the range will fix it.
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
- Target version changed from 2.4.0 to 2.3.3
Also available in: Atom
PDF