Bug 250780 - net.pf.request_maxcount doesn't work in loader.conf after upgrade to 12.2
Summary: net.pf.request_maxcount doesn't work in loader.conf after upgrade to 12.2
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-pf (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-11-01 15:27 UTC by nicola.delluomo
Modified: 2021-01-07 20:37 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description nicola.delluomo 2020-11-01 15:27:12 UTC 
Hi,

after I upgraded from 12.1-RELEASE to 12.2-RELEASE pf stopped working @reboot complaining my tables are > than the limit.

In effect, by checking with sysctl, I found out that the custom limit set in /boot/loader.conf is not loaded anymore at reboot, so I fall back to defaults.

If I set it manually from command line

# sysctl net.pf.request_maxcount=300000

# pfctl -f /etc/pf.conf

everything works fine.

Here's my loader.conf file.

security.bsd.allow_destructive_dtrace=0
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
opensolaris_load="YES"
zfs_load="YES"
net.pf.request_maxcount=300000
machdep.hyperthreading_allowed=0
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
hw.mds_disable=1
Comment 1 Kristof Provost freebsd_committer 2020-11-01 15:35:35 UTC 
I've not gone digging through SVN to confirm 100%, but I suspect that's because net.pf.request_maxcount is no longer a tuneable, but can now be changed at runtime.

I'm not sure there's anything I can do here.
Comment 2 nicola.delluomo 2020-11-01 15:43:47 UTC 
(In reply to Kristof Provost from comment #1)
I do hope it's still a tunable: otherwise how can you start pf at boot with bigger tables?
What's the point in not allowing to tune it at boot?
Comment 3 Kristof Provost freebsd_committer 2020-11-01 17:20:54 UTC 
A tunable is merely a sysctl variable that can only be set at boot time.
Set your sysctl flags in /etc/sysctl.conf, and ensure sysctls are re-loaded after loading a module. Or load the module from /boot/loader.conf and then the startup sysctl load will take care of it.
Comment 4 nicola.delluomo 2020-11-01 22:12:41 UTC 
Thank you for your reply!!!

If you're right about net.pf.request_maxcount not being a tunable anymore, I think this would deserve documentation (perhaps under pf.conf), as it'd be an important change from 12.1-RELEASE to 12.2-RELEASE which could lead to (undetected) firewall failure.

I've been using FreeBSD for quite a while now, but I've never tuned boot sequence: the matter here is that if I define net.pf.request_maxcount in /etc/sysctl.conf, pf is started before sysctl.conf.

So I end up without a working firewall configuration (in fact firewall config is not loaded at all because of this error), but with sysctl set as I meant.
If I'm not mistaking, I'd need sysctl to be loaded before pf, not after.
Did you mean I should manually load pf.ko in /etc/loader.conf?
Can you give me an example of how I could set the correct sequence?
Do you think this could lead to security problems?
Comment 5 lexxai 2020-11-11 23:50:52 UTC 
Wow, same trouble on updated firewall server.
For me solution only change startup script for pf:
/etc/rc.d/pf

pf_start()
{
        sysctl net.pf.request_maxcount=200000
...
Comment 6 nicola.delluomo 2020-11-25 10:17:55 UTC 
Hi,

I fear modifying /etc/rc.d/pf is not a viable solution as it's prone to updating with system update (or upgrade).

Can somebody suggest how to solve this?

I do think many firewalls assign tables bigger than standard limit.
Comment 7 Kristof Provost freebsd_committer 2021-01-07 20:37:42 UTC 
Fixed in 3420068a73e554b30a86f9327b1a63f40e3b4568 (main) and 08d13750ebdae45bcdb73d52665b823e9ba93db1 (stable/12).