OPNsense Forum
English Forums => General Discussion => Topic started by: chrcoluk on January 11, 2018, 08:33:40 pm
-
Hi guys.
My friends have already migrated to opnsense from pfsense, and I agree with the reasons they migrated, so am looking to migrate myself also, but the showstopper for me at the moment is pfblockerng.
I use it for 2 purposes.
1 - To load up DNSBL lists in my firewall to reroute traffic to a blackhole http server that hosts an empty image. I know I could probably get this working manually like I used to on asuswrt, but I would much prefer a simpler solution provided within opnsense somehow.
2 - To load up ASN lists for the purpose of classifying traffic.
Has anyone got a solution to these problems? thanks.
-
ASN lookup for policy routing is a necessary feature for me as well. Also see https://forum.opnsense.org/index.php?topic=5964.msg24801#msg24801.
-
PFBlocker is definitely much better than OPNSense's GEOIP functionality. The OPNSense solution is a machete while PFBlocker provides you with a full suite of knives from machete to scalpel.
Some features that I wish were included in the OPNSense GEOIP include:
(1) Being able to permit or deny from countries/regions on a protocol and port basis. For example, with PFBlocker, I can rely on the "deny all" rule to block traffic but open up access to ports 22, 80, and 443 for TCP and port 1194 for UDP from IPs only originating in $MY_COUNTRY. In contrast, OPNSense only allows me to deny all traffic or permit all traffic from $COUNTRY.
(2) Have separate GEOIP rules for inbound and outbound traffic. It's a little bit easier to conceptualize and fine-tune your rules, especially if you have different sets of countries you want to include in your inbound and outbound lists (like I do).
(3) DNS Blacklisting and Blocking - PFBlocker does a pretty good job of filtering ads and other unwanted content at the network level. However, there are ways to incorporate this into UnBound using blacklists.
-
Huh? Are you talking about Geo IP Filter as Alias table or in IPS? With Alias table you can achieve everything like in pfBlocker Geo IP
-
I guess there have been quite some misunderstanding of what's possible in OPNsense in regards to GEO support:
(1) Easy to do, create an alias for your selected countries and add a firewall rule using that alias.
(2) Same as (1) with floating rules if you want to select "direction"
(3) Likely also possible with an "url table" alias (for example using http://www.spamhaus.org/drop/drop.txt)
The "rerouting" functionality is probably a port forward to a local host and address, which should also be possible with aliases (and portforward rules).
We choose to incorporate most important alias features in our core product in stead of adding another plugin overlapping quite some functionality of what's already in there. Our 18.1 version will also incorporate a rewrite of the code behind the aliases (and supporting more frequent updates), but all described above have been in OPNsense for quite some time already (at least more then a year).
For custom aliases you can use an external type alias, which won't be touched by OPNsense and can be used in the firewall and nat rules. This is available as of 18.1.
-
What options are available to create aliases using ASNs?
-
in 18.1 you could add an "external" alias and fill the contents with a custom script (for example use the one you already created).
using the following command to load the table:
pfctl -t my_ext_alias -T replace -f list_of_aliases
Show the contents (also possible from the gui):
pfctl -t my_ext_alias -T show
-
For the DNSBL, you can try following this:
https://devinstechblog.com/block-ads-with-dns-in-opnsense/
I'm also researching the possibility of creating a version of the script in that post that will create external aliases as well.
-
just a quick update guys.
I am making a CLI system which will handle my needs in the short term, it will be shared here in the community when its in a workable state, from that point I hope we can all together progress it and maybe add a GUI at some point as well. I will post back when I have further news on this.
AdSchellevis yep my plan will be to utilise any existing opnsense features where they exist such as the alias tables.
-
ASN lookup for policy routing is a necessary feature for me as well. Also see https://forum.opnsense.org/index.php?topic=5964.msg24801#msg24801.
yep thanks
-
Rather than go back and edit an earlier post, I will just post again and admit I was wrong.
It turns out that OPNSense does allow for pretty fine grained control of ingress and egress GeoIP blocking using aliases. The issue is the documentation and the fact that OPNSense provides two mechanisms for GeoIP filtering. The documentation refers to the one builtin to the IDS/IPS system. That one is rather underwhelming (and somewhat buggy for me). The other is provided using PF aliases and is pretty feature rich and flexible. I like it a lot more than the one included in the IDS/IPS. However, it the system using aliases is discouraged in the documentation and it’s existence is not readily apparent from the table of contents.
-
I'm quite sure after 18.1 release there will be a focus on updating the docs :) Thanks for you patience with GeoIP 8)
-
Ah, but if the docs are all correct then it spoils the voyage of discovery.. :P
-
Docs are never complete :D
-
Hear's the saying, if you need the docs you shouldn't be playing.
Read them, tell yourself they are all wrong and then ask someone. 8)
-
That's definitely true. However, pfBlockerNG is such a condensed Swiss army knife tool that users can end up failing to express their needs in firewall feature terms. They look for a single place to do it all and ask here if they can't find it.
So pfBlockerNG gives a very easy to use integration into pfSense, an experience that is hard to emulate with the philosophy that we try to follow with OPNsense. It's neither good or bad. Maybe documentation can help, maybe it can't. But it's worth a try. :)
Cheers,
Franco
-
That's definitely true. However, pfBlockerNG is such a condensed Swiss army knife tool that users can end up failing to express their needs in firewall feature terms. They look for a single place to do it all and ask here if they can't find it.
So pfBlockerNG gives a very easy to use integration into pfSense, an experience that is hard to emulate with the philosophy that we try to follow with OPNsense. It's neither good or bad. Maybe documentation can help, maybe it can't. But it's worth a try. :)
Cheers,
Franco
Why is hard to add feaures from pfBlockerNG to opnsense?
What has to do this with the "philosophy"?
pfBlockerNG is an excellent tool and opnsense should aim to replicate most of the functionality.
There are plenty of open source firewalls, what the market needs is one that integrates UTM functionalities. AV (not just clam AV which has a bad detection rates), suricata, OpenAppID, SNORT V3, Advanced thread protection functionality (anti APT), web filter, ad filter, ip filters, integration with external APIs like cuckoosandbox, Virus total, etc. the first open source firewall (osf) to get into this state will take the market from the others osf.
Either you get this from open source software or you start to look for optional and comercial alliances in the market.
Opnsense should focus on this and nothing else, if someone wants just a firewall is a no brain to pick pfsense over opnsense.
-
And yet, we all here picked OPNsense over pfsense.. and many coming from pfsense.
-
Opnsense should focus on this and nothing else, if someone wants just a firewall is a no brain to pick pfsense over opnsense.
You can do pretty much everything in Opnsense that pfSense + pfblockerng can do, it just takes a bit more thought. I also came over from pfSense, I will not be going back, however the choice is yours. If pfSense floats your boat then stay with it.
-
That's definitely true. However, pfBlockerNG is such a condensed Swiss army knife tool that users can end up failing to express their needs in firewall feature terms. They look for a single place to do it all and ask here if they can't find it.
So pfBlockerNG gives a very easy to use integration into pfSense, an experience that is hard to emulate with the philosophy that we try to follow with OPNsense. It's neither good or bad. Maybe documentation can help, maybe it can't. But it's worth a try. :)
Cheers,
Franco
Why is hard to add feaures from pfBlockerNG to opnsense?
What has to do this with the "philosophy"?
pfBlockerNG is an excellent tool and opnsense should aim to replicate most of the functionality.
There are plenty of open source firewalls, what the market needs is one that integrates UTM functionalities. AV (not just clam AV which has a bad detection rates), suricata, OpenAppID, SNORT V3, Advanced thread protection functionality (anti APT), web filter, ad filter, ip filters, integration with external APIs like cuckoosandbox, Virus total, etc. the first open source firewall (osf) to get into this state will take the market from the others osf.
Either you get this from open source software or you start to look for optional and comercial alliances in the market.
Opnsense should focus on this and nothing else, if someone wants just a firewall is a no brain to pick pfsense over opnsense.
Why do you think commercial vendors hire lots of people? This is tough work and here are only volunteers doing this in spare time. Also it's not our ambition to "take over the market". ;)
Please feel free to find a AV vendor supporting current BSD .. If there was one, we would have a plugin yet
-
Why is hard to add feaures from pfBlockerNG to opnsense?
What has to do this with the "philosophy"?
1. Nobody has done it so far. It it were easy, it would have been done. Isn't that a safe assumption? :)
2. I tried to explain this: we don't want pfBlockerNG as a powerful condensed type of plugin, we want to integrate the underlying features into the system in a natural way. We don't want a single point of entry for said functionality. This is "[design] philosophy".
pfBlockerNG is an excellent tool and opnsense should aim to replicate most of the functionality.
I concur. :)
There are plenty of open source firewalls, what the market needs is one that integrates UTM functionalities. AV (not just clam AV which has a bad detection rates), suricata, OpenAppID, SNORT V3, Advanced thread protection functionality (anti APT), web filter, ad filter, ip filters, integration with external APIs like cuckoosandbox, Virus total, etc. the first open source firewall (osf) to get into this state will take the market from the others osf.
Good list. We do have some of these features. Some will be added later for sure. Note that your own list does not mention "pfBlockerNG".
Either you get this from open source software or you start to look for optional and comercial alliances in the market.
True. :)
Opnsense should focus on this and nothing else, if someone wants just a firewall is a no brain to pick pfsense over opnsense.
This is a bit too narrow. Going back to what you said about UTM features:
Haven't we not added several of those over the course of this project's history?
Are we unwilling to add more of those? If yes, where did you interpret that?
Are you taking this exact moment and try to argue that the system is not good enough? That's true, but then again it's always true:
There will be more features, more bugs, more alignment with the needs of the user base as that grows and shifts.
So today we're not adequate, tomorrow we're also not adequate, but at least more adequate than today. That's what counts and your discussion does not take that into account because maybe you've come here very recently, expected to find something that you need but didn't. :)
Cheers,
Franco
-
I find that using IPS for the 10 'worst' offending countries and GeoIP Aliases for everything else works very nicely. Keeps my firewall logs cleaner.
-
Is there a way to import lists of FQDNs such those listed on https://tspprs.com/ (and have them automatically updated) into an Alias? If I'm understanding this correctly, I would then be able to assign that alias to a firewall rule and I'd have similar functionality as with PiHole or pfBlocker.
-
You can Block these with Bind Plugin, but no chance for an Alias yet
-
Definitely not easy to code but also as martin said I realised not all of it needs scripting, at least a few functions of pfblockerng can already be done in opnsense, just using a different procedure.