So many config changes from WireGuard (and even more from pfBlocker if DNSBL is disabled)
-
@johnpoz said in So many config changes from WireGuard:
@mcury all I did was enable it, but leave everything disabled or not configured.. You could try that since yours is doing it every hour, then in a couple hours we should be able to tell if that fixes the problem. If it does it would be really odd.
Enabled DNSBL and ran an update, it is up and running.
I'll be monitoring it and will report soon.DNSBL groups as per below:
dead on arrival, nowhere to be found.
-
@mcury said in So many config changes from WireGuard:
If there is something that I can do to help, just tell me.
Install WireGuard.
Btw Devel has bugs, nondevil is more up to date nowadays.
-
-
@Bob-Dig said in So many config changes from WireGuard:
@mcury said in So many config changes from WireGuard:
If there is something that I can do to help, just tell me.
Install WireGuard.
Wireguard is installed and enabled, but this problem is not happening with it, just with pfblockerNG
-
@mcury said in So many config changes from WireGuard:
Wireguard is installed and enabled, but this problem is not happening with it, just with pfblockerNG
WTF
-
Wireguard only does it at boot though and pfBlocker when a cronjob fires I think.
-
Oh nope! But it is triggered by a package restart. So your system may not show it.
-
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.
-
@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.
-
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.
-
@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..
-
No go for me - still doing it.. And its worse now.. now its doing 2
Lets see what happens today at 11..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
I just got a chance to reboot today.
I got 22 new configurations..
10 during shutdown
12 during reboot. -
@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.
-
@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.
-
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
