Synopsis #
PF evaluates translation, filtering, state, interfaces, and anchors as one packet path. A syntactically valid rule can still block administrative access or publish a service on the wrong address. Remote firewall work therefore needs a known recovery channel, a preserved ruleset, an independent session, and observable acceptance criteria.
This guide supplies a change method, not a universal ruleset. Existing hosts may use Bastille anchors, dynamic tables, VPN interfaces, failover addresses, or provider-specific console access that a generic file cannot preserve.
Understand the path being changed #
Write the intended flow before editing:
source -> receiving interface and address -> translation -> filter -> local socket or forwarded destination -> return route
PF is stateful. Existing SSH traffic can remain in a state even when a new connection would be blocked. A surviving administrative session therefore does not prove that the new rules admit replacement sessions.
Anchors are part of the active policy. A base ruleset that omits rdr/* or bastille/* can disable dynamic Bastille mappings even when the top-level filter looks correct. Review Publish a Bastille service through PF
when jails are involved.
Establish recovery first #
Before editing a remote host:
- Confirm a working console, out-of-band terminal, or another authorized administrator.
- Keep two independent SSH sessions open.
- Preserve the exact active configuration and any included files or anchor loaders.
- Record the interface, source network, destination address, and management port.
- Define the command that restores the previous file and reloads it.
Do not perform the first PF change on a host that has no tested recovery path.
Capture current evidence #
Record configuration and runtime state:
# cp -p /etc/pf.conf /etc/pf.conf.prechange
# pfctl -sr
# pfctl -sn
# pfctl -sa
$ netstat -rn
# sockstat -4 -6 -l
pfctl -sa can be large and may expose internal addressing. Store it with the change record rather than posting it without review.
Validate before loading #
Check the candidate file without changing the active rules:
# pfctl -nf /etc/pf.conf
Review the expansion and ordering of the loaded rules where macros, tables, and anchors make the text ambiguous. Syntax validation confirms only that PF can parse the file. It does not confirm DNS, interface names, route symmetry, or remote access.
Load the candidate from the first session while leaving the second session idle:
# pfctl -f /etc/pf.conf
Immediately open a third, new administrative connection from the expected source. Exercise privilege escalation and keep it open. Then test the changed service from the intended client network.
Observe the actual match #
Use states and counters instead of guessing:
# pfctl -ss
# pfctl -vvsr
# tcpdump -ni em0 host 192.0.2.10
Replace the example interface and address. Packet capture should be as narrow as possible and stopped after the test. No packet on the receiving interface is an upstream routing or address problem, not a PF rule problem. Packets without an expected state point toward rule matching; states without replies point toward the listener or return path.
Roll back on uncertainty #
If a new administrative session or acceptance test fails, restore the preserved file from the still-working session or console:
# cp -p /etc/pf.conf.prechange /etc/pf.conf
# pfctl -nf /etc/pf.conf
# pfctl -f /etc/pf.conf
Do not keep adding broad pass rules to a failed change. Restore the known state, collect evidence, and revise one layer at a time with Diagnose DNS, routing, and firewall paths
.