DHCP - No Free Leases (pf_2.4.3-release-p1)

[iHugoF]

I tried to change file by shell and kill/start process, after deleting all leases and no luck...
To be "Expired" leases are marked with "24h"...even if the max-lease-time and default-lease-time is set to 3601 and 3600s.
If I restart process via GUI, file is always overwritten...

Where is it getting the configs from?!

Even if I remove file permissions, it chowns and chmods the file again with the right ones...

[johnpoz]

If you want to edit something in a conf you have to edit the services.inc file since yes this is what creates conf on service start, etc.

https://github.com/pfsense/pfsense/blob/master/src/etc/inc/services.inc

$dhcpdconf = <<<EOD
option domain-name "{$syscfg['domain']}";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;
option arch code 93 = unsigned integer 16; # RFC4578
{$custoptions}
default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
one-lease-per-client true;
deny duplicates;
ping-check true;
update-conflict-detection false;
EOD;

[Gertjan]

@ihugof said in DHCP - No Free Leases (pf_2.4.3-release-p1):

default-lease-time 7200;
max-lease-time 86400;

default-lease-time 7200;
max-lease-time 86400;

are global time out values.

Every pool has its own, pool-specific settings, like in your case :

       default-lease-time 3600;
       max-lease-time 3601;

[iHugoF]

@johnpoz

You're the best! :)

It's seems to be that!

I've changed the services.inc and now the expiration time of the leases make more sense!

It still went and got some for tomorrow, that I don't know how, since I deleted all the leases...but lets wait and see of this does the trick!

Many Thx! :)

[iHugoF]

@gertjan

I know, but for some weird reason, it is considering the global values...not the pool ones...
After editing the services.inc like @johnpoz said, now the leases will expire, as they should, in 3601s.
Before it was assuming the 24h of the global value, and for the number of users I have, it just doesn't do, since I've more than 8190 different users, in a 24h period.

How come no one had this problem before?
Or maybe no one noticed it...:)

I'll let this run for at least 24h, to see if the problem is solved.

Thx!

[Gertjan]

@ihugof said in DHCP - No Free Leases (pf_2.4.3-release-p1):

How come no one had this problem before?

Good question. Dono what the problem is.

My LAN :
Setting :

Or : default lease time one day, max lease time 4 days.

This is a device on LAN, an iPhone, came in this morning :

It has a lease of 4 days => ok.

On my captive portal - another LAN, another DHCP server - another pool:

default lease time = 6 hours - max lease time 12 hours.

Hummm. 12 hours, so ok.

dhcpd on my two interfaces respects de duration as I set it.

[iHugoF]

@gertjan

Maybe it's the number of different clients I have...

But it started happening again...
Some leases are being kept for 24h...:-/

Most of the leases are like this...and they will not be reused until they expire, 24h later...:-/

Thx!

[Gertjan]

@johnpoz said in DHCP - No Free Leases (pf_2.4.3-release-p1):

etc/inc/services.inc

You checked the dhpcd conf file after edeting the source, and restarting dhpcd ?

default-lease-time xx;
max-lease-time yy;

did change ? For both the defaults and pool's version ?

If you have a DHCP request coming in every 10 seconds with a lease duration of 24 hours : what about making a bigger pool , like 10k entries ?

But .... I guess we all agree, some how I can't find out what is the real issue here.

Can you wireshark, and test if some devices "hailstorm" the dhpcd with requests (DHCPDISCOVER, as mentioned above) ?
Google informed me that a theory I have really exists : https://www.information-security.fr/fonctionnement-et-protection-contre-les-attaques-dhcp-starvationrogue/ (not the right language .... but you will get the picture )

[iHugoF]

@gertjan

Yes, it did indeed change the lease times on config file, although it's inserting the configurations outside the pool {}, which is normally where they as supposed to be.
It's inserting them in the subnet {} but that seems to be fine for most clients.

Really can't see where the problem is coming from, since if I start using the dhcpd of another linux box or cisco router, there's no problem...hence thinking the problem is somewhere how pfsense / freebsd configured the dhcpd behind the scenes.

