pfBlockerNG sync not working
-
@vavsaftoiu Interesting, I haven't used the manual patch, but from what I can see the manual patch is doing the exact thing that BBCan did for the official fix, so maybe I've got something else going wrong?
It does list HA Sync = done in the logs when doing a manual reload, but absolutely nothing is syncing over. HA is working otherwise and was fine even with pfB in the past.
I'll do some more digging to see if I can figure out what is going on.
-
@planedrop
i have extended my comment: https://forum.netgate.com/post/1108304 -
@juliokele Thanks for this, I'll try to reinstall pfB to see if that helps, reboot has already happened and I actually never applied the manual patch.
-
Hey guys,
after applying pfblockerng non-devel update 3.2.0_6 to my _5-install sync still did not work.
Unchecking the button "Keep Settings", saving and reloading and then reinstalling the package on my backup-machine followed by a force reload on the master machine did the trick and now the sync works smoothly. Reboot was not necessary on neither my master nor my backup machine.
Thanks folks!
-
S SteveITS referenced this topic on
-
B Bob.Dig referenced this topic on
-
@juliokele said in pfBlockerNG sync not working:
pfBlockerNG-devel
Is there any news on when this will be fixed for "pfBlockerNG-devel"?
-
@Bruce74 said in pfBlockerNG sync not working:
Is there any news on when this will be fixed for "pfBlockerNG-devel"?
Semi-related question, what is the future of pfBlockerNG-devel? When 23.01 came out pfBlockerNG and pfBlockerNG-devel were made the same code. So we just switched to non-devel as (vaguely) suggested in the release notes. My general assumption was they would not differ going forward, but apparently they are already diverging in minor ways.
-
@SteveITS just updated to pfSense 2.7.2 and this brough me to pfBlockerNG_devel 3.2.0_7 and still had to manually re-apply the fix so definitely not fixed on latest Devel version either. Should devel version be patched by now or should we consider switching to the non devel branch?
-
I updated to pfBlockerNG-devel 3.2.0_7 a couple of weeks ago, and it fixed the sync issue for me.
-
@Bruce74 That's weird, I just updated pfSense from 2.7.1 to 2.7.2 and naturally pfBlockerNG-devel from 3.2.0_6 to _7 and it didn't fix it for me, I had to re-edit the .inc file and remove the additional 'd' again (I didn't apply the patch file, just patched it by hand).
-
@IT_Luke I always struggle a bit to find things in Github but comparing
https://github.com/pfsense/FreeBSD-ports/blob/734989ab5809fe5c7bde23a240e717da656775ac/net/pfSense-pkg-pfBlockerNG/files/usr/local/pkg/pfblockerng/pfblockerng.inc#L10826
and
https://github.com/pfsense/FreeBSD-ports/blob/734989ab5809fe5c7bde23a240e717da656775ac/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/pkg/pfblockerng/pfblockerng.inc#L10826...the latter does not have the fix:
$pfb_sync = config_get_path('installedpackages/pfblockerngsyncd/config/0', []);I made a note in the redmine.
-
@IT_Luke I'd recommend swapping over to the non devel version, which does have the fix applied like @SteveITS mentioned.
I did want to note something though, for me the fix had to both be applied by updating pfBlocker, and then I also had to reinstall pfBlocker on both HA nodes to get the sync to work again (keeping settings so it really was just clicking the reinstall button in the package manager). Been perfect ever since but a little odd it required that.
-
@planedrop I think I'll wait until the Redmine gets processed/picked up - I have no problems after manually patching the .inc (again), my HA installs sync fine after so no worries. In the event of another pfBlockerNG-devel update I know what to check so it's not a big deal, it's a very fast manual fix. If in the end the devel branch gets "left behind" I will uninstall and reinstall the "normal" branch. Cheers anyhow!
-
@IT_Luke Totally get ya on this. If it's useful, I was running devel and reinstalled non-devel on about 8 firewalls and it went super smooth, settings were kept, basically didn't even know it changed. Not as encouragement to do so, just that if you come to the conclusion you need to, should be pretty simple/fast/easy.
-
subbed to the thread in the hopes that an update will be posted here when this has been resolved.
-
@shabsta The issue is resolved in the latest pfB release, you'll have to do a reinstall of the package on all HA nodes for the fix to actually work though.
-
@planedrop said in pfBlockerNG sync not working:
ou'll have to do a reinstall of the package
I disabled and reinstalled pfBlockerNG on second pfsense server and this resolved the issue, thank you.
-
I ran into a sync issue today.
23.05.1, pfB 3.2.0_5 - found changes didn't sync, or at least show in the GUI, with the patch, without the typo.
Restarted router2, same.Upgraded both to 23.09.1, pfB 3.2.0_7. As part of that, uninstalled pfB and reinstalled after.
Same, a description wouldn't sync.Reinstalled the package on router2 (via the button on the Installed Packages page), no sync.
I ran a Force Reload on router1 which then got the changes to show on router2.
In hindsight this sounds more like linked issue https://redmine.pfsense.org/issues/12918 (pfBlockerNG-devel changes from xmlrpc sync do not take effect immediately ...until cron job is run on router2).
-
@SteveITS I thought this delay was normal, my understanding was we had to wait for a reload to happen before things would sync to the other side, maybe I'm wrong?
-
@planedrop That would be very unlike all the other package config syncs. Given the Redmine which labels it a regression, it seems like it’s just not been working. IOW the sync ought to trigger a reload if anything changes. Otherwise a failover could, say, cut off admin access because an alias doesn’t exist.
-
@SteveITS @planedrop From my experience with pfB, I have always triggered a force reload whenever a major change has occurred on the master node (interface changes or similar in config) - this always ensured the secondary has all the changes. I then verify on the slave node if this is the case. Whenever there is a pfB update or a release update I trigger a reload (not necessarily forced) as the pfB state appears often yellow and that sorts it. I see "config replicas" being pushed only at cron update time or manual update. As the pfB XML sync is triggered hourly I don't see how any interim config change would immediately trigger a sync to the slave - it has never happened in my case at least and I believe this to be the normal behavior as this sync is handled in a complete seperate and indipendent way than the HA sync which does get automatically pushed at every config change. If you do make a modification to any list or rule in pfB and the node goes down before the hourly trigger, that list mod is not replicated to the slave(s). In any case, after any release update or pfB update, I always have issued a forced reload as pfB is reported in a "yellow" state. Regarding the typo patch, I have had to uninstall and reinstall pfB-devel and force reload after again patching on the master node to get it to sync to the slave again as somehow it was not picking up the config change (?!) - but this happened only on one HA pair.
On an additional note regarding the CARP interface selection in pfB which I have stated elsewhere too: when selecting the CARP interface in pfB (so not the default VIP), it is configured as a /32 IP. BSD does not really like this as the iface is not really "up" until you reboot - only then it appears listed properly in the CARP ifaces (else it neither is master nor slave, it's a ghost). However if you manually set the iface as a /29 for ex, it immediately goes up and is properly reported. However on every pfB hourly trigger it reverts to a /32 as this is what is specified in the .inc file (yes I did edit it and that works too). It is not a major issue as after a reboot once it goes up as a /32 it stays up, but maybe it is probably better to assign it a /30 or /29 subnet (how many nodes can one have?) so BSD is happy (being a CARP iface it is advertised as such and it's state is seen by the other node...).
