Pf debugging

General Notes

• Remember that pf is a stateful firewall.
  If an ip has been blocked, then you add it to a whitelisted table - it will remain blocked until you execute pfctl -F all -f /etc/pf.conf

• Remember that pfctl -F all -f /etc/pf.conf will clear rules AND tables.
  You may need to recreate table entries BEFORE access is attempted, and marked for blocking

• Use sudo tcpdump -n -e -ttt -i pflog0 port 5555 to watch blocked traffic.
  If that does not work, check the actual interface for clues.

• If using vnet jails, remember that there are 2x layers of pf. One for the host, and one inside the jail.

pftop

See pftop

pflog

pflog service won't start

You'll know the problem if:

tail -f /var/log/daemon.log  # watch for reason
# Failed to initialize: pflog0: (there are no BPF devices)

## OR

tcpdump -i pflog0
# tcpdump: (there are no BPF devices)

My problem was twofold.

1. I had assigned my FreeBSD devfs ruleset the number 5, which was an existing default ruleset. Changing to 100 properly loaded the ruleset
2. I needed the additional rule add path 'bpf*' unhide

See

• https://lists.freebsd.org/pipermail/freebsd-jail/2013-February/002073.html
• https://yom.iaelu.net/2019/03/freebsd-12-vnet-jail-using-bridge-epair-and-pf/
• https://forums.freebsd.org/threads/sngrep-doesnt-work-in-jail.87315/

Tricky Connections

# first line of defense is always tcpdump
tcpdump -n -e -ttt -i pflog0     # log blocked packets
tcpdump -n -e -ttt -i en0        # packets on en0
pfctl -s states | grep 10.0.0.1  # show tcp states on packets related to 10.0.0.1