DHCP - Multiple Interfaces - possible bug?
-
I am no expert here, so please forgive if I am saying something incorrectly. And I'll preface that PFSENSE is a great product. And it is quite possible that my own ignorance is causing some issue I am unaware of, but I have been dealing with this for a few days and need to ask the community at this point.
I have PFSense running, community edition, version 2.4.5-RELEASE. I have 5 interfaces defined as such:
I have DHCP running on each interface (LAN, DMZ, DMZ_WEB), each with their own subnet (10.1.1.0/24, 10.1.2.0/24,10.1.3.0/24) respectively.
Each interface has some amount of static mappings defined and in DNS resolver (to internal DNS) I am registering DHCP leases, static mappings, and connected VPN clients (OpenVPN).
Everything seemed to be working fine for the first few weeks. Clients in each subnet were getting assigned their respective IP Addresses as expected and no issues were noticed.
Then, about 4 days ago I noticed that the DHCPD Service status on the dashboard was reporting as offline and some (but not all) clients were reporting offline. Ping tests validated the clients were no longer accessible.
What I found was if I disabled DHCP on any one of the three interfaces (LAN,DMZ, DMZ_WEB), the DHCPD service status on the dashboard reported as running, and clients for those interfaces would then become accessible with active leases.
Of course, clients associated with the third interface would not be available after any exiting leases expired (for testing purposes I set the lease renewal interval to just 2 minutes).
So I find this behavior very odd. It does not matter which of the three interfaces has their DHCP disabled. If any one is disabled, the status reports running on the dashboard and clients receive their leases on the other two subnets as expected.
For my own sanity, is there a known bug out there on this issue?
-
huh? If dhcpd is running on any interface - it will show running. But no it will not be running on the interface you shut it off on?
If your saying the dhcpd went offline, and then you disabled it on interface X, and then it showed running.. I would assume that your change in the config did a restart of the whole service, so yes those networks where it was enabled would now be able to get IPs again.. If for some reason dhcpd as a whole had shutdown/crashed.
-
@johnpoz - Sorry John, let me try to be more clear.
If I have DHCP set to be running on each of the three interfaces (all 3), then on the dashboard page the service shows as stopped AND leases expire and are not renewed across all 3 interfaces, despite being enabled:
If I then disable DHCP on just one interface, the dashboard page the service shows as running, and leases are then made available for clients associated with the two remaining interfaces:
This will happen and can be validated regardless of which interface DHCP gets disabled.
So basically, if any two interfaces have DHCP running, the service works as expected. But if a 3rd is introduced DHCP stops running across all interfaces.
Is that more clear?
-
Again.. Yes if say the dhcpd crashes/shuts down for some reason.. The service would show as down.. since it is.. But you making a change, like disabling specific interface.. Would cause pfsense to restart the service to reflect the new change in config.. So if the dhcpd was down, this change in config would cause a restart of it, or bring it back up because it was down.
You could also just hit the button to restart the service without making any changes to the config.
Does your log show why the service crashed or shutdown? If you hit that button and it doesn't restart the log should reflect why..
I have dhcpd running on way more than 3 interfaces ;)
-
Log report after trying to start DHCP service from services dashboard (hitting that button) with all 3 interface's DHCP enabled (it failed to start):
-
Looks like a problem with hn2 - says matches multiple shared networks... What networks do you have on these networks with masks.
Pfsense shouldn't allow you to create overlapping networks... But you could have an issue that slipped through or you changed mask after the network was created?
What are the networks you have on all of your interfaces?
Quick easy way to look and show this info would be just your menu when you ssh to the box - example here are mine.. Just hit networks that have public on them.
-
-
Well as long as your wan doesn't start with say 10.x something I don't see any overlap there..
Can you show say the dhcp server settings for that hn2 network (dmz) and your other.. Maybe there is something wrong in the config where it didn't update or something.
Give me a sec - we should be able to just look directly in the dhcpd.conf - one sec let me find the path, and post up mine as example.
Look at the dhpd.conf here
/var/dhcpd/etcDo you see anything that overlaps?
-
Sure thing:
I appreciate you keeping engaged, thanks.
I have to run for a job, but will be back online later this evening.
-
Well don't see anything overlapping there.. Odd.. The way I am reading that error is dhcpd thinks for some reason there is an overlap. Best to look direct in the dhcpd.conf
In your dhcpd.conf do you have this called out anywhere "shared-network"
Do you have any vips setup on pfsense?
https://redmine.pfsense.org/issues/6834For example pfblocker can setup a vip??
-
I reviewed dhcpd.conf @ /var/dhcpd/etc/ , but did not see anything regarding "shared-network". everything seems fine/normal within the conf file.
However, yes, I DO have two VIPs configured in association with haproxy, and I AM working with NAT as a result of the work with haproxy.
I have been setting up haproxy for a variety of use cases. I would not have thought there was such an association. Very interesting... I will read through this in detail tomorrow, run some tests, and report back.
Thanks for the clue.
-
To wrap this up... it was this same issue with a misconfigured VIP (https://redmine.pfsense.org/issues/6834). Essentially, in a VIP, you define the interface and an IP. If they do not align properly, this issue seems to surface.
A bit hard to track down, but now everything is working properly. Thanks John!
-
Glad you got it sorted!
