Project

General

Profile

Bug #4820

DHCP Scope at setup

Added by Andrew Houlne over 1 year ago. Updated 10 days ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
DHCP Server
Target version:
Start date:
07/07/2015
Due date:
% Done:

100%

Affected version:
All
Affected Architecture:

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.

Associated revisions

Revision d02ee138
Added by Jim Pingle 4 months ago

In the setup wizard, do not change the DHCP range if it is already set inside the new subnet. Otherwise it will overwrite a range set manually from the DHCP settings or the console when the wizard is run later. Fixes #4820

Revision 00fc1317
Added by Jim Pingle 4 months ago

In the setup wizard, do not change the DHCP range if it is already set inside the new subnet. Otherwise it will overwrite a range set manually from the DHCP settings or the console when the wizard is run later. Fixes #4820

History

#1 Updated by Phillip Davis over 1 year ago

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.

#2 Updated by Chris Buechler over 1 year ago

  • 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.

#3 Updated by Andrew Houlne over 1 year ago

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.

#4 Updated by Chris Buechler over 1 year ago

  • 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.

#5 Updated by Al Lotufo 4 months ago

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.

#6 Updated by Jim Pingle 4 months ago

  • 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.

#7 Updated by Jim Pingle 4 months ago

  • Status changed from Assigned to Feedback
  • % Done changed from 0 to 100

#8 Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to Resolved

Works

#9 Updated by Jim Pingle 10 days ago

  • Target version changed from 2.4.0 to 2.3.3

Also available in: Atom PDF