Bug in ipv6 lists when updating
-
pfBlockerNG-devel 2.2.5_35 contains only the feeds list update: https://github.com/pfsense/FreeBSD-ports/pull/946/files
Does this only happens with GeoIP aliases or with feeds aliases too?
-
I have seen this in the past also, so it is not due to the latest update. I did see it the last time there was an update to pfblockerng-dev. I just didn't post a bug report in the past.
The only thing unique to my setup is I do not use the auto rules, but have pfblocker create aliases and then I make my own rules. Primarily so I can control the logging.
At least this time it only happened to the GEOIP rules, but only on one rule. I also used GEOIP alias on the WAN interface but it was ok.
Here is the WAN rules and you can see the GEOIP aliases used there. It is an alias "permit" vs "deny"
-
I also opened Bug #10941 for this in Redmine.
-
@IsaacFL said in Bug in ipv6 lists when updating:
I also opened Bug #10941 for this in Redmine.
I upgraded to pfBlockerNG-devel 2.2.5_35 this morning from the previous version with no issues.
I've used pfBlockerNG for years and have never seen this issue. Seems to me you have something misconfigured or your old configuration was trashed in some way and is causing this error.
I have no idea what your issue is. Maybe @BBcan177 can chime in on what the issue is.
-
@IsaacFL can you attach your sanitized config (https://<pfsense_ip>/status.php) here or on the redmine issue page?
unable to reproduce it
-
@viktor_g I posted it at the Redmine Bug #10941
I tried doing a reinstall of the package from the package manager and the issue did not occur then.
-
@IsaacFL Did you upgrade from pfBlockerNG to -devel at some point? I've found when that happens the aliases are created with the _v4 (or _v6) suffix added, even if already present, so one must rename the aliases. I did it on all the routers (ours and clients) I upgraded to -devel but it was a year ago and I don't recall offhand if I renamed the pfBlocker alias or updated the NAT rule. Overall they needed to match.
pfSense should flag the error in the web GUI and email a notification of the invalid alias, though, as I recall? Because what happens is the NAT/firewall rule is using an alias that doesn't exist, as in your screenshot.
Edit: in my case, every single rule using pfBlocker aliases on all routers needed correcting.
-
@teamits
I don't think so, but I had tried the "regular" version at one time but had uninstalled it. I had not been using pfblockerng until a few months ago as I was using pihole.
I recently did a new install, after 2.4.5-p1 came out, moving from a VM to dedicated hardware. I transfered the config.xml so the problem could have carried over.
Maybe it did have something left over in config.xml from that time I tried it out. Hopefully, the process of updating will have cleared it up.
It only happens when I do an update, so it is pretty easy to work around. When I got the error messages, I knew what to look for and how to fix it.
-
When you say "updating" you're just updating the package by itself? I don't generally do that until upgrading pfSense, where I uninstall the package and reinstall after. (because if the package is ever for a later version of pfSense, it may break things)
That's where it hit me, as I'm pretty sure I did both at the same time....uninstall pfBlockerNG, upgrade pfSense, install pfBlockerNG-devel, and fix all the pfB alias names.
I relatively recently upgraded from 2.4.4 to 2.4.5 and upgraded pfBlockerNG-devel to pfBlockerNG-devel, and didn't have this issue then. Though in your case it sounds like it did not happen on all aliases.
Pre-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! -
You can view the downloaded backup config xml and check for any rules/alias containing the incorrect name and possibly fix the config xml itself if needed.
-
@teamits there was an update to pfblockerng devel a couple of days. That is what I did.
-
I did the upgrade from .35 to .36 today and did not get this problem this time, so it could be that it something unique to my configuration at the time.
