PfBlocker
-
So you're saying my new list will over ride the other lists by default?
Also, what format to I put the IPs in? Is it listed as below?
213.238.8.10/32
Sorry to be so stupid on this.
Thanks!
-
whitelist(allow) rules are applied before blacklists(deny).
the custom list is in CIDR format, so if its only one ip address 213.238.8.10/32 is fine.
-
Thank you!
-
FYI http://www.countryipblocks.net/information/country-ip-blocks-endorses-pfsense/
-
FYI http://www.countryipblocks.net/information/country-ip-blocks-endorses-pfsense/
Awesome. Thank you.
-
I'd like to begin by saying thank you for pfblocker and what all of you do to make this project a success. The post I'm about to write is intended for communicating how pfblocker could be improved, but if not read in the proper mindset may come off as me being critical of pfblocker so I want to make my intentions clear up front.
I am not currently using pfblocker for a couple of reasons, the primary reason is it seems to make establishing new connections incredibly slow. This is most easily noticed when browsing from one domain to another, in my configuration anyway it causes an immense connection time but once the connection is established it seems to do ok-ish.
This may not necessarily be the fault of pfblocker as it does take system resources to run such a package gracefully, so I believe perhaps a chart or even a dynamically calculated value on the pfblocker page would help tremendously. For example, I'm not sure if pfblocker is processor hungry or memory hungry, but it could compare for instance available ram with amount of rule entries and give the user an idea of the performance they should be getting with their rules. If they have gone over the limit for their system, the user then can either deal with it, remove some rules, or remove other system resource intensive package or setting. This would make diagnosing these types issues much easier.
Another suggestion I have for pfblocker would be to have the option to dynamically increase the number of firewall entries to the amount of rules for the lists the user has selected + however many for their personal needs. For example, a checkbox "Automatically Increase Firewall Maximum Table Entries", then a box to enter how many above the amount of rules for personal firewall rules, possibly with a default of 10000 which should be sufficient for most everyone.
That's all for now… hope these recommendations are fresh and I'm not just "yet another griper" lol. I didn't see anyone suggesting this but there are many places to look.
-
In reply to Kamel,
pfblocker performance is going to depend on your hardware. Keep in mind that pfblocker is neutral to how your system will perform. Your system performance with pfblocker will be affected by how large your lists are. If you're using a very small list the you won't even notice pfblocker. The larger the lists then the more memory is required.
Creating a chart for usage is moot. Everything depends on your hardware and your lists. For example, a list with 5000 IPs runs like nothing on my firewall but a list of 5000 may cause problems on an embedded system. So if your experiencing problems then you need to upgrade your hardware or reduce your pfblocker usage.
Firewall entries should be left to the user. Most users will never have to increase system resources to use pfblocker. If we dynamically change system variables on the fly this could cause issues with the system or other packages. Basically, it's an unnecessary risk to change a variable that a user can do at their own risk. A compromise to this could be to have the user enable this feature at their own risk.
My pfense is running on hardware that is way overkill for pfsense, however running addons like pfblocker does take a lot of system resources. With that being said, I am running pfblocker with over two billion IP's. It's takes a lot of RAM but I don't experience and slow downs or any latency because my hardware is built for it.
-
I'm not sure I effectively communicated what I was trying to say… I realize that list sizes are going to impact performance. Maybe even just a "rule of thumb" chart would be helpful, like "for systems with 256mb of ram use no more than X entries, systems with 512mb of ram no more than X entries, systems 1gb-4gb use no more than X entries" or something to that effect would still be helpful.
If there is risk to dynamically changing the number of rules, a compromise might be to add a check when applying the settings then... if total list rules combined are greater than the maximum available rules in your firewall settings, produce an error and don't let the user submit their settings. This would make the error obvious, so that they don't get weird errors in their logs and wonder why pfblocker isn't working right.
-
I'll see what I can do with a performance/requirements chart. I'm sure it's going to take a while to create the chart.
-
Okay, another question…
When making a white list for IPs, do you use any type of delimiter? Or do you just list them in a column like below?
213.238.8.10/32
193.148.0.35/32
206.123.63.32/32Thanks!
-
I'll see what I can do with a performance/requirements chart. I'm sure it's going to take a while to create the chart.
If it's going to be a major pain to do, perhaps it wont be worth it :-\
Just looking from the standpoint of the end user, I think it would be very helpful is all. If I can help in any way let me know, will be glad to do so.
-
When making a white list for IPs, do you use any type of delimiter? Or do you just list them in a column like below?
213.238.8.10/32
193.148.0.35/32
206.123.63.32/32One network per line, just like gui says.
-
If it's going to be a major pain to do, perhaps it wont be worth it.
Just looking from the standpoint of the end user, I think it would be very helpful is all. If I can help in any way let me know, will be glad to do so.Pfsense is not for end users, it's for firewall admins or small networks admins. You must know about tcp/ip and what you need or want in a firewall.
If we do a chart, the next question will be about someone that followed that chart and is not happy about the results.
It's unnecessary in my opinion.
-
I don't think any amount of experience or knowledge of tcp/ip would give you a good idea of the amount of system resources consumed by firewall rules. That is more dependent on the specific software, and combination of software. Since pfsense has a common software platform with only minor variations, I think a chart would be somewhat accurate, but it's of course up to the user to use their common sense.
If the consensus is that it's unnecessary, that's fine. I don't agree that a working knowledge of tcp/ip has anything to do with the subject, however.
-
I agree with marcelloc. Creating a chart is unnecessary a will not reflect real world scenarios on a real world budget for home use. It would be extremely difficult to account for all platforms that pfsense is compatible with.
Kamel,
marcelloc is right. This package was created to assist networks admins and professionals. Having performance issues at home on is not a concern. The fact of the matter is that all performance issues can be solved with hardware. Every single IP added to a list consumes RAM. Packets entering and exiting the firewall requires processing power. Furthermore, pfblocker uses native pfsense software and knowing this you can conclude that if your firewall isn't performing at the level that you need then it is a hardware issue and not pfsense at fault.You have some good ideas but you're missing the fundamentals. pfsense does appeal to and is compatible with many platforms but when it comes to the best performance many platforms will not perform better than other platforms.
Also you don't need to know the inner workings of TCP/IP to work with pfsense but if you're going to manage pfsense in an environment where pfsense thrives then you better know everything about TCP/IP and so much more. marcelloc was using TCP/IP as an example of what a network administrator would know at a minimum to understand how to properly manage a firewall since this package was created for network administrators.
-
Forgive me if my comments seemed a bit tasteless. I got the impression marcelloc was insinuating that my abilities were insufficient. I know I shouldn't have so I apologize for that.
I still believe it would be a good idea (and should be relatively simple to add) to check if there are enough firewall entries available for the amount of rules pfblocker applying before you submit. This was actually my primary concern, the idea of system resource usage was only secondary to this.
-
Forgive me if my comments seemed a bit tasteless. I got the impression marcelloc was insinuating that my abilities were insufficient. I know I shouldn't have so I apologize for that.
I'm not insinuating anything. I'm here to help the project just like everybody.
I'm sorry if my post sound offensive. It was not my intention.I'm improving some help messages on package gui to help even more admins.
PfBlocker checks the ammount of entries in a list before apply, but it Does not sum all lists. I will try to include this in version 1.0.1. You maybe still getting this error if you have many rules or aliases. Just like the chart, we can get close to all situations but not all. -
I have two pfsense v.2 instances, i386 (2 different networks). pfBlocker has been installed on both ones.
It works just fine on one instance, and doesn't work on another - it doesn't block anything at all.
I have disabled all existing firewall rules, have checked tables in Diagnostics->Tables (they exist indeed) - everything looks just fine.
But when trying accessing internal network (WAN interface was selected for inbound rules), I'm not being blocked from the target
network which is supposed to be blocked. Tried adding custom rules list - no luck, added a country to block list - no luck to see it working.
The only difference between these 2 instances is that on pfBlocker has a combobox menu selector, another one has tabs.
Both were installed from GUI. I'm totally lost. Any ideas how to check why it didn't work ? -
make sure you are using the same version on both.
gui was designed to fit tabs and prevent combolist.
also check pfblocker applied rules on wan or lan.
you need at least one rule on interface you want to apply rules.
if you don't mind, post your rules screenshot.
note: pfblocker use native pfsense functions to help admins. So if you have rules not working, check what is going wrong with your box.
-
Forgive me if my comments seemed a bit tasteless. I got the impression marcelloc was insinuating that my abilities were insufficient. I know I shouldn't have so I apologize for that.
I'm not insinuating anything. I'm here to help the project just like everybody.
I'm sorry if my post sound offensive. It was not my intention.I'm improving some help messages on package gui to help even more admins.
PfBlocker checks the ammount of entries in a list before apply, but it Does not sum all lists. I will try to include this in version 1.0.1. You maybe still getting this error if you have many rules or aliases. Just like the chart, we can get close to all situations but not all.Increasing my firewall rules limit worked fine and it's fast with no issues (assuming I disable some other services to reduce my RAM consumption). I will admit, it was a bit of a pain figuring out what was wrong at first. Even many searches going by, it seemed people were referring to things like memory etc. I hadn't realized the number of rules in the blocklists were impacted by the number of firewall rules or I would have known what to do immediately.
In any case, thanks for that – I think it will be a simple enough but helpful addition. I know for me personally, I'll never make the mistake again :P
