So many config changes from WireGuard (and even more from pfBlocker if DNSBL is disabled)

[stephenw10]

Oh nope! But it is triggered by a package restart. So your system may not show it.

[Bob.Dig]

Now I took a look at some other machines (CE) and I can confirm, it is only showing it, if DNSBL is disabled. But damn, this sucks even more than with WireGuard.

@mcury Your not seeing WireGuard because your pfBlocker is polluting it so much more.

[mcury]

@Bob-Dig said in So many config changes from WireGuard:

Your not seeing WireGuard because your pfBlocker is polluting it even more heavy.

You may be correct about that, I'm now monitoring it and if I see something new, I'll report it here.

[mcury]

Enabling DNSBL fixed the problem with it saving configs.

As soon as I can, I'll reboot the firewall to check if I can see Wireguard showing up there.

[johnpoz]

@mcury said in So many config changes from WireGuard and even more from pfBlocker if DNSBL is disabled:

Enabling DNSBL fixed the problem with it saving configs.

That is good to hear.. I will know prob 2300 central tonight, when my cron kicks off..

[johnpoz]

No go for me - still doing it.. And its worse now.. now its doing 2

Lets see what happens today at 11..

[mcury]

I just got a chance to reboot today.

I got 22 new configurations..

10 during shutdown
12 during reboot.

[Bob.Dig]

@johnpoz said in So many config changes from WireGuard (and even more from pfBlocker if DNSBL is disabled):

No go for me - still doing it.. And its worse now.. now its doing 2

This helped in my case... where I didn't use DNSBL

But it looks almost the same to where I do use it, probably an older config.

[johnpoz]

@Bob-Dig hmmm - maybe I will completely remove it, and wipe the config. I only have a few aliases so should be easy enough to reproduce.

[JeGr]

@johnpoz @stephenw10

The problem with pfBlockerNG and config saves is even bigger as that many MANY configuration changes are all SYNCED to a CARP member triggering a HUGE number of unnecessary reloads and changes on the secondary node. And as pfBNG doesn't really sync the lists but the config only, the second node still has to run its own instance of pfB and do the whole download and install of the lists AGAIN, so you nearly have double the config changes to the standby node. Also in a bigger setup you have to either completely disable the sync because of this or you have to time the standby node down to do updates e.g. only daily or all 12h as otherwise you get hit with the sync job that triggers a reload of MANY services of the standby node, then have the node perform its own pfB download and saving configs. So config history is completely broken and unusable in a cluster where pfB is enabled as you won't see anything older then a day or two with that many checkpoints. Also the sync adds even more on the standby AND triggers high load and temporary RPC/sync unavailability as the node gets simply swamped by syncs and reloads (talking about a big node here with many VPNs, big ruleset etc. - datacenter firewall). That's a really big minus of pfB currently. I already mentioned that to BBcan/Tony several times but never came to tackle down the issue (with various others concerning a CARP setup like the interface creation in DNSBL mode etc.)

Cheers