DHCP delete lease

We've looked into this, but decided not to implement it at this time. Since deleting a lease won't cause a client using that lease to give it up, this would be problematic without a lot of extra work. 

....and what if we already understand that, but have the need to do it anyway?

This is a pretty terrible answer. 

>This is a pretty terrible answer.

Sorry you feel that way, but it is an honest answer. There is almost no demand for such a feature, and the effort required to do it right, so that inexperienced users are protected, means we won't consider it at this time. 

Sorry AlanT, but JohnBerisford is right, this feature is really important and your answer is very BAD

best regards :)

MassimilianoDal Cero said:

this feature is really important and your answer is very BAD

Please help me understand why this is so important. I understand it's desirable, but what issues is the lack of this ability causing, that make this feature really important? 

Hi Alan :)
I try to explain the problem, in Sophos XG (as other devices) is possible assign a reservation to a MAC Address.
Ok, this works ... but only if the host is not already plugged to the network and DHCP has not sent to it a IP Address.

If XG send an IP to the device first to have fixed a reservation with MAC Address, this address remain fixed for a undefined time, though a reservation is done.

So is not possible disassociate client for receive a new IP reserved and this is a "big problem", I Can't recreate DHCP server and give a disservice to the network only why a client has not its IP.

An example: In our network, for security reason (obviously) only registered clients can exit on Internet, so if a client are locked to a dynamic IP assigned by the dhcpd this client can't exit until the association IP-MAC is released.


But in Sophos XG this release is not possible, so we are obliged to wait until the device decides to release the MAC address and assign to it the correct IP.

Best regards :)

MassimilianoDal Cero said:

Ok, this works ... but only if the host is not already plugged to the network and DHCP has not sent to it a IP Address.

Thanks for the reply, but that scenario wouldn't be possible even if the IP hadn't been given out already. XG (and most other DHCP servers) won't let you assign a static mapping inside of an assigned DHCP scope. So if I set the dhcp range from x.x.x.10 to x.x.x.20, then try to assign x.x.x.19 as a static lease, it will stop me - regardless of whether a client has been given that IP or not. Adding an option to forget dynamic leases wouldn't allow this.

Also, if x.x.x.15 was in use, and I wanted to statically assign it, I could split my DHCP scope into two - x.x.x.10 to x.x.x.14 and x.x.x.16 to x.x.x.20, removing x.x.x.15 from the dynamic IP assignment range, and I would be permitted then to statically assign it to a device. 

If I assign x.x.x.21 to a device, then want to change the device associated with that static lease, I can remove it and add a new static lease for x.x.x.21, or just change the MAC associated with the existing lease, without any restriction. it will just work.

The only problem scenario I can see, is if I assign a DHCP scope that is too small, and I run out of available addresses. In that case, my solution would be to either increase the pool size, or reduce the lease lifetime to allow clients to be forgotten faster, or possibly both. Perhaps at the time I discover the problem, it might be convenient to have a "forget" button, but as I can assign multiple ranges to the same lease, it should always be possible to address a problem. If the range is too small, just increase it. If the subnet is also too small, lower the lease time. Fixing it this way would be something of a one-time occurrence, for an issue that very few users ever run into, and once solved, should be unlikely to occur a second time. A forget button might momentarily solve a problem, but it would not stop it from happening again. I'm not against adding such a feature, but with proper priority. Right now, the requirement for this is very low, because of the reasons I've just stated, and it requires some effort to ensure it's safe to use in all cases. If there are more use cases that users are commonly running into, I'm not aware of them, and would like to know.

Alan:

I agree with others - this feature is needed.

For example, we implemented a RED appliance at a remote site - my laptop picks up the IP Config from that site, which has the default gateway as the IP of that Red Appliance.

Now, back in the head office, it keeps assigning me the IP Address i received at the remote site, meaning i cannot access many of our servers (including the VM Host of all our test machines)

With a "delete lease" button, this would be simple.

Now, i have to wait until the lease is gone, or put in a static IP so I can work properly.

Thanks

Hi Arie,

I have the same issue, when I plug a device first to assign a static IP is impossible to release it after a unpredictable time (even if I set the lease to 1 minute, it is not respected)

Is a not sens the need to split in multiple DHCP trunks to overcome this lack

Is not always possible split DHCP definitions, and the absence of forcing "delete lease" feature is a very serious lack

unfortunately I must adopt your same solution:
"wait until the lease is gone, or put in a static IP so I can work properly."

Hi Arie, thanks for the feedback. 

ARIE SOMMER said:

Now, back in the head office, it keeps assigning me the IP Address i received at the remote site

I think I'm missing something in the example you're giving. The use case you describe, isn't how XG operates today. If a device is issued a lease by one DHCP server on a firewall, then moved to another network on the same firewall, the firewall will automatically delete the first lease, and issue a new lease on the second network. There is no need to wait for the lease to expire. I rely on this behavior daily, but just did a test, moving a firewall repeatedly between dhcp scopes. With no changes or delays on the firewall, it promptly received a new IP on each connection, within seconds. The DHCP lifetimes were at defaults on both. In each move, the old lease was automatically deleted from the firewall, and a new one was added. 

This behavior doesn't change with RED involved, except that a RED network can be bridged to a local network. If that were the case, then it would be correct for the firewall to issue the same IP in both cases, and any access problems would not be due to the IP you received. 

Again, I'm not against adding this feature, and it is on the backlog - but it's so rarely necessary, that it's not been prioritized higher. I'm suspicious that there is some other reason (or reasons) the few of you wanting this feature are having any issues, and that adding this feature would not solve whatever issue is actually happening.