Figured this out.
I replaced pfBlcokerNG with pfBlockerNG-Devel but the behavior remained the same. Creating a rule based on a GeoIP alias containing a country, opens ports 81 and 53 to the world (despite ports 81 and 53 are not included in the alias settings; only the required ports are included). To avoid this, in addition to (or instead of) having Custom DST Port in Firewall > pfBlockerNG > IP > GeoIP > Continent > Advanced Inbound Firewall Rule Settings, the ports are also required to be set in the Destination Port Range of the Rule, otherwise ports 81 and 53 (in addition to other opened ports) would be opened to the world. In my case I disabled the Custom DST Port and set the Destination Ports Range in the rule. I am not sure about the purpose of the "Custom DST Port" in GeoIP.
@BBcan177 Thanks for your help.
Sorry I have wasted your time.
lastly, pfBlockerNG is amazing. It just makes pfSense so much more powerful as a great firewall solution.
These settings are all and only stored in the main pfsense config xml file.
All other files on the disk should be removed. It's not a "setting", after all.
@gabric098 said in How to fully uninstall pfBlockerNG:
zero knowledge about pfblockerNG
Me neither.
That's why I read the installation manual(aka : the php and xml files that install pfblockerNG are in plain old school English ...).
@provels - Hi, I am running pfBlockerNG (v. 2.1.4_20).
I don't use DNSBL, just the IPs. I started readding the blocklist IPs (e.g., BinaryDefense, EmergingThreats, firehol Level 1 to 3) and they now work.
I was not aware of the role of the .orig files. I tried clearing both (AfunList.orig from /var/db/pfblockerng/dnsblorig and AfunList.txt in /var/db/pfblockerng/dnsbl) and then force updating DNSBL. Both the orig and txt files were regenerated from the list feed
As far as I can tell, the feed is correctly synced.
@RonpfS said in pfBlockerNG rule download failure log entry- false positive?:
Can you access the URL for AfunList in a browser?
Yes.
So I'm not sure why the log is reporting an error
@NollipfSense Good deal. Package probably didn't completely reinstall when you upgraded. If you install the daily snapshots now, it will go a lot faster as it just installs the update without package reinstalls (like 5 minutes total).
@Qinn
If you see the line about "MaxMind last updated..." Then there is no failed download errors. Otherwise, you have more than 4 failed downloads, and you need to scroll the widget window down to see the last event and there should be the trashcan icon. Going from memory on this one.
@jahonix said in Rules ordering not working:
@pftdm007 said in Rules ordering not working:
I am using floating rules to make rules ordering easier for me. Please indicate if this is a problem.
Not a problem if you consider this:
Floating Rules notes
Floating rules without quick set process as “last match wins” instead of “first match wins”. Therefore, if a floating rule is set without quick and a packet matches that rule, then it also matches a later rule, the later rule will be used. This is the opposite of the other tab rules (groups, interfaces) and rules with quick set which stop processing as soon as a match is made. See Floating Rules for more details on how floating rules operate.
OK I read the pfsense documentation and get a better idea. Now I see that there is a ckeckbox called "Quick" in the rules. All of my floating rules ghave this box ticked. So from the documentation:
"Apply filtering in a “last match wins” way rather than “first match wins” (quick)"
I take that the first match will win. But first (or last) based on what? The rules ordering in pfblocker???
Turns out uninstall/install looked like it kept the settings but it subtly changed the alias names for a custom alias from "pfB_GeoIPUSv4" to "pfB_GeoIPUSv4_v4" which broke several NAT rules. Error reported by pfSense for the rule was:
Unresolvable source alias 'pfB_GeoIPUSv4' for rule ____
Editing the NAT rule and saving without changes corrected it. The NAT rule itself had the new name already, but the old name was being flagged as not resolving because the old name was still used in the matching firewall rule (the two were different).
