pfSense

Not able to replicate, tested on

24.11-RELEASE (amd64)
built on Wed Nov 20 13:41:00 -04 2024
FreeBSD 15.0-CURRENT

1)Set Deny Unknown Clients to "Allow known clients from only this interface"
2)Save
3)Set Deny Unknown Clients to "Allow all clients"
4)Save

the client is able to get the IP.

Lev Prokofev wrote in #note-1:

Not able to replicate, tested on

[...]

1)Set Deny Unknown Clients to "Allow known clients from only this interface"
2)Save
3)Set Deny Unknown Clients to "Allow all clients"
4)Save

the client is able to get the IP.

I'm able to reproduce. I'm, on PfSense+ latest version... 24.11

Jim Pingle wrote in #note-3:

Sounds more like something is keeping your daemon from reloading with the new settings, not a bug specific to that particular option. There have been a couple reports of similar issues but nothing definite and repeatable has been identified thus far.

Please post on the forum for assistance, or contact TAC if you have a subscription.

Jim,

Not sure how that isn't a bug then. I have a standard setup, nothing fancy with regards to the network using the DHCP server. I have changed this setting before in older CE versions when I need a temporary client on an otherwise locked down network. I really think there is a lot of gremlins with KEA still because I find weird stuff like this since the move from the old DHCP server before KEA.

But whatever, a reboot fixes it. So hopefully my post helps someone else scratching their head and seeing nonsense in their logs.

I upgraded to PfSense Plus some time ago to support Netgate staff not because I need the Tac Subscription but to pay for the work I know that goes into this is a lot and I appreciate the contributions upstream to BSD as well and I don't believe in freeloading. I prefer to use my own hardware because I can customize it.

Regards, and Happy New Year.

It's not a bug with this setting as stated, and there isn't enough information here to identify what that actual underlying bug might be, hence it being incomplete and the need for additional troubleshooting. And Redmine isn't the place for that discussion and diagnosis to happen.

If we can identify the underlying issue and replicate it in a lab setup, we can either adjust this or open a new issue with more accurate information.

Jim Pingle wrote in #note-5:

It's not a bug with this setting as stated, and there isn't enough information here to identify what that actual underlying bug might be, hence it being incomplete and the need for additional troubleshooting. And Redmine isn't the place for that discussion and diagnosis to happen.

If we can identify the underlying issue and replicate it in a lab setup, we can either adjust this or open a new issue with more accurate information.

So making a change like a normal user would do that then stops clients from getting IP addresses until the firewall is restarted, when this never happened before the implementation of the still known to be buggy KEA-DHCP server, isn't a bug and should be posted on a forum instead.

Got it. Didn't realize that bugs had to be classified as actual bugs before being reported as bugs even though they look like and act like bugs.

Cheers, I won't report any more critters until someone else reports them because apparently you can't re-create it in a lab so it must not exist in the wild.

Alrighty then. Off to do more important things than try to help.

The issue is we do not have enough information to act on anything stated here. I'm not saying it didn't happen, or there isn't a problem, I'm saying you're likely chasing a symptom of a root cause that has not yet been sufficiently identified. We can't replicate the problem so we have no leads on how to address it without more data.

To find that root cause we need to diagnose the problem in more detail and find a way to replicate the problem. This issue tracker is not a discussion platform suitable for that process, the forum is.