Seemed to work.  Thanks for your speedy reply.

Thanks so much!
The more I read the more I realize how little I know.  I'll be doing a gob of reading over the next month.

check these threads, have tons of lists

https://forum.pfsense.org/index.php?topic=102470.0
https://forum.pfsense.org/index.php?topic=86212.0

@BBcan177:

Is your OpenVPN a "Server" or "Client" configuration?  Do you want both "Inbound" and "Outbound" auto-rules to be created?

I have a fix that will add "Outbound" auto-rules for a OpenVPN "Server" config, and add both "In/Outbound" auto-rules for a "Client" configuration….

Typically, with OpenVPN, you assign an interface in the Interface tab, and it will show in the pfBlockerNG In/Outbound Interface options. The checkbox option, is for some corner-cases where there is no interface assigned and there is no Interface listed in the drop-down menu.

My OpenVPN is a server configuration (think "road warrior" setup with mobile clients connecting).  So my use case is that I want to apply the same PFBlockerNG outbound rules I use for local clients to road warrior clients connected through the VPN for ad-blocking and content blocking purposes.  So it sounds like your fix would address my problem.

Sent you a PM …

Looks good on today's snapshot.
Thanks Chris!

I have been working on some new features, so I will most likely submit it all at once… So it probably won't be for atleast a few more weeks... Been really busy lately...

I chose the first rule.

I also created an alias (pfsense, not pfbng) to allow the particular IP's I want and put that as the first rule. Everything works like a charm for an hour, then the CRON job resorts to the Rule Order.

Looks like I can accomplish the same thing through pfbng's alias system.  Wasn't aware that's what the ipv4 and ipv6 tabs were for.

btw, the help link on the ipv4 tab is broken (https://<url to="" pfsense="">/help.php?page=/pfblockerng/pfblockerng_v4lists.xml)

Thanks for your help - I'll tinker from here until I get it.</url>

Confirmed that the DNSBL VIP will not be accessible when Pfsense is in bridge mode even when the Bridge logical interface is used for DNSBL listening. It works fine in Layer 3 mode and DNSBL alerts are visible.

Thank you cmb - you're right it just needed a package list update. Here's to hoping Chinese port scanners never bother me again!

Solved, it's a bug, just upgrade to latest version.

Thanks BBcan177.. That was it. I changed it to:

|pfSense Pass/Match | pfB_Pass/Match | pfB_Block/Reject|

And it works fine now. I'll look at creating aliases within pfB for my overrides.

Thanks again for your help and for your work on this package!

Regards,

Nate D.

:)  I thought I fixed that… Dok mentioned it to me like over a year ago ... Will get that fixed in the next version...

Once I re-enable it I will report back as to whether or not the service restarts under those conditions.

So I got around to enabling DNSBL, and I think I have it working.  ;D  The DNSBL service does indeed remain running now after a CRON or forced update. I did have to add a rule to pass traffic to the DNSBL VIP as you instructed… THANK YOU for that.

I do have a question: what should I see in my browser if I navigate to the VIP? All I see is a blank page, but the title bar tells me it is resolved... is that normal? See attached.

I would like you to take a look at a sample of the top of my firewall rules (I am a default block guy), and tell me if you see any issues. I wan't sure about my NAT redirect for DNS (as I asked above), so I left it.

I also have one VLAN interface where I have the NAT redirect pointing to opendns (my kid's clients), and that seems to still work as well. I am very happy with the adblocking that I see now, and I will be adding to the DNSBL lists as you discussed here: https://forum.pfsense.org/index.php?topic=102470.msg573159#msg573159

Please review the attached sample rule set and let me know if you see any problems with the DNS redirect or otherwise.

Thank you so much for your work on this package, and for your help!

-Bill

1x1.JPG
1x1.JPG_thumb
Rules2.JPG
Rules2.JPG_thumb

I should mention that my VPN is setup as TUN, but all client traffic is forced through the tunnel.

Hopefully this will help

Thanks.  That would seem the sensible way to go, particularly as someone has very kindly already done a pull request for it.

I couldn't see an option for the RAM disk backup/restore in pfBlockerNG itself, so I'm assuming it's always enabled.  If you have the time, I could see a benefit to implementing the DNSBL backup too if only because it seems anomalous to have some of the settings backed up but not all.

Thanks for developing pfBlockerNG by the way - it really is a useful and well-used package for pfSense.

I was trying to see what the process running would be pfBlockerNG that would be seen by top. The process that is running is php.

Here is the real. I believe process /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfblockerng.inc dnsbl.

Top would show php as the process.

last pid: 18593;  load averages:  0.00,  0.01,  0.00                                                                                up 0+23:14:21  07:14:39 73 processes:  1 running, 72 sleeping CPU:  0.0% user,  0.0% nice,  0.2% system,  0.4% interrupt, 99.4% idle Mem: 104M Active, 383M Inact, 405M Wired, 256K Cache, 407M Buf, 2949M Free Swap: 8192M Total, 8192M Free   PID USERNAME  THR PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND 45366 squid      1  20    0  267M  167M kqread  0  0:14  0.00% squid 42679 unbound    2  20    0 55112K 28476K kqread  1  0:06  0.00% unbound 67172 root        1  52  20 17000K  2392K wait    1  0:05  0.00% sh 54987 squid      1  20    0 37752K  4084K select  1  0:03  0.00% pinger 37883 root        1  20    0  220M 33036K nanslp  0  0:03  0.00% php

I was just curious why I could not see a process running. Now I know why. All I know about php that it is one of the scripting languages.

Thanks for the information. If I have problems in the future I am able to dig deeper into the problem.

Oh look there it is! Apparently is for DNSBL with a big DO NOT EDIT. Thanks for pointing me to that, any ideas what to do from here or should I take the query into the PFBlocker post?


@dougc420:

OK a clever friend of mine found the solution.

When I setup PFB it auto created rules.
The list action was set to "Deny" by change that to "Alias Deny" and deleting and recreating the rules manually.
This fixed the sorting order issue where the rules would move in priority.

I also see the logic doktornotor shared.
Rather thank blocking 4,225,000,000 port combinations and 3,706,452,992 public IP addresses causing much computational overhead.
It is better rather to make selective entries to PFB specific openings and let pfSense do that inherently and not globally blocking everything using PFB because pf already does all that.

Thank you everyone for your help I really appreciate your support.
Now I do not have an absurd WTF setup.    (:

+1, this solved it for me as well. My issue was I wanted to block the same IP's on LAN and WAN, but I needed the order to be different on the interfaces as I needed passthrough rules on the LAN, which obviously didn't work. Only drawback I seem to be getting due to this approach is that Alerts in the pfblockerNG now is empty so it is challenging to know which block list actually initiated a block. edit Duh, forgot to mark "log this".