PfBlockerNG

Cino

If its hosted in the US, then yes that will be the case, is it as I've not looked yet, I thought this was Canadian a business?

Its based out of the US, Austin TX I believe. But with team members thru the world.

@Asterix:

@Asterix:

NA country list is blocking my HE ipv6 tunnel. Tried suppression and changing order. Also tried de-selecting North America from the NA list. I have kept all countries to deny inbound.

Only way it works is by disabling NA country list entirely. Suggestions??

Anyone?

Whitelist the tunnel's IP with a rule above the pfBlockerNG's rule maybe? (pfsense interface config, or tunnelbroker should show it)

Cino

@jflsakfja:

@Asterix:

@Asterix:

NA country list is blocking my HE ipv6 tunnel. Tried suppression and changing order. Also tried de-selecting North America from the NA list. I have kept all countries to deny inbound.

Only way it works is by disabling NA country list entirely. Suggestions??

Anyone?

Whitelist the tunnel's IP with a rule above the pfBlockerNG's rule maybe? (pfsense interface config, or tunnelbroker should show it)

This is what I do and it works prefect. I use floating rules, so its one of my first floater before the pfBlockerNG rules.. And I have Quick checked

P.S This is why there is an option (Rule Order) to change the way pfBlockerNG places the rules. To give you the flexible that is needed based on your setup. Since I have pfBlockerNG create floating rules, I needed to use the second Rule Order. If I wasn't using floating rules. The first option would work but I would still place my whitlisted IPs as a floating rule.

asterix

OK a bit confused. Could you please provide some quick screen shots. Last time I added a rule it was pushed all the way down on the floating rules. Also the suppression list alias is not being loaded in the rules as well.

Not in front of a pfsense box now, but you can find various options on where to put the automatically created rules in the pfblockerng package. One of them should allow you to have your defined rules first, and the automatically created ones (pfblockerng's) last. If you chose that option, and the rule is still created in the end, tick the rule and move it to the top manually.

cjbujold

Great program works well for us. However would like to suggest 2 items:

in the alert tab add a filter so we can easily find an offending rule affecting an IP (something like the filter in Snort).
If somebody could provide the suggested block list to use. We have added several from IblockList but I presume there are some that are better than others. Some direction and expertise on which to use would be very helpful

Again a great program and congratulation to the team that put it together.

cjb

asterix

I have set it to the second option as well..

pfSense Pass | PfB Pass | PfB Block/Reject

Now exactly which IP do I need to add to the top of the floating rules for HE Tunnel to work. I have tried the typical 66.220.2.74 and the gif remote address as well. Also where is the whitelist option?

Supermule

What would be the point of that?

Everything is passed through to the servers no matter what country it origins from.

:D

pfB pass/reject -> all others comes second.

@Asterix:

I have set it to the second option as well..

pfSense Pass | PfB Pass | PfB Block/Reject

Now exactly which IP do I need to add to the top of the floating rules for HE Tunnel to work. I have tried the typical 66.220.2.74 and the gif remote address as well. Also where is the whitelist option?

The gif address (remote) should make it work. Are you sure the floating rule you created is a quick pass rule?

asterix

This is exactly what I have done… let me know what I may have missed..

PfBlocker enabled
All countries - Deny Inbound

IPv4 tab - Alias named Whitelist. Added IPv4 Custom Address - 66.220.2.74 and the gif remote address - List action is set to Permit both (open communications between pfSense and the 2 HE IP addresses)

Checked the Rules and its on the top by default through PfBlocker configuration.

Reloaded and even rebooted pfSense. Yet the tunnel is blocked. The moment I deselect the entire NA country list the tunnel is back on.

@Asterix:

This is exactly what I have done… let me know what I may have missed..

PfBlocker enabled
All countries - Deny Inbound

IPv4 tab - Alias named Whitelist. Added IPv4 Custom Address - 66.220.2.74 and the gif remote address - List action is set to Permit both (open communications between pfSense and the 2 HE IP addresses)

Checked the Rules and its on the top by default through PfBlocker configuration.

Reloaded and even rebooted pfSense. Yet the tunnel is blocked. The moment I deselect the entire NA country list the tunnel is back on.

Looks like its configured ok. Dunno why it's not working. I'll let someone else with access to a pf box to help along.

asterix

Made progress…
If I de-select the US IPv6 list in the NA country list then the tunnel seems to be fine. Also I am back to the default PfB block/Reject rule load. So looks like the culprit is an IPv6 address on the US list..

but now the question is which one is it that's blocking the HE tunnel?

Cino

If your using pfBlockerNG to create floating rules and not using it to create your pass list for whitelisted IPs, then pfSense Pass | PfB Pass | PfB Block/Reject would be the way to go. This way your whitelisted alias is before the pfBlockerNG rules.

asterix

This is working for me with floating rules enabled.

Default Order: | pfB_Block/Reject | All other Rules | (original format)

but now the US IPv6 list is de-selected.

asterix

So I tried to create a IPv6 Whitelist to see if it helps by adding my gif tunnel remote address 2001:470:xxxx:xxx::1 but it gives me this error while reloading

[ WhitelistIPv6_custom_v6 ] Custom List Error ]

