Now, finally, you have isolated the problem, and I was able to replicate it on a -release test system.
The rc(8) subsystem sets default rules in the event your pf.conf fails to load. Those are the rules you see when securelevel is set to 2.
The sysctl values in sysctl.conf are set early in the rc(8) process, as kernel settings need to be provisioned before daemons are launched.
If you set kern.securelevel=2 in /etc/sysctl.conf, rc(8) operations for PF that follow later in the process will fail, because PF cannot be altered. Your configuration cannot be loaded. This is because the securelevel(7) restrictions are already in place.
Fix:
- Do not set kern.securelevel=2 in sysctl.conf
- Issue the sysctl command *after* PF has been provisioned. Use rc.local(8) as that is executed much later in the rc(8) process.
Step-by-step instructions for Peter:
1. EDIT /etc/sysctl.conf. Delete the line that sets kern.securelevel.
2. CREATE /etc/rc.local, with one line that executes the "sysctl kern.securelevel=2" command. Either use an editor, or use echo(1) and pipe the results into a new file, such as shown in the example below.
# echo sysctl kern.securelevel=2 > /etc/rc.local
----
I will consider whether I will submit a patch for the securelevel(7) man page to the Project to clarify rc(8) implications. If I do, I'm not sure it would be accepted. Peter missed error messages on his console produced by rc(8), including failures to load his PF rules, that should have immediately indicated a configuration problem when he set kern.securelevel=2 in sysctl.conf.