The PF firewall on FreeBSD: testing pf.conf with pfctl -n before loading it, and a scheduled rollback against SSH lockout

Goal

Write, test and load a PF ruleset on FreeBSD 14.x, and apply a change to a remote host's ruleset without risking a permanent SSH lockout.

Prerequisites

Root access; PF's kernel module loadable (built into GENERIC on FreeBSD, or kldload pf); an existing SSH session to the host being firewalled if the change is remote.

Steps

1. Enable PF at boot: sudo sysrc pf_enable=yes sets the rc.conf variable the Handbook documents for this. PF will not start without its ruleset file, and FreeBSD ships no /etc/pf.conf.
2. Write rules in /etc/pf.conf. pf.conf(5) documents block and pass as the two rule actions, evaluated in order with the last matching rule normally deciding the outcome unless quick is used; if no rule matches at all, the manual states the default action is to pass the packet, so an empty or misordered ruleset is not fail-closed by itself — the ruleset itself must end with an explicit default block if that is the intended posture.
3. Use anchors to attach separately managed sub-rulesets: pf.conf(5) describes an anchor as "a container that can hold rules, address tables, and" other anchors, referenced from the main ruleset by name and manageable independently with pfctl -a <anchor> -f <file>.
4. Before loading any change, parse it without applying it: sudo pfctl -nf /etc/pf.conf (or whichever file you are about to load). pfctl(8) documents -n as meaning "do not actually load rules, just parse them" — this catches syntax errors safely.
5. Only after a clean parse, and on a remote host only after step 6's safety net is in place, load and enable: sudo pfctl -e ; sudo pfctl -f /etc/pf.conf, the sequence given in the Handbook. When PF is first enabled, an SSH session opened earlier can drop: by default only a TCP SYN creates state (flags S/SA), so its mid-connection packets match no stateful pass rule.
6. Before changing rules over SSH, save the working file (cp /etc/pf.conf /etc/pf.conf.known-good), write the change to /etc/pf.conf.new, and schedule a revert: echo "pfctl -f /etc/pf.conf.known-good" | at now + 10 minutes (use pfctl -d as the revert when PF was not enabled before). Then load with pfctl -f /etc/pf.conf.new. at(1) is documented as the tool to "queue, examine or delete jobs for later execution." If SSH still works, cancel the job with atrm <job-id> (from atq) and copy the new file to /etc/pf.conf; if it locked you out, the job restores the known-good ruleset without console access, and a reboot would also load the untouched /etc/pf.conf.

Expected result

pfctl -nf /etc/pf.conf prints nothing and exits 0 on a syntactically valid file; after pfctl -f, pfctl -sr (show rules) reflects the new ruleset, and the scheduled at job, once cancelled, no longer appears in atq.

Limits and test basis

pfctl -nf only checks syntax, not intent — a syntactically valid ruleset that still blocks port 22 will parse cleanly and then lock out SSH. The scheduled revert depends on cron running: atrun(8) is started from the system crontab every five minutes, so the job can fire up to about five minutes after its scheduled time.