Feb 5 2006

ipfw vs pf

I'm a pretty big ipfw fan, but it's getting hairier and hairier to deal with a complex ruleset. If you want to have nat, transparent proxy forwarding, 'pipes' (traffic prioritization) and stateful rulesets - you have to be incredibly careful with your ruleset crafting. To add to that, natd is fragile -- stable, but having your network at the mercy of a killable daemon is subject to human error, and scary.

Spime uses a database driven firewall, with a custom daemon listening for updates, and converting it all into ipfw syntaxed stuff. It needs to manage ruleset order, and do some tricky stuff to make sure customers don't notice updates. Why would someone notice an update? Because flushing rulesets kills dynamic states, dropping all existing connections. So I have to create a new disabled 'allow all' set with a check-state, enable it, delete all old rules in the 'real' set, update the real set, then switch sets again. This works great.... but holy crap.

I've been using pf at home for about 6 months, and finally decided to convert Spime over to it tonight. Having a centralized location for all firewalling, nat, and traffic QoS is great - having it work well is even better. Blacklisted hosts can come out of a persistent table file, and customer firewall rules can be anchored off the main ruleset, into a different file. I can update just the customer rules without worrying about states getting torched.