Hi Wiesław, Definitely support your desire to try to add more structure to your PF writing! :)
We use git to version control PF and many other files (over 60 files across an OBSD system now come to think of it). For PF, I wouldn't recommend using anchors as I *think* their slower and restricted in terms of options. You also want to be using tables if you want performance. Anyway, we wanted to create some structure too but opted for, instead of being too clever just using care and attention, always using 2 firewalls (running carp), and following PF's own 'skip steps' to define how we break our rules into different well defined groups within the PF file. Of course within the skip step group ordering you can also add whatever other rules you like. E.g. We always say rules with the higher QoS go above other rules within the same rule group. Doesn't make a difference in terms of actual QoS performance, it's just makes it easier for someone to come along and see where their new rule needs to be inserted, if their is a clear guideline to follow (which we leave commented in the pf file for reminders). If anyone has a clever way of managing it I'd be interested but simple guidelines seem to work well enough. PS; cannot encourage enough the benefits of two firewalls, honestly (esp if your sharing the management). It makes it so much easier to make a change to a backup firewall, switch to it gracefully, and check all is ok. then git pull your new PF on the previous firewall once your happy you don't have to roll back quickly. You won't loose any states or break any connections created by a previous a ruleset as pfsync will keep you happy. If new connections are failing on the new ruleset just switch back. Barely anyone will notice a thing if your quick about spotting a fatfinger issue. Cheers, Andy Sent from my iPhone > On 8 Apr 2014, at 19:47, Wiesław Kielas <[email protected]> wrote: > > Wiesław
