Baby Steps to Implement pfBlockerNG

  • I just finished reading the pfBlockerNG main thread and is now ready to take baby steps to implement pfBlockerNG on my pfSense.

    Baby Step 1 - Protect Opened Ports

    My first order of business is to protect 3 opened ports (1 port forwarded, 2 OpenVPN).  So here are the steps I used:

    • Enable pfBlockerNG with: Keep Settings, De-Duplication, CIDR Aggregation, Suppression, Floating, & Kill States enabled.  WAN - Blocked, LAN & Opt1- Reject

    • GeoIP -> North America: USv4 selected, List action - Alias Permit, Logging Enabled

    • Disabled the NAT created firewall rule for my port forward.

    • Created manual rule with description starting with pfb_ that is identical to the NAT created rule except the source is now the Alias Permit from above.

    • Modifiy the two OpenVPN wizard firewall rules to also use the Alias Permit as the source.

    I have not added any lists or enabled DNSBL.  Should I see any alerts to see if non-US addresses are blocked from my open ports?  Or I would have to check the firewall and OpenVPN logs to see if I am no longer getting attempted accesses from non-US addresses to my open ports?

  • Baby Step 1: Protect Opened Ports
    After a day running, I think it is working since the pfBlockerNG dashboard widget gives some statistics of Deny and Permit.

    In the OpenVPN log, I now see only USv4 addresses trying to access my OpenVPN ports.  Since I am only the user authorized to access via the OpenVPN ports, these access attempts are unauthorized.

    I started a custom Deny Both alias list, but the note for the custom field says to limit the addresses.  What is the best way for me to maintain a Blacklist of unauthorized IP addresses that are in the US?  Or is this a futile effort and I should just ignore the unauthorized attempts on my OpenVPN ports?

  • Moderator

    With an Alias Permit, you will only log those permitted events… All other Blocked events are handled by the pfSense default block rule.

    If you can narrow down the list of which IPs can be allowed to access the port, then you can further restrict it, instead of opening it up to the entire US.

    The custom blocklist is an option, but open ports will be hit. You can also add other known malicious IPs to the IPv4 tab and have those rules above this permit rule. This way you can filter out the known malicious IPs.

  • Is there a good list of known malicious US IPs?  I have the PRI1 alias from your script, but that has over 23K addresses.  If there's a list of just US malicious IP (hopefully it will be much smaller than the PRI1 alias list), then I would make a Deny Inbound alias and have it before the USv4 Alias Permit for OpenVPN.

    I use OpenVPN when I travel to access my network and so it would be difficult for me to narrow the IPs allowed to access.  Narrowing it down to the US was the most certain I can be since I don't remotely access my network outside of the US.

  • Moderator

    There are quite a few lists… The next version of the pkg will have a feed management tab which will help with this...  There are other Aliases in my old script... Some URLs are dead now but you can do some research to see which ones are working by checking the sites in a browser...

  • Trying to understand de-duplication…

    If I have an IP address that is in a Deny Outbound  and  a Alias Deny but I do not want the de-duplication process to remove that IP, how should I set up the custom list?  I tried native, but it looks like de-duplication is removing the IP.

    The reason being is that I have a Deny Outbound list action to protect outbound but I also have a manual incoming Block rule using a Alias Deny to protect my opened ports.  It so happens, with de-duplication enabled, I cannot have an IP blocked for both cases.

    The Deny Outbound purpose is to prevent LAN devices from visiting harmful sites.  The Alias Deny used in an incoming block rule is to protect my open ports, which is already limited to the USv4 GeoIP list.  I could set the Deny Outbound to Deny Both, but that would be too inefficient since there is only 1 or 2 overlapping IPs and I rather utilize the implicit block for the IPs on the Deny Outbound.

    Basically, I am finding a handful of IPs that are constantly trying to access my opened ports.  It appears they are slipping through because they are US addresses (which passes my GioIP rule) but are also listed in one of the feeds for my Deny Outbound (which de-duplication removes from my custom list).

  • Moderator

    With deduplication all of the "Deny" type actions (Deny Inbound, Deny Outbound, Alias Deny) are essentially deduplicated as one.

    If you want to bypass deduplication, then you will need to use "Alias Native" which will not use deduplication at all.. However, packet fence (pf) will do some deduplication if there are repeated IPs, but only for this single aliastable.

    Check your "Rule Order" setting, the Deny rules should be above your permit rules, so that any known malicious IPs are blocked before your GeoIP permit rule.

  • Thanks for tidbit on packet fence deduplication!  I will try Alias Native again.  I thought I had tried it, but during the force update, my custom list of 5 IPs would be narrowed down to 3 IPs.  So I assumed de-duplication was performed on Alias Native too.

    All my deny rules are above my permit rules.

  • I have global logging disabled.

    In GeoIP/North America I have Alias Permit with logging enabled.  The manual rules (starting with pfb) that reference this Alias Permit does not have logging enabled.  What is going to get logged and where?

    I checked the Firewall log, but I do not see anything that would be from this Alias Permit.

    Looks like to get the alerts for the Alias Permit to show up, I had to enable logging on the actual manual fire rules.  What is exactly enabling logging on an Alias Rule do?

  • Moderator

    When you use manually created pfBNG rules, ensure that you name begin the Rule Description with "pfb_"  This way the widget and the Alerts Tab will be able to distinguish which rules are for the package.

    You can click on the blue infoblock icons in the IPv4 tab for more help on setting up "Alias" type firewall rules…

    When logging is enabled, those alerts will show in the pfSense Firewall log. You can edit the pfSense log settings to show the Rule Description as a column with the "Where to show rule descriptions" option.

    To answer your "Update" -

    When you use "Alias Type" rules, none of the settings that you see on the page apply, as the package is not making any of the rules. Alias type rules are manually entered, so you must configure each part manually… If you used "Permit Inbound" or "Permit Outbound", then you can also defined the port/destination IPs by utilizing the "Adv. In/Out" settings.

    For Alias Types, only the Action and Frequency settings apply on when to update the Alias.

  • A good source for IP blocklists is

    Personally, I use their merged lists since they merge a lot of the actively maintained lists out there:



    firehol_level4 (sometimes I've changed this one to be just DENY INBOUND but whatever.

Log in to reply