On 5/11/22 3:32 PM, Tom Smyth wrote:
Hello Folks,
We are updating some course material for an upcoming PF firewall course,
and I would like to put a call out to those who use PFsync in a
redundant firewall cluster
about your user experience, have you come across any edge cases?
have you any tips or tricks about PFSync.
have you come across any edge cases / minor misconfigurations /
suboptimal configurations that caused problems, were there some tweaks
you had to make to make your system scale ?
it is likely that people who are running PFSync have more complicated
firewall configs.
and I would like to see what tuning other people have done in the field.
It's been a few years since I managed a firewall cluster with pfsync, but
one thing I came up with fairly early on is we needed a way to manage rule
changes between the two devices, and I came up with something that I think
is pretty cool, and yet haven't seen anyone else describe something
similar.
Wrote a little script which, when run:
* Compared this script on "this" FW with "Other" FW
* generated a diff between the /etc/pf.conf file on both systems
(other box assumed to be "old", "this" box assumed to be new)
* Put the diff into a file along with the user ID of the administrator who
made the changes, prompted the user to enter a description for the change
above the diff, who approved it, etc.
* If the administrator enters a change log and saves the file:
* save that file to disk, with a clear date and time stamp.
* Copy "this" FW's pf.conf file to the "other" system
* pfctl -f /etc/pf.conf on both systems
* scp the change log file to the other system
* Probably should look for changes in hostname.*, and deal with their
changes, too, but I didn't implement that at the time, so I'd be lying
if I told you I did. But I recall wishing I had! :D
This way, you have a log of every change made to the system, plus
administrator comments as to why the change was made. EITHER FW can push
changes to the other, both boxes have a full history, either box can be
used to rebuild the other. IF you find a problem, a diff to undo it is
easily found. It makes change control almost a pleasure. If someone
made a change and forgets to push it to the other, you can see that the
diff is more complicated than you expected (or you made a typo and blew
something out!).
I've used similar scripts for other fully redundant systems, like DNS
servers. Yes, I'm sure you can do similar things with system management
applications like puppet, etc., but this is completely self-contained,
no extra hw or packages required. (and yes, DNS has the master/slave
config with zone transfers, but I'd argue this is a better system.)
Nick.
