pfBlockerNG sync not working
-
@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...).
-
I had to rediscover this today. Non-devel version, 3.2.0_7.
For me:
Force Reload on router1 does sync.
Force Update on router1 does not sync.and
The XMLRPC timeout won't save if it's set to a value over 150 (it reverts it to 150): https://redmine.pfsense.org/issues/15158and
The XMLRPC Replication Target is required even if not using it: https://redmine.pfsense.org/issues/15159Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@SteveITS This is good info to have, thanks.
And meant to respond to your original thing from a month ago, my bad.
Agreed it a sync should trigger the reload if there are changes, seems pretty critical.
-
@SteveITS It was my understandng that only the force reload would sync to secondary (and of course the hourly cron event), at least that's how it has been behaving for me for the last few years. A Force update would never sync. This was in fact an abnormal behavior in my opinion due to exactly what you pointed out, but I thought it was like that "by design" (and initially got me baffled).
-
I'm on 3.2.0_7 pfBlockerNG-devel
Do we still need to apply the fix on the "patcher"?
It looks like it won't sync without it...
-
@fmroeira86 on 3.2.0_7 pfBlockerNG-devel: yes
-
@fmroeira86 Yes you do, probably best to swap to non devel though.
-
Are there currently differences between the devel version and the normal version? I recall there were some years ago. If I decide to switch to the normal version, what procedure should I follow to ensure the continuity of settings?
Thank you so much!
-
@fmroeira86 AFAIK the only difference right now is the typo fix mentioned above.
You can just uninstall devel and install normal to change.
https://docs.netgate.com/pfsense/en/latest/releases/23-01.html
“The pfBlockerNG package has been updated to match pfBlockerNG-devel. After upgrade it is safe to uninstall pfBlockerNG-devel (keeping settings) and install pfBlockerNG instead.” -
@fmroeira86 said in pfBlockerNG sync not working:
Are there currently differences between the devel version and the normal version? I recall there were some years ago. If I decide to switch to the normal version, what procedure should I follow to ensure the continuity of settings?
Thank you so much!
Thank you!
Just swaped to the regular version without any problem only by installing it.
It did uninstall the devel version and all configurations remained untouched :)
Cheers!
-
@SteveITS Just wanted to note I finally got around to testing this in regards to syncing and learned the following:
- Update and Cron on Firewall 1 does not sync
- Update, Cron, and Reload on Firewall 2 does not sync
- Reload on Firewall 1 does sync
So, basically as you said, a force reload must happen on Firewall 1 to get the sync to happen.
-
S SteveITS referenced this topic on
-
M markdavis referenced this topic on
-
@planedrop said in pfBlockerNG sync not working:
So, basically as you said, a force reload must happen on Firewall 1 to get the sync to happen.
@BBcan177 The help says:
Setting changes are applied via CRON or 'Force Update|Reload' only!which is not true at this point.
-
@Bob-Dig I think that’s more in terms of “make changes, click Apply to activate” as with rules, service config, etc. However all those other pfSense settings sync automatically unless unchecked in the HA settings.
If that’s the intent though, the text could be updated to say :
“Setting changes are applied via CRON or 'Force Update|Reload' only!
Settings sync to the HA secondary only via Force Update”
…so it’s at least obvious it’s different from other packages/pfSense.
-
@SteveITS @Bob-Dig @planedrop Forgive my re-iteration on this sync issue but I insist for clarification purposes: the pfblocker package using a seperate and indipendant sync method doesn't rely on pfSense's native HA sync between nodes, it uses what I see as a basic "copy XML over to slave by cron job script" method which you specify in the package's sync page configuration. So if you happen to modify anything on the master node in pfblocker this will never trigger an immediate sync as with any other service in/of pfsense - it will only trigger every time cron is run (hourly). If you want to force it, then you have to issue a Force-reload. A normal reload will not copy the XML over to the slave. This is a "by design" behavior from what I can see - be it correct or not is another debate though and maybe this can be rectified. I have always been using the -devel version from the start so I don't know if the standard version behaves differently but I highly doubt it. Maybe @BBcan177 can shed some further light on the matter, but this is how I see the whole sync works with pfBlocker-devel.
-
@IT_Luke said in pfBlockerNG sync not working:
it will only trigger every time cron is run (hourly).
No, it will only work on a forced reload. If you don't do that it will never be copied over.
-
@Bob-Dig Let me verify this on one of my nodes - will get back to you.
-
@IT_Luke said in pfBlockerNG sync not working:
will get back to you.
Do that. I have no problem with this behavior, kinda like it. But it should be mentioned there correctly.
-
@IT_Luke Just to clarify, I do not think it was always this way. I just do not know when the behavior changed. We've had pfB in HA for like 9 years now.
-
@Bob-Dig I confirm the failure to sync the updates from the Master at cron sync time (it only syncs with a forced-reload). Something is definitely broken with the change config detection. Will try to snoop around the .inc file and see if there's anything that stands out.
