PfSense 2.3.2 static mapping assign temporary lease to client - Bug?
-
Hi,
if I connect a new client with DHCP to my network pfSense assign a temporary IP address of the IP DHCP range.
Now I assign a static IP to the client and reconnect the network, but pfSense assign again the temporary IP.As soon I remove the static IP the client MAC with the temporary IP is visible again under Status -> DHCP Leases.
Remove this temporary lease and assign the static IP again resolve this issue, client receive the static IP.Is this a known issue in 2.3.2?
-
When you state "static IP", do you mean that you're configuring a static IP on the client machine, or that you're configuring a DHCP reservation within pfSense?
Assuming the latter… this seems to be how ISC DHCP Server (which pfSense uses) acts... If there's an active lease for a given client, it always seems to assign that IP address without first checking for reservations. The only way to "fix" it (so another IP, such as a DHCP reservation, is assigned) is to delete the active lease.
Creating a DHCP reservation doesn't seem to automatically purge any active leases from the DHCP server for the same MAC address. I can't tell you if that's by design or just something they overlooked.
-
When you state "static IP", do you mean that you're configuring a static IP on the client machine, or that you're configuring a DHCP reservation within pfSense?
Mean configuring a DHCP reservation within pfSense (no change on the client).
Creating a DHCP reservation doesn't seem to automatically purge any active leases from the DHCP server for the same MAC address. I can't tell you if that's by design or just something they overlooked.
With older pfSense versions I start a new machine, watch the DHCP lease to find out the MAC, assign a static IP in the DHCP setting and reboot.
I my eyes pfSense should delete all DHPC leases with assign a static IP address for this MAC.
-
"assign a static IP in the DHCP setting and reboot."
Reboot what? The client? What client? Its quite possible that on reboot a client doesn't ask for his old dhcp IP again?
AFAIK going back to versions 1.x of pfsense it has always worked this way. If you have lease file and the client asks for that IP in that lease again, the dhcp server just does what its asked.. A client asks for an IP that there is an existing lease for so yeah it gets that same IP. If client asks for an IP and there is no lease then dhcp server would look to see if there is reservation and give it that, or if not then give it IP out of the pool.
Maybe I am remembering this wrong.. Guess could fire up an old copy of pfsense to validate that.. But I do not think this has changed in 2.x let alone 2.3.x etc..
"pfSense should delete all DHPC leases with assign a static IP address for this MAC."
Sounds like a feature request to me - head over to redmine and see if already been put in, or yeah put it in..
-
"assign a static IP in the DHCP setting and reboot."
Reboot what? The client? What client? Its quite possible that on reboot a client doesn't ask for his old dhcp IP again?
Reboot the client (Linux box).
"pfSense should delete all DHPC leases with assign a static IP address for this MAC."
Sounds like a feature request to me - head over to redmine and see if already been put in, or yeah put it in..I guess this work with pfSense =< 2.3.2, but maybe I'am wrong.
Never need to delete the lease before assign a static mapping on the pfSense/DHCP server in the past. -
Well do a simple sniff on your interface dhcp server is running on in pfsense. Reboot your linux box, does it ask for IP again.. What flavor of linux you running, did that change?
Is it doing a discover or request.. So here I just rebooted a linux ubuntu 14.04.05 server vm I run.. And it sends request for its old IP.
If I force a release on it, so it sends out a discover - it is still asking for its old IP. But the release should of removed the old lease and then allowed you to get your reservation. I would have to clear up the reservation I have for this box and do some sniffing, etc.
And for sure could test this with older version of pfsense. But there is no script or anything that deletes old lease files.. The removal of the lease file would be up to dhcpserver and client requesting it, etc. What the dhcpserver does when it gets a discover or request after offer, etc. Its possible dhcpserver could be coded to look for reservations first before looking at old leases, etc. But that would be up to them - that aspect is not coded by the pfsense team.
Sure its possible they could code something in pfsense to flush leases when you create a static.. But is that really needed? When you create a reservation for device just look through the leases and delete any leases from that device and then upon client sending discover he will get his new IP, etc.
-
How long is your DHCP lease time ?
If a DHCP lease is greater than a few days, it will still probably be in effect when the client starts up again regardless.
http://askubuntu.com/questions/151958/how-to-make-dhclient-forget-its-last-dhcp-lease
-
If I force a release on it, so it sends out a discover - it is still asking for its old IP. But the release should of removed the old lease and then allowed you to get your reservation. I would have to clear up the reservation I have for this box and do some sniffing, etc.
(wow.. agreement..)
I don't have the ipv4 DHCP daemon running on pfSense anymore, so I can't verify this… but I experienced the same type of issue that the OP (and you) did when I had DHCP on the pfsense box. I spent quite a bit of time staring at the logs, and saw what you're seeing. The only way I was able to get dhcpd to refuse the old IP address and instead give the reservation address was to delete the old lease/assignment from the pfsense.
However, if I remember correctly, the old lease/assignment won't show up in pfsense (so you can delete it) as long as there is also a reservation. So, (again, this is from memory of a few weeks ago)I ended up:
1. removing the reservation from pfSense
2. renewing on the client (which caused a lease to appear in pfsense)
3. then deleting the lease on pfSense
4. ...and THEN creating the reservation.If the client renews between steps 3 and 4, you'd have to start over again.
Once done, when the client renews, the dhcp server will NAK the request for the old IP and insist on giving the reservation.
This whole process is more annoying when you realize that for always-on machines, it won't happen automatically over time (because the clients will renew a lease BEFORE it expires.)
I can't say if it's a bug or working as intended.
-
Setting up reservations is a bit strange and needs some work, IMO. When you try to create a reservation, for the ip address, it says:
If an IPv* address is entered, the address must be outside of the pool.
If no IPv* address is given, one will be dynamically allocated from the pool.This is strange. There should be no way to create a reservation from inside the pool. If the user chooses to allow pfSense to allocate an address, it should still be be outside the pool.
Also, it would be useful if pfsense would display the prefix and the range of the pool or even better only prompt the user for the required portion of the address.
I tried to create a reservation for dhcp6 and chose to not enter an address. pfSense created a reservation, with no address, leaving the lease in place, which the client continued to use. I was using sophos utm before switching to pfsense. As soon as a reservation was created, the client would be given the new address as soon as the lease was renewed. When there is a reservation, dhcp* should assign it, irrespective of what the client requests.
-
If your not assigning an IP, how could it still be outside the pool.. From where would pfsense decide what IP to give the client?
The reason for the reservations and not assign an IP and allow to be pulled from the pool is to override other settings for this client than what the specific pool is for example maybe you want to hand this client a different dns server, or have it use a different router or domain or ntp server or tftp, etc.. but don't care what ip it has
edit: if you really really want to assign a reservation inside the pool it can be done with an edit
https://doc.pfsense.org/index.php/Why_can%27t_I_have_static_mappings_inside_my_DHCP_range
If assignments absolutely must be made inside the pool, and the risks involved are worth taking and want to do so anyway, the input validation check may be removed from the PHP file that drives the DHCP editor page. The details of this unsupported change are left out as an exercise for the reader.But its much easier to just create multiple pools with the gaps needed to allow for your static reservations. So lets say your pool is 100-200 and you want some static reservations at 149-155, then you could create pool 1 with 100-148 and another pool with 156-200
-
If your not assigning an IP, how could it still be outside the pool.. From where would pfsense decide what IP to give the client?
The reason for the reservations and not assign an IP and allow to be pulled from the pool is to override other settings for this client than what the specific pool is for example maybe you want to hand this client a different dns server, or have it use a different router or domain or ntp server or tftp, etc.. but don't care what ip it has
edit: if you really really want to assign a reservation inside the pool it can be done with an edit
https://doc.pfsense.org/index.php/Why_can%27t_I_have_static_mappings_inside_my_DHCP_range
If assignments absolutely must be made inside the pool, and the risks involved are worth taking and want to do so anyway, the input validation check may be removed from the PHP file that drives the DHCP editor page. The details of this unsupported change are left out as an exercise for the reader.But its much easier to just create multiple pools with the gaps needed to allow for your static reservations. So lets say your pool is 100-200 and you want some static reservations at 149-155, then you could create pool 1 with 100-148 and another pool with 156-200
Agreed, aspects of this are vague. Assuming the pool is a subset of the subnet, I understand reservations should be from the subnet, but not in the pool. My main reason for posting was to point out the strange behaviour in the case where I elected to not provide an address. It was implied that pfSense would allocate an address, but it did not do so. No address was filled in and the device kept using the lease as if no reservation had been created. Unless I'm missing something, the feature is broken.
-
did you hand out different info? Do a test change the reservation to hand this client say different dns and see if the client after renew gets its new dns server.
-
Same issue here.
Static mapping seems to be somehow broken.
If I can provide log, let me know :) -
Same problem here.
When I assigned a reservation to a client (meaning that the client will be assigned the same IP when requesting DHCP) it assigns an IP from the pool is the prior lease is still in the DHCP leases table.
I am SURE that this did not happen in prior versions (2.2) of pfsense. When you assigned a reservation, it was assigned first. It seems that this new version does not check the reservation table before the leases table.
I don't know if this is a bug or it is how it will work from now on.
Thanks for the help, and sorry for my bad English.
Kindest regards,
Gerardo -
"It seems that this new version does not check the reservation table before the leases table."
I do not agree, I have been using pfsense since version 1 and like 99% sure that has never been the case. Maybe you were releasing your lease from the client before renew.
I can tell you for fact that if on the client you do a simple release and then renew you get your reservation from the client. Windows do a simple
ipconfig /release
ipconfig /renewAnd you will get your new reservation. Again if the old lease is there and the client asks for it then yeah its going to be renew, does not matter if you have a reservation or not.
I do not see why some sort of script could not be created to parse through the leases for matches to the reservation list and purge them. Comes down to priorities I would assume. If you want it bad enough then put in bounty, is there a feature request for this? Check redmine and if not put it in. If the bounty gets high enough then sure someone will do the coding required to do that.
But once you understand that you need to make sure there is not an old lease be it from the client releasing it, or removing it at the server if you do not have access to the client at the time it really becomes a non issue.