• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

IP Whitelisting in pfBlockerNG

Scheduled Pinned Locked Moved pfBlockerNG
4 Posts 2 Posters 17.9k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R
    rebytr
    last edited by Dec 5, 2015, 4:25 AM

    What's the correct method for setting up a whitelist in pfBlockerNG?

    For example, I have configured pfBlockerNG to deny outbound traffic to Japan via the Top 20 spammer list.  My Onkyo receiver periodically phones home (to Japan) to check for updates.  It does its job and blocks the traffic.  In this example, what's the proper way to setup pfBlockerNG to allow this valid traffic for a set of IPs, while still blocking the rest of Japan?

    I've tried setting up alias' in pfblocker and specifying the list of IPs in the custom address field.  However, I just can't seem to get the rule order right.  I've tried all the rule order combination settings in pfBlocker, so guessing I must be doing something wrong somewhere.

    Here's my current order of rules on the LAN side using the default rule order setting in pfBlocker to give you an idea:

    <anti-lockout rule=""><pfb_lists for="" deny="" outbound="" rules. ="" there's="" a="" bunch="" of="" these=""><pfb rule="" to="" permit="" a="" custom="" list="" of="" ips=""><custom rule="" with="" schedule="" to="" allow="" traffic=""><custom rule="" with="" schedule="" to="" block="" traffic=""><default allow="" lan="" to="" any="" rule="">I find that when I change the rule order in pfBlocker, my "default allow LAN to any rule" trumps my custom block rule.  :(</default></custom></custom></pfb></pfb_lists></anti-lockout>

    1 Reply Last reply Reply Quote 0
    • B
      BBcan177 Moderator
      last edited by Dec 5, 2015, 5:51 AM Dec 5, 2015, 4:49 AM

      Create a new 'Permit Outbound' alias in pfBlockerNG. Then add any IPs that you want to allow outbound in the custom list at the bottom of the permit alias.

      If none of the defined auto-rule options apply to your setup, then you will need to use 'alias type' settings and define the rules manually.

      "Experience is something you don't get until just after you need it."

      Website: http://pfBlockerNG.com
      Twitter: @BBcan177  #pfBlockerNG
      Reddit: https://www.reddit.com/r/pfBlockerNG/new/

      1 Reply Last reply Reply Quote 0
      • R
        rebytr
        last edited by Dec 9, 2015, 2:07 AM

        Thanks.  I just went ahead and converted all my lists to the alias type.  Was a bit time consuming, but I now get the full flexibility to order the rules how I wish.

        After the most recent pfBlockerNG update, I did get some errors after the upgrade.  Appear to be benign, as I'm guessing the install removed the alias', then re-created them.  Errors appear to be from the firewall saying it couldn't find the alias name.

        1 Reply Last reply Reply Quote 0
        • B
          BBcan177 Moderator
          last edited by Dec 9, 2015, 2:14 AM

          Yes, you can ignore those warning during a re-installation.

          During a re-install, all of the pfBlockerNG Aliases are removed and re-added at the end of the pkg installation. Since you manually added pfBlockerNG (alias) Firewall rules, there is a small window of time, where the pfBlockerNG alias does not exist, and you will get those warnings.  I don't have a workaround for that unfortunately.

          "Experience is something you don't get until just after you need it."

          Website: http://pfBlockerNG.com
          Twitter: @BBcan177  #pfBlockerNG
          Reddit: https://www.reddit.com/r/pfBlockerNG/new/

          1 Reply Last reply Reply Quote 1
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received