The anchor-based approach for time-dependent rules is elegant. Most people would reach for a cron job that rewrites firewall rules on a schedule, but using pf anchors keeps the state management inside the packet filter where it belongs. The key advantage of pf over iptables for this kind of use case is that rule evaluation is deterministic and the syntax stays readable enough to audit six months later without documentation archaeology. Nice to see OpenBSD used for practical home network management instead of just theoretical security posturing.
I had to make something like this at work once (allow access during some hours deny it at other times. and they wanted it enforced at the packet level) and I was a new sys-admin and all I had was an old linux box with iptables. It was ending up as the normal iptables mess until I asked myself "self: how would pf do it?", "anchors. I said, pf would do it with anchors" and I did it that way. well as much as possible. It was by far my cleanest work with iptables.
It has been a while since I have had to mess with iptables but if I remember correctly(quickly reads the iptables man page) the equivalent to pf anchors in iptables is to use named chains then you can faf about loading and unloading the dynamic rules from the chains without messing with the static rules.
The whole thing really made me appreciate the design of pf. I think, strictly speaking, iptables is more capable than pf, but pf and openbsd in general, is far more ergonomic.
> The key advantage of pf over iptables for this kind of use case is that rule evaluation is deterministic and the syntax stays readable enough to audit six months later without documentation archaeology.
Is iptables not deterministic? Don't the packets look at each rule in numerical order until something matches? If you have two rules with the same number, shame on you.
Re archaeology, OpenBSD changed the rules syntax for some reason and the other platforms with pf kept the existing syntax, so that's always a fun game to play.
I think the issue is if you are dynamically updating the rules then you might have an intermediate state where some packages are processed according to some set of rules which is neither the set of rules at the start nor at the end. Wheras with anchors you can flip between different sets of rules atomically. (though I suspect you can do the same with iptables but it'll called something different)