Its a reasonable start.<p>It provided an example of a static nat forwarding for incoming traffic.<p>Another common task is blocking certain outgoing traffic<p>block return out quick on egress from any to any port smtp<p>to block all outgoing email if your internal machines are all windows (to block spambots or whatever).<p>Or to block outgoing traffic from one device (perhaps your laser printer, or abandoned smart TV, or an "internet of powned things" device).<p>block return out quick on egress from 10.1.2.3<p>You can have huge fun with tables. So make a table of addresses to block from the internet (much like the martians table in the example), and a pile of crontab that pfctl add and pfctl delete the kids i-devices around bed time or homework time or whatever.<p>As a starter, its pretty good, but there should be commentary on troubleshooting tools. Here's the care and feeding of the log command to figure out what you're actually doing vs what you think you're doing. Here's how you see the current NAT table using pfctl, stuff like that. As with many security issues, its easier to enable uPNP than it is to correctly debate if you should enable uPNP, its easier to enable your whole lan to access the internet rather than blocking the laserprinter, so that's a fun topic in general.<p>Also it's been a tradition in linux and presumably bsd software firewalls since the mid 90s to add endless complication and logging that serves no useful purpose and is never examined or acted upon after installation until a hardware limit for hardware of that year is reached, then complain software firewalls are too slow and maybe a couple years of hardware advances will make them practical, repeat endlessly. You can shove a couple megs/sec using a 486, I certainly did in the 90s, although you can also clutter up a top of the line desktop today such that the CPU and disk IO will flood about a couple hundred K if you try hard enough by writing every packet to disk and having pages of firewall rules.