Sending DHCP NACK by default to out-of-range "requested IP address"
-
It did also send DHCPDISCOVERs, but then just ignored the corresponding OFFERs after not getting the NAK on the old IP address' request
Well that sure and the hell does not sound rfc compliant to me..
Pfsense can only offer options in dhcp that are actually in the dhcp server they use.. Does it offer what your asking about NAK any request for an IP that is not in the current pool? Off the top I would guess no.
-
It did also send DHCPDISCOVERs, but then just ignored the corresponding OFFERs after not getting the NAK on the old IP address' request
Well that sure and the hell does not sound rfc compliant to me..
Pfsense can only offer options in dhcp that are actually in the dhcp server they use.. Does it offer what your asking about NAK any request for an IP that is not in the current pool? Off the top I would guess no.
Well, should I write my own? Is there even a simple way to integrate external software with the control panel, and make it survive updates?
-
Perhaps you should just get the DHCP hotfix from MS for the shitty W10 OS.
-
and ipconfig /renew always failed
What about /release?
-
Yeah that was one hack around the W10 bug. Others claimed that it required
netsh int ip reset ipconfig /flushdnsas well… Regardless, this W10 stupidity is not a ISC DHCP fault.
-
and ipconfig /renew always failed
What about /release?
Yeah that was one hack around the W10 bug. Others claimed that it required
netsh int ip reset ipconfig /flushdnsNone of that worked. Nor uninstalling and reinstalling the network card, nor resetting the networking stack.
Some claim to have solved the problem by mounting the Registry in another Windows installation and deleting a specific key. Yuck.Perhaps you should just get the DHCP hotfix from MS for the shitty W10 OS.
Hotfixes are no more a thing. Now there are "incremental updates", and all the computers are up to date.
Regardless, this W10 stupidity is not a ISC DHCP fault.
That's a fair observation, but we all know how it works in the real world.
What I mean is, I can't go to my client and tell him to toss all its Windows machines and replace them with Linux machines, and to replace their ERP software because the present one is based on AcuCobol ( ::) ).
Nor I can tell him to buy an IP address management system nor can I use fixed IP addresses, because they have too many machines and a too dynamic of a network to do that.The easiest solution (and less costly for the client) might really be writing my own dead-simple DHCP server, for how absurd it may sound, if ISC's daemon really does not have an option or a less crafty way to NAK by default.
I found an interesting topic on the ISC user mailing list: https://lists.isc.org/pipermail/dhcp-users/2012-April/015276.html
It seems to talk about this exact issue. -
So this is a MS shop?? Sounds like you have lots of windows machines - so your not running Active Directory?? Or any windows servers? Why would you not just run MS dhcp.. Does it NAK clients that ask for an IP that is not in its pool?
Dhcpd will normally NAK an IP that is outside the scope of the network.. So for example if your network is 192.168.0/24 and you run a pool on the dhcp server of .100 to .150 if a client asks for 192.168.0.50 it will not be nak..
But if it asks for 192.168.1.x then it would get a nak..
This is by design so dhcpd is not sending a Nak to clients that are getting a dhcp server from a 2nd or 3rd dhcp server handling parts of the pool..
Normally client that does not get back an answer to a request, and then sends discover should then if gets an offer for that discover should use that IP.. As dok mentions sounds like you have bad dhcp clients to me.. Which are MS clients, so I would be curious if the MS dhcpd naks how you want it too.. My guess is also no..
I can see 1 problem for sure if running multiple dhcp with portion of the pools and sending naks for IP requests that are not in their pool. Now the client would be sending a discover to get an IP every time vs a renew or request.. So wouldn't this mean that you would never actually renew a lease but be getting new lease every time?? Never actually tried to lab that or test such a thing because it really should never come into play.
-
Release followed by renew didn't work????
Yesterday, I used Wireshark to see what happened on a Windows 10 computer. When I just did a renew, I could see the computer make the dhcp request from it's previously assigned address and then receive an ack. When I did a release first, it went through the full discover, offer, request, ack sequence and used 0.0.0.0 as the source address until the ack, at which point it started using the assigned address. If this isn't happening for you, then you've got a real serious problem that has nothing to do with pfSense.
This shows why capturing packets is an extremely useful tool I prefer Wireshark, but you can also use the pfSense packet capture for this. You can also run Wireshark on a Windows computer and leave it running while you try release & renew. For IPv4 DHCP, filter with "port 67 or 68". This will show the packets from both the computer and DHCP server.
-
^ yup.. packet capture is like step 1 trying to figure stuff like this out on what is going on.
If your setup the pool to include the IPs that are being requested by the client, and there is a lease for that IP then pfsense should be sending NAK.. If your using a subset of the range for the pool.. And a request comes in for an IP that is on that correct network, but outside the pool then no dhcpd will not NAK it.
-
So this is a MS shop?? Sounds like you have lots of windows machines - so your not running Active Directory?? Or any windows servers? Why would you not just run MS dhcp.. Does it NAK clients that ask for an IP that is not in its pool?
Because I do not want to run any more MS stuff! I'm not gonna make them pay thousands of dollars for a domain controller just to run DHCP.
Dhcpd will normally NAK an IP that is outside the scope of the network.. So for example if your network is 192.168.0/24 and you run a pool on the dhcp server of .100 to .150 if a client asks for 192.168.0.50 it will not be nak..
But if it asks for 192.168.1.x then it would get a nak..
This is by design so dhcpd is not sending a Nak to clients that are getting a dhcp server from a 2nd or 3rd dhcp server handling parts of the pool..
Normally client that does not get back an answer to a request, and then sends discover should then if gets an offer for that discover should use that IP.. As dok mentions sounds like you have bad dhcp clients to me.. Which are MS clients, so I would be curious if the MS dhcpd naks how you want it too.. My guess is also no..
I can see 1 problem for sure if running multiple dhcp with portion of the pools and sending naks for IP requests that are not in their pool. Now the client would be sending a discover to get an IP every time vs a renew or request.. So wouldn't this mean that you would never actually renew a lease but be getting new lease every time?? Never actually tried to lab that or test such a thing because it really should never come into play.
Johnpoz - I really appreciate the effort you are putting to explain this to me again and again and your help in general - but it's not that I don't get it. I understand that this is the default behaviour of DHCP and how it is intended to be normally use.
But sometimes in the real world there are needs that are slightly different from the "intended" behaviour, and this is why pfSense already contains many granular options that are not strictly "standard" but are there because they proved to be useful in some real world situations.
This particular option would be useful in my (and other people's) real world situation as I only want to have a single DHCP server on the whole network, and I need to send the NAKs by default. :)Release followed by renew didn't work????
Nope! I was as shocked as you. At one point I was about to bang my head against the desk and surrender.
Yesterday, I used Wireshark to see what happened on a Windows 10 computer. When I just did a renew, I could see the computer make the dhcp request from it's previously assigned address and then receive an ack. When I did a release first, it went through the full discover, offer, request, ack sequence and used 0.0.0.0 as the source address until the ack, at which point it started using the assigned address. If this isn't happening for you, then you've got a real serious problem that has nothing to do with pfSense.
This shows why capturing packets is an extremely useful tool I prefer Wireshark, but you can also use the pfSense packet capture for this. You can also run Wireshark on a Windows computer and leave it running while you try release & renew. For IPv4 DHCP, filter with "port 67 or 68". This will show the packets from both the computer and DHCP server.
I've already gone that way. As mentioned, the computer would send DHCPDISCOVER and then just ignore the DHCPOFFER, keeping its old IP address after noticing that its DHCPREQUEST for it didn't get NAKed.
And - again - after receiving NAKs for those DHCPREQUESTs (which I got pfSense to send by employing the workaround I described in the initial post), it would no longer ignore the DHCPOFFERs and actually used the new IP address.
In other words, the Windows machine DID request a new IP address, which got correctly offerend, but then it tried to request its old IP address and since it didn't get NAKed by the DHCP server it would actually decide to use that.
I honestly do not think this is not compliant, I think this is just a very weird behaviour. And this is why I think pfSense needs the option to send NAKs by default.^ yup.. packet capture is like step 1 trying to figure stuff like this out on what is going on.
If your setup the pool to include the IPs that are being requested by the client, and there is a lease for that IP then pfsense should be sending NAK.. If your using a subset of the range for the pool.. And a request comes in for an IP that is on that correct network, but outside the pool then no dhcpd will not NAK it.
This was added while I was replying. I just confirm what I've already said. Packet capture done, I understand the behaviour and why it is that way, I still think that there should be the option to override this behaviour.
-
Yeah, so you are using a broken OS produced by MS and ranting at pfSense forum. Makes a lot of sense. NOT!
-
Yeah, so you are using a broken OS produced by MS and ranting at pfSense forum. Makes a lot of sense. NOT!
I'm not ranting. You are, right now.
My objective was mainly to discuss whether or not the behaviour I've observed really is non-compliant or just weird (it makes a big difference, you know), and whether the addition of the discussed option to pfSense would make sense. You could have noticed that by reading my first post, which explicitly mentions that I've already found a solution.
So you are just here to bash on me and you don't intend to add anything to the discussion. Makes a lot of sense. NOT! -
Here's a work around, but it will require some effort of your part. Since it tries to use the previous address in the same subnet, then perhaps you can force it temporarily to use a different subnet. You can do this either by temporarily changing the subnet in psSense and causing each computer to release/renew or just grab a cheap router, configured for a different network, and then connect each computer to it, then put them back on the real network.
BTW, I have been working with networks for about 20 years and have often found MS breaks things.
-
Here's a work around, but it will require some effort of your part. Since it tries to use the previous address in the same subnet, then perhaps you can force it temporarily to use a different subnet. You can do this either by temporarily changing the subnet in psSense and causing each computer to release/renew or just grab a cheap router, configured for a different network, and then connect each computer to it, then put them back on the real network.
BTW, I have been working with networks for about 20 years and have often found MS breaks things.
Thanks for the suggestion, but as I've mentioned in the original post I already have a functioning workaround which is arguably more viable.