I tried adding /64 in the end to that IP as well. Doesn't work.

Cino

Create an alias outside of pfSenseNG for the IPv6 subnet you want to whitelist. Then add a manual permit rule to your floating rules (with quick checked). You will probably have to change the rule order to what I suggested before.

The IPv6 regex still needs some adjustments in pfBlockerNG. When we tested this a few months ago, I was able to get it work with some test IPv6 addresses I was using for testing. At the time, I couldn't locate any good list to thoroughly test like I did with IPv4

doktornotor

@Asterix:

PfBlocker enabled
All countries - Deny Inbound

Hmmm… There's default deny rule already. The above is an exercise in wasting memory and creating useless rules, or what exactly have I missed here?

@Asterix:

So I tried to create a IPv6 Whitelist to see if it helps by adding my gif tunnel remote address 2001:470:xxxx:xxx::1 but it gives me this error while reloading
I tried adding /64 in the end to that IP as well. Doesn't work.

Yeah, of course the /64 does not work. Should be 2001:470:xxxx:xxx::/1 without the bogus trailing 1. Other than that, seeing people shooting themselves in the foot by completely nonsensical blocking makes me wonder. WTF.

asterix

@doktornotor:

@Asterix:

PfBlocker enabled
All countries - Deny Inbound

Hmmm… There's default deny rule already. The above is an exercise in wasting memory and creating useless rules, or what exactly have I missed here?

@Asterix:

So I tried to create a IPv6 Whitelist to see if it helps by adding my gif tunnel remote address 2001:470:xxxx:xxx::1 but it gives me this error while reloading
I tried adding /64 in the end to that IP as well. Doesn't work.

Yeah, of course the /64 does not work. Should be 2001:470:xxxx:xxx::/1 without the bogus trailing 1. Other than that, seeing people shooting themselves in the foot by completely nonsensical blocking makes me wonder. WTF.

Educate me where you see the default deny inbound global (all countries) rule on a base pfSense install. PfBlocker has the settings unchecked and disabled at first install and is at users discretion to enable them how one wants for tighter control.

asterix

@Cino:

Create an alias outside of pfSenseNG for the IPv6 subnet you want to whitelist. Then add a manual permit rule to your floating rules (with quick checked). You will probably have to change the rule order to what I suggested before.

The IPv6 regex still needs some adjustments in pfBlockerNG. When we tested this a few months ago, I was able to get it work with some test IPv6 addresses I was using for testing. At the time, I couldn't locate any good list to thoroughly test like I did with IPv4

I will try it and if it doesn't work will hold off till there is a good update to the IPv6 address list.

doktornotor

@Asterix:

Educate me where you see the default deny inbound global (all countries) rule on a base pfSense install.

Nowhere. It's not visible, it's implicit. Anything not allowed is denied by default. Unless you have some "allow from any" rule you wish to restrict via country blocking on your WAN, there's just no point in creating inbound country-based rules at all.