PfBlocker

TrickyWidget

I got the dreaded error trying to load the Level 1 list:

There were error(s) loading the rules: /tmp/rules.debug:16: cannot define table pfBlockerLevel1:
 Cannot allocate memory pfctl: Syntax error in config file: pf rules not loaded - The line in question reads
 [16]: table <pfblockerlevel1> persist file "/var/db/aliastables/pfBlockerLevel1.txt"</pfblockerlevel1>

My Firewall Maximum Table Entries is set to 4294967295 and still no love. Freshly installed pfSense and pfBlocker, most everything at defaults. Just the one block list. 512MB of RAM, only 32% in use. 1GHZ CPU.

Does anyone have any suggestions?

Thanks.

TrickyWidget

I got this suggestion from marcelloc:

@marcelloc:

Unselect the list, apply pfblocker config.

change again table max entries and apply config.

when you are sure that the new config is applied, try to enable again the list.

That seemed to work for a while, but the error eventually returned (or at once on reboot).

I've got a RAM upgrade on the way to see if going to 1GB helps any.

fragged

Hi,

On my physical 2.0.1 box pfblocker is making duplicate WAN rules. I only though to check after reading this thread: http://forum.pfsense.org/index.php/topic,50408.0.html . I tried to remove + reinstall the package, but it saved the config files and still keeps making duplicates.

pfblocker works fine on my VM, which also has floating rules though I've only used the latest version on it.

Is there a file / config I should also remove addition to the pfblocker package to make sure nothing is carried on.

Regards,
Joona

marcelloc

I've reduces duplicate cases and also applied some forum users patches but there are still duplicates on some cases.

This does not affect pfsense performance or load, is just a minor bug I could not fix 100% yet.

To workaround, you can change pfblocker action to alias only and create your own rules on wan just like the way you did on floating rules.

att,
Marcello Coutinho

TrickyWidget

Upgrading to 1GB RAM and further increasing the firewall table entries seems to have resolved my memory issues with the level 1 list.

marcelloc

Great! thanks for the feedback.

OldGrayandCranky

I believe that a bug exists in pfBlocker 1.0.2 or maybe it is by design but I can't see why it would be.

In a fresh install of pfSense 2.01, after completing the setup wizard and installing the pfBlocker package, WAN rules are not created automatically by pfBlocker unless a manually added rule already exists in the WAN rules. The Action selected was "Deny Both".

The LAN rules are created without any problem. I did a complete fresh install again to verify this. Can someone confirm if this is a bug?

A workaround is to manually create a rule in the WAN rules and then configure pfBlocker. Everything works fine then.

Thanks for your help. :)

phil.davis

Each interface has an implicit "block all" rule on the end (not listed on the GUI). So if there are no WAN rules, or just other blocking rules (like Block bogon networks), then all connection attempts from WAN are being blocked already. So there is nothing to be gained by adding a pfBlocker rule (I guess it would just add extra processing for nothing). The behaviour is by design, not a bug.
Once you open up something on WAN, then you need to go to pfBlocker and "Save" again. It will reprocess everything, find stuff opened up on WAN and add its blocking rules.
Note: if I then delete the rules that opened things up on WAN, go to pfBlocker and "Save", then pfBlocker does not remove its rules from WAN. So you can end up with an unusual-looking state (but no security issue). If you disable pfBlocker and save, then enable and save, it cleans up any rules then puts back the essential rules, restoring the state of things to "normal".

marcelloc

phil.davis,

100% correct :)

Explaining the code:

While applying pfblocker rules, if it does not find wan rules array, it will not create one(as default action is block). That's why you need a rule on wan before pfblocker can apply rules to it.

att,
Marcello Coutinho

OldGrayandCranky

Thanks Phil and Marcelloc, The explanation was informative and I do agree with the logic of the design. I appreciate the time spent on the project. It fills a very important need. Thanks!

On useability, I can't help thinking that allowing the "Deny Both" option to be successfully executed lures the user into a false sense of security when in fact, they need to reapply the rules to be protected.

Since the package already tests to see if there are rules on the WAN, is it possible to use that logic to fail the execution if no rules exist and force the user to select an option that would meet all of the requirements? If so, the error message could instruct them to add rules to the WAN or choose another option.

That extra step would improve the package and provide an extra measure of protection by default.

S_D

Ok, I have this working and it's a great package. Thanks for your hard work on it.

I have a feature suggestion though

I'm moving from Peerblock on my data server to pfblocker. Both using the level 1 block list. My data server behaves exactly as expected. However, with pfblocker I and the level 1 list with 'deny both' (inbound and outbound) I note that pfblocker blocks traffic talking to the lan interface of my pfsense box (192.168.101.1). Replicating that setup with Peerblock does not deny this traffic.

I'm wondering if this is what you said about it handling large networks?

How about a box where I could enter a test IP and see if pfblocker would block it? Unfortunately I can't view the resulting level1 table in diagnostics–>tables as it is too large and I just get a white page...

Unless there's another reason why this IP may be blocked?

Thanks,

Simo

marcelloc

@S_D:

Unfortunately I can't view the resulting level1 table in diagnostics–>tables as it is too large and I just get a white page...

try this on console/ssh

/sbin/pfctl -t pfblocker_alias_name -T show | grep ip_you_want_to_check

S_D

Thanks. Running that doesn't show the IP as being blocked (in fact opening the file manully in wordpad doesn't list it either - hardly surprising as it's an RFC1918 address).

however, adding another 'allow' custom list containing the address before this allows the traffic again.

Running your command on this list shows the ip

I think what we're seeing though is a raw search of the downloaded file, rather than a search of the compiled tables.

Which leaves 2 questions.

Why is the level1 list block 192.168 addresses (I've tried changing to 192.168.1.1 to test further and it's still blocking it)
and
Is it possibly to search or query the compiled list?

Thanks,

Simon

S_D

Just built a VM replica enviroment to test this again and have confirmed it there to, so it's not corruption on that system i don't think.

I can see the blocks in the firewall logs.

S_D

A final bit of diagnosis.

I've changed the LAN network to be 10.1.1.0/24 (firewall on .1), and pfBlocker is not blocking traffic. That leads me to believe it is something to do with the way it is summarising it's 192.x network somewhere, but as I say I don't know how to properly query the compiled list. :)

S_D

@marcelloc:

P2p lists are converted to cidr format after download. If p2p range generates a network mask bigger then /16, pfBlocker will TRF to find a network cidr for this, What could result on a /12 or /8 network. In this situation, you may have some non blacklisted ips blocked.

Cidr is the recommended format for lists.

Sorry to spam this thread, this is the last question I promise.

Above you mention CIDR as the recommended format.

I've been downloading in P2P format (http://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz)

When I tell pfBlocker do download the same list in CIDR format instead, the traffic now flows! So I assume the pfBlocker conversion of P2P to CIDR is what was causing the issue. I also now only get around half the number of CIDRs showing in the widget now (approx 252000). Is that right?

Thanks!

marcelloc

@S_D:

Sorry to spam this thread, this is the last question I promise.

No problem. Today the forum helps you, tomorrow you help the forum ;)

@S_D:

I also now only get around half the number of CIDRs showing in the widget now (approx 252000). Is that right?

Probably yes.

jp141

Thanks guys this is amazing, a vast improvement over the older packages :D

The only 2 requests I have are:

1.) Have its own log tab so you can quickly and easily see what has been blocked

2.) On the dashboard widget breakdown the blocked stats to incoming/outgoing

Would they be possible?

Thanks again

marcelloc

@jp141:

1.) Have its own log tab so you can quickly and easily see what has been blocked

pfblocker just create firewall rules with log options selected, so there is no way to distinct from other firewall log rules

@S_D:

2.) On the dashboard widget breakdown the blocked stats to incoming/outgoing

No plans for that yet.

jp141

Ok thanks for the update.

Keep up the great work ;D