PfBlockerNG

[BBcan177]

@mzarrugh:

Is it possible to use easy list

Not currently. That is a Domain Blocklist. pfBlockerNG is an IP Based Blocking solution. pfBNG v2.0 will have this functionality.

[samham]

I have configured iBlock list under IPv4 to block in both directions I see the logs showing blocking however no updates for the widget, please see attached

[BBcan177]

@samham:

I have configured iBlock list under IPv4 to block in both directions I see the logs showing blocking however no updates for the widget, please see attached

When you look at the System Logs: Firewall Logs in the GUI. Do these alerts have pfB_ in the Rule Column?

[samham]

no I don't but i see the IP being blocked in both the pfblockerNG:Alerts and the Firewall Log

[BBcan177]

Clear the Firewall Log and start fresh. When you make Rule Changes, they can go out of Sync.

[BBcan177]

@samham:

how do you show Rule column under system:firewall log?

System Logs: Settings:

Filter Descriptions and select "Display as Column"

Also make sure the logs are in reverse. First Checkbox at the top of the Settings page.

[samham]

I still don't see the pfB_in under rules

[samham]

OK I see it now, but still no update in widget

[BBcan177]

@samham:

OK I see it now, but still no update in widget

Did you manually edit the pfBlockerNG Descriptions in the rules? the rules are auto-generated and need to start with "pfB_"

You should not need to edit the Descriptions as this will affect how the Widget reads the log files.

Edit:
If you uses "Alias" Type rules: make sure the Rule Description starts with  "pfb_" Lowercase..

There is a whole tech section in the IPv4/Alias tab, to describe how to do this.

[samham]

not for the auto rule under the WAN interface, but for the manually added rule under the LAN I did add a description as by default it is blank.

update…

I deleted the manual rule and created an auto rule, now it works fine. thanks BBcan177 for a great package, what is the account to donate?

[doktornotor]

Manual rules are just fine as long as you RTFM and set the descriptions as required. The widget lacks paranormal skills, cannot match the hits unless the rules description is set properly.

[Topper727]

I will be on that list to want to see it and test it bbcan..

[wcrowder]

I have to agree with doktornotor, most of the problems I'm seeing reported here could have been avoided by reading the instructions on each page. BB' worked hard to explain everything either above or below each choice. Example: "Headers" are required.

The 'Header' Field must be Unique

IE. A Blank "Header field" is not unique.

Read each page carefully and it will work. :)

[BBcan177]

@samham:

thanks BBcan177 for a great package, what is the account to donate?

You can send a paypal to my email account, which is listed in the General Tab of pfBNG. I will put this towards v2.0 Development!  :)

[Cino]

@wcrowder:

I have to agree with doktornotor, most of the problems I'm seeing reported here could have been avoided by reading the instructions on each page. BB' worked hard to explain everything either above or below each choice. Example: "Headers" are required.

The 'Header' Field must be Unique

IE. A Blank "Header field" is not unique.

Read each page carefully and it will work. :)

I totally agree with your both!!

Like I tell my privates, read the f$cking FM! And in the case of pfBlockerNG, the directions are there on every page.

Maybe the package needs a warning: for advanced and/or IT users only =D

[A Former User]

As a person who is regularly caught explaining "in plain English" IT terminology, I see the problem somewhere else, and I'll play the devil's advocate here.

Someone has to bridge the engineer > user gap. I'm regularly caught in all three sides (including the middle-man), and I see the problem from every possible angle.

An example:
Engineer's thought process:
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
(if you know that && means execute the following command when the previous one ends)

User's thought process:
upgrade system next

Having to set up aliases is not the point here. It's actually having to set up aliases that's the problem  ;)

The engineer knows that in order to get to the next version, the system has to first know about that version (update), bring the system up to the last upgradable point before the actual jump to the next version to reduce the possibility of things going south (upgrade), then make the jump (dist-upgrade).

The user wants to upgrade the system and doesn't care about the process behind it.

Trust me, works a lot better when IT is cut out of the discussion. Think accounting. I don't actually care about the process to get to a result, as long as I get a result. Although I personally find it fascinating knowing how things work, not everyone does ;-)

Not saying any side is wrong btw, just laying out my thoughts for both sides to consider. group hug

[doktornotor]

@jflsakfja:

As a person who is regularly caught explaining "in plain English" IT terminology, I see the problem somewhere else, and I'll play the devil's advocate here.

[Topper727]

Add them in the IPv4 tab like shown in picture below my post

.png)
.png_thumb)

[bfeitell]

I have been using pfblockerNG for a few days now (v1.03), and I have been seeing extremely long boot times.  The system hangs at configuring firewall for about 13 minutes before finally continuing and bringing up the system.  I was able to ssh into the system, and it shows almost zero load with ~16 processes including top, until my ssh session freezes when the boot process completes.

This is very similar to the massive delay seen when trying to use the original pfblocker under pfSense 2.2.

I am using just the country block lists, and I am blocking all unsolicited inbound traffic from all the nations listed, except mine.

The behavior is very strange in that the system just seems to be idling, before it finally unsticks and completes the boot process.

Cheers,
Bennett

[Supermule]

Are you blocking the package repository from pfsense?