From: Alexandr Nedvedicky <sashan@fastmail.net>
Subject: Re: pfctl: fix resetting limits
To: Carsten Beckmann <carsten_beckmann@genua.de>
Cc: "tech@openbsd.org" <tech@openbsd.org>
Date: Wed, 19 Nov 2025 14:52:57 +0100

Hello,

On Wed, Nov 19, 2025 at 11:34:19AM +0000, Carsten Beckmann wrote:
> Hi,
> 
> I've noticed a few issues with pfctl that are caused by this change:
> 
> https://github.com/openbsd/src/commit/85baac77515140239632c5e733ba5c896915fadc
> 
> 'pfctl -F Reset' no longer resets limits back to their default because they are
> initialized with the currently active limit in pfctl_init_options now.
> 
> Because of that initialization limits are also "sticky" now. If you load a
> configuration that changes a limit and then load another configuration that does
> not specify that limit the old limit will be kept. This can lead to a
> configuration suddenly breaking after a reboot when the old limit is gone.
> 
> If we want to set limits as soon as we parse them we should use pfctl_load_limit
> instead of pfctl_load_options in pfctl_set_limit. This avoids side effects from
> other limits that may or may not yet have been parsed at that point. It also
> allows us to initialize options with their default again in pfctl_init_options.
> Unless I am missing something that should fix both issues I've mentioned while
> not causing a regression for the issue that the original change addressed.
> 

    I agree the diff is right solution for 'pfctl -f Reset'. I think the
    reset action should restore built-in default defined at compile time.

    I'm worried it may not work quite well when pfctl is loading rules
    to anchor (pfctl -a anchor -f anchor.conf)

    the way I understand it is what limit pf(4)/pfctl(8) should use
    when pf.conf does not mention that explicitly:
	it's compile time/built in default vs. the limit currently
	set in kernel driver.

    I need to think more about it. Perhaps your diff is the right thing
    to do. I will get back to you by the end of the week.


thanks and
regards
sashan