Pf

If you're using the OpenBSD's pf, which also works on FreeBSD, make sure it's enabled.

# pfctl -si
Status: Enabled

I've been bitten by this while debugging.

# pfctl -N -f /etc/pf.conf

This will reload the nat rules only.. often best to disable the firewall rules when testing nat, so do

# pfctl -Fr

to flush the rules, and just

# pfctl -R -f /etc/pf.conf

to use them again.

# pfctl -Fs 

to flush the current nat states, just remember the existing natted connections will drop when you do this.

# pfctl -ss 

to show the current nat states.

in summary, -Fn the F means to Flush. -sn the s means to show. -N and -R are to load only the Nat or filter Rules respectively.

If you're satisfied with your pf ruleset, you might be interesting in looking into ALTQ. Alternate queuing (ALTQ) is a framework that allows to shape network traffic.

helpful rules for pf.conf

These can mostly be found by logging all of your block rules and then watching with:

# tcpdump -vvv -e -ttt -i pflog0

Once you see something you want to block, usually a reoccuring sequence, you can add a block rule without log enabled.

# block Microsoft Calendar
block in quick on $ext_if proto udp from any to any port {1024 1025 1026 1027 1028 1029 1030 }
# block nmap OS detection scans somewhat (-O)
block in quick proto tcp flags FUP/WEUAPRSF
block in quick proto tcp flags WEUAPRSF/WEUAPRSF
block in quick proto tcp flags SRAFU/WEUAPRSF
block in quick proto tcp flags /WEUAPRSF
block in quick proto tcp flags SR/SR
block in quick proto tcp flags SF/SF

Don't let the flags confuse you, the simplest way to block any sort of OS detection scans is to block anything and not return a packet. The scanner will only know that the packet never came back. You need to suit this with the blocking policy of your ISP though. It's interesting to find out when an IP is not allocated by an end-user whether the ISP's network access server reply anything in its place or whether the IP is blackholed. Early access servers showed a routing loop in a traceroute, my particular ISP blackholes non-used IP's. Getting to my point, if your ISP blackholes non-used IP's then using a block that doesn't reply anything shows no distinction whether there is a "live" computer behind an IP. If an ISP replies with some sort of packet perhaps the pf rules should be adapted to reply the same, so that a transparency appears.

---

Official PF page