ISC Dhcp as implemented in pfsense is a pantload
-
I don't know enough about the core code to wag my finger at pfsense or ISC, but as implemented in pfsense, it can best be summarized as:
"working as intended by poor design"
I have been constantly annoyed by dhcp failures and scanning the forums highlights the common response of:
"Do you have any nodes set static within your dhcp scope?"
My answer to this has always been "yes, no and so what?"
The No is because I don't intentionally set statics within the dynamic scope.
However….dhcpd is apparently confused as to what the scope actually is.
My gut feeling is that this particular failing is a pfsense problem, though I haven't done the sort of thorough testing to give me a definitive answer.
What I have seen happening over and over on my development boxes is:
I set the scope to, say x.x.x.10-x.x.x.200.
Everything is fine - no issue with the service shutting down or ip's assigned.
I then realize I need more room for statics on the low end, so I change the scope to .50-.200.
And dhcpd has a hissy fit.
It issues out of scope ip addresses.
I just connected a box that had never before been connected to this subnet.
It previously had been on a 192.168.1.0/24 subnet, so it could not possibly have requested a renewal of 192.168.250.26, but that's the ip it received.
That's a flaw/bug - whatever you want to call it.
It's also a flaw that dhcpd will now periodically stop functioning because it has determined that static ip's from .11 through .49 offend it's delicate sensibilities, because:
A: It's objecting to a nonexistent state
B: It's a really boneheaded design if it can't tolerate a static within the dynamic scope.Point B implies that any pfsense network must use port authentication to prevent a single static device from hosing the network.
That would preclude it's use in almost any scenario I can think of.
Based on that, I must conclude that this is not normal behavior, and that either I am missing some critical setting to have pf require dhcp assignment, or that there is a very common bug that is exposed by common implementation activities.
I thought that perhaps due to a config rollback via the xml config files, a configuration error in the scope had been introduced, but I'm not seeing that based on /var/dhcpd/etc/dhcpd.conf.
What other files should I check to rule this out?
Are there changes I can/should make to the conf to change this behavior?
It just seems grossly deficient for a dhcp server not to have the functionality to detect an ip address conflict, mark the offending ip as BAD, and move on.
Like every other dhcp server I have ever worked with.
While I freely admit my own ignorance, I'm just not seeing this as workable behavior outside of a strictly controlled lab environment, where no changes to the scope are made without a wipe and reinstall, and devices are not allowed to be added to the system without direct intervention of the administrator to ensure no in scope statics are introduced, whether intentionally or not.
Are all the posts I have read just wrong?
I really like pfsense - enough so that my intention is to convert our existing infrastructure from cisco/sophos to pfsense across the board.
The goofiness has been tolerable so far, but it would be asking my team a lot to have to deal with what I see as seriously flaky dhcp beahvior.
I have 6 additional sites going online in the next 12 months where I really need to be able to do a forklift network implementation and have it be as soid as possible - there will be an admin on site for a few days to bug stomp as it goes online, but after that, visits will be annual at most.
I realize I'm complaining about free-as-in-beer software, and do not think I am remotely ungrateful.
We currently are playing catch with live grenades in that we do not have a user self registration with validation implementation.
I don't want to read in the morning paper "kiddie porn ring discovered operating out of local establishment."
pf gives me enough insight into user activity that I will be able to sleep at night.
My end goal is to have pf working in conjunction with packetfence to provide that unattended validation.
It won't prevent someone from doing Bad Stuff from our network, but it will raise the bar high enough that no one will be able to say I haven't fulfilled my due diligence obligations.
Going forward with cisco isn't an option, as getting the bandwidth capability along with identity management would make free wifi not economically viable.
Sophos isn't an option, as it's way too locked down to modify without compromising reliability.
I have one local site and one remote site live with pf now, in addition to every box I can glom onto acting as a dev box.
This is my last real hurdle before I start scrounging budget for 1U's.
Help me pfsense forums, you're my only hope...
-
So I can not make out what your freaking question is???
You say you have a scope of 192.168.1.0/24 and your client got an 192.168.250.x address?? Well it sure and the F did not get it from dhcp server running on pfsense for sure.. How do you think that could in a million freaking years happen??
What is more likely is you have a other dhcp server on your network, or your scope is not what you think it is..
If you going to modify your scope, then you should clear the old leases that fall outside your new scope - or yeah no shit stuff is going to complain.
-
The "as implemented" is the same way ISC dhcpd is implemented everywhere.
Give us something useful to go on.
We don't allow you to set a static mapping inside the pool because dhcpd doesn't consider that a true reservation, it'll still hand that IP out to another device if it needs to. Take it upstream if you want to moan about that. If you do end up with a static mapping within the range (by changing the range after adding one), it'll still work, just not guaranteed that only the defined device will get that IP.
It also won't stop running because of any static IPs, it doesn't care about static IPs in the least. And it certainly won't hand out IPs that aren't within your defined range (unless some kind of problem in dhcpd itself, which is unlikely).
If it stops running, it'll log something useful as to why it won't start in the DHCP and/or system logs. The input validation we put in place should prevent any such configurations, but it's possible you came up with something invalid that we haven't considered. Post the logs and the conf file that won't start.
/var/dhcpd/etc/dhcpd.conf is the config file, /var/dhcpd/var/db/dhcpd.leases is the leases file. If there is a problem, you'll find it in the conf file. Otherwise it's a problem with dhcpd itself, but either way we definitely would fix if it's our problem, or report upstream if it's theirs.
-
I probably should have been more clear - my question was how would I locate the core issue of a brand new device being assigned an ip from what used to be within the scope - but is no longer.
ie: scope used to be 192.168.250.10-192.168.250.200 - before the new device was added (about a week and a couple of reboots before,) scope was changed to 192.168.250.50-192.168.250.200 - new device was assigned 192.168.250.26.
I did not run around to each device and manually release each lease.
I've never found that necessary with other systems unless I was using really long lease times for some problem child device.
What I am hearing is that a change in the range of the scope will not take effect if the dhcp server detects any remaining leases from the old range.
I submit that this is entirely unnecessary and pointless, but I understand why you wouldn't significantly alter the behavior of one component
I can always just use dhcp from a switch - I have not looked closely at it's functions, but when I've done so previously I never had to jump through hoops to keep it from shutting down.
And yes - I realize it doesn't actually shut down - just whines and refuses to display leases until I restart dhcpd.
Like it just did - again.
This time, disabling dhcp and reenabling it doesn't restore the list, though changing the range to anything else does show the most recent lease.
I'm sure you tired of hearing about dhcp issues.
I'll decide which path best suits my preferences.
-
All you have done is complain, you have not provide any actual information to work out what your problem if anything might be.
If device had lease .26 before, and you change the scope to not include .26 – you need to delete that old lease... Or yeah that client can continue to renew it.. So what your asking is for pfsense on change of lease to delete all OLD leases that fall outside of the new scope?
-
No, I think my original question - which files to check - was answered in that as long as the old leases have not been cleared from dhcpd, the new range will not take effect.
At least that tracks with what I have observed.
The device initially would have had a 192.168.1.x address.
It was a machine I had loaned out long before I implemented pf, so there was no possibility of it having a 192.168.250.x address.
After I released the lease on that one system, it was assigned an address in the correct range.
It comes down to interpretations and expectations, I suppose.
I expect a dhcp server to respond with a dhcpnak per RFC suggestion - not ignore the request entirely.
But since it isn't absolutely mandated by RFC, I guess it's at least minimally compliant.
So what's the use case for this behavior?
What problem does it avoid, or what functionality does it enhance to have dhcp ignore requests for an invalid range, rather than send dhcpnak, which presumably would then cause the client to fall back to dhcpdiscover?
Is it to accommodate a scenario with multiple dhcp servers serving different options?
-
No that is not how it works… Your new scope would take effect, but if you have OLD leases they could be renewed...
If a client does not have an old lease, then they would get an IP in the new scope.. Take it up with ISC if you don't like how the dhcpd answers a renewal request while there is a lease there..
If your saying a client sent a discover and got an IP that was not in scope, and not an old lease then show that.. But when a client sends a renewal - and there is an old lease - then yeah dhcpd is going to renew it, why shouldn't it.. If you don't want to renew then you should delete that lease.
Where in the RFC does it state that old leases should not be honored if the scope was changed?
-
Except that it doesn't quite work like that either.
If the client has a lease, and the range of the scope changes, and the client sends a renewal request, dhcp ignores it.
I out a different system in that state earlier this morning to test it, by changing the range from 192.168.175.2-192.168.175.200 to 192.168.175.100-192.158.175.200.
I then did a renew from a client with a valid lease on 192.168.175.4.
pfsense logged:
dhcpd: DHCPREQUEST for 192.168.175.4 from 6c:62:6d:3f:42:62 via em0: unknown lease 192.168.175.4.
Does this track with your understanding of how dhcp is supposed to function?
At this point I just want to know if there is something here I'm not understanding, or is something broken.
I assume it's the former, as there are pretty vanilla installs with the same behavior across the board.
Mind you, two other devices which were in the same state have received new leases in the updated range, without being manually released.
The difference is that those devices have fallen back to sending dhcpdiscover.
FYI - I did find what amounts to confirmation of my assumption that isc dhcp specifically doesn't reply with dhcpnak to allow for multiple dhcp servers in some old packetfence docs.
Apparently, this causes issues with some clients changing vlans, and their workaround was to deny all clients in the subnets for which they aren't authoritative.
I could do something similar, and add a deny to dhcp.conf for the old segment of the range.
Not something I'd want to do for the use cases I'm planning, but if pf were doing dhcp the day I added 80 phones and needed to move a lot of devices around, it would have been useful.
More to the point, it explains the behavior in terms of providing functionality for which I have no use, but others do.
-
Pfsense dhcpd comes up authoritative, you can view the settings in the dhcpd.conf file.. But you are correct it is not sending NAK when it should since its authoritative. Is my understanding, but it seems you need a deny in the conf for that to happen. But that again is on ISC, I agree if the dhcp is set to be authoritative for a pool, it should not just ignore requests but actually NAK them if they are not good.
It will renew a lease, if its still in the pool even when here is a reservation setup for a client. Which is why I thought it would renew, but you are correct if you change the pool then that lease is no longer valid. But its not sending nak, so client will have to wait until lease expires before sending discover.
So a quick work around if you want to send NAK.. Is just create another pool that contains the ranges you want to NAK and then deny clients send a request for that - they will get a nak, and then send out discover vs waiting for their lease to expire.
There was a request long time ago to allow for custom changes to the conf file, like you can with unbound and the advanced box. It would be nice to be able to do that.. Another work around is just killing the dhcpd edit conf and then starting it directly pointing to your conf file and what interfaces you want it on. So that conf does not get rebuilt from the xml in the normal service startup.