I can't have a bigger pool, since this subnet it's already defined and would clash with other subnets in use.

I checked today and I've like 6000+ abandoned leases and from what I know from dhcpd, these are not used until all the expired ones are used.
The abandoned leases are the ones being marked with a 24h expiration.

[iHugoF]

Still no luck, but figured that the problem is related to the abandoned leases and they all come from a specific wireless controller (3Com)...Yes, it's OLD! :)
But it all works well with Cisco router DHCP...so, dhcpd shouldn't have any issues, but something it's not quite the same...

[msf2000]

It's a bit of a radical idea... but have you considered splitting wired and wireless users into different subnets (or different DHCP scopes)? Divide & conquer to find the problem, is my motto.

Either way... I agree that the lease abandon rate is pretty high... This feels like an (OSI) layer 2 problem somewhere in the network, but I don't know enough to say what it could be.

[iHugoF]

@msf2000 It has all been divided...:) This is just 1 subnet, were I'm testing pfSense, and it's just for wireless guest clients.

For all the other subnets, we've other dhcp servers and no issues, hence I'm being puzzled with dhcp on pfSense acting like this...

I've never seen this dhcp behavior on any other dhcp servers...:-/

[johnpoz]

So the controller is doing a dhcp relay? You mention that all the leases are from the controller?

Where are you getting that listing of leases and times? The dhcp lease table should show host and mac, etc.

[iHugoF]

@johnpoz No, no need for dhcp relay, since the controller wireless network interface is on the same network/vlan of the interface of pfSense and yes, all the abandoned leases come from that specific wireless controller - 3Com.
I've other 2 Cisco controllers and no issues with those ones.

But you may be on to something, since I've noticed that all the clients leases that reach pfSense come with the controller name, and not the PC/Device name, even with all the mac addresses being different and such, but the client ID it's always the same = controller name/model.

I got the list from the pfSense DHCP GUI and from the dhcp logs, via CLI.

[johnpoz]

That is odd.. I have no experience with 3com controllers.. But why would pfsense not see the host-id from the client itself? Unless the controller is doing something with the dhcpdiscover/request?

[msf2000]

@ihugof said in DHCP - No Free Leases (pf_2.4.3-release-p1):

er subnets, we've other dhcp servers and no issues, hence I'm being puzzled with dhcp on pfSense acting like this...
I've never seen this dhcp behavior on any other dhcp serv

Is the 3COM wireless controller configured as a DHCP relay, or is it configured to just pass layer 2 traffic from pfSense to the clients?

[johnpoz]

^ yeah sounds like it my be relaying it??

[iHugoF]

@johnpoz Is odd since 3Com doesn't even have a dhcp-relay option...it only has dhcp-server on/off option, and it's off, so all traffic it's just pass through...

Abandoned leases happen when dhcp-server sends ICMP ECHO to client, before assigning a lease, so that would mean that someone or something is replying to the ICMPs and pfSense dhcp thinks IPs are being used and marks them as abandoned...
Once again...it's strange why only pfSense dhcp is doing this...
Until I find the cause of this, I set "abandon-lease-time 3600;" so it doesn't have to wait 24h to clean it...
Hope that can fix it until a more permanent solution...:-)

[iHugoF]

@msf2000 No relay option, just letting the traffic pass...:-)

[iHugoF]

Errr...pretty damn dumb....but I just realized that the 3Com was badly configured...LoL
That's the problem of trusting someone else...:-)
You should always check yourself!!!
3Com was configured as a /21 when the network is a /19 and the interface as a dhcp client of the network itself.
Besides all this, the interface IP on another interface, was overlapping my subnet...
I'll wait and see if this was the problem...but I'm starting the clients from 3Com arriving with the proper device name and not the 3Com device name.
I still see some abandoned leases, but it set the timeout for 300s now, to check if that does it...
Really hope that "this was it" coz this was making me go crazy! :-)