The syntax is not a problem. The problem is in the performance. I suppose that if I configure OpenBSD to process the in/out packets only to layer 2 the performance will be much more than linux with iptables.
I don't know jack about IPSet, but I know enabling or disabling hosts in bare stock PF without the gui in front of it is about as easy as it gets.
IPTALES is the same;
iptables -A [INPUT/FORWARD] -d -j [REJECT/DROP]
The PF configuration file syntax was designed from the ground up to be sane, unlike iptables, which typically needs some decent sysadmin scripting or using fwbuilder to make any good sense of.
I beg to differ here. IPTABLES is not that hard when you understand it. Like anything else, once you know what you are doing it isn't that hard. And no, I have never used any GUI program to configure my firewalls.
There is no finer opensource firewall product on the market, in terms of performance, ease of configuration and use, and other issues.
This is all subjective to the user. I would say that PF is a nightmare and IPTABLES is easier to use.
If you're not opposed to vi, for what you're looking to accomplish, moving to BSD and pf is a no-brainer. PF can definitely handle a list of 500 hosts and anything else you've mentioned. It's absolutely capable, easier, and in general, for anything that involves packet filtering at all, about as good as it gets.
Again this is all subjective to the user.
--
Regards Robert
Linux User #296285 http://counter.li.org _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
So basically, you're saying you'd want to allow or disallow traffic based on mac address? Seems like you could put mac filters on a number switches, Cisco being the most easily documented by Mr. Google.
Be a lot faster than any kernel, and a total waste of BSD. If you can do it on Linux via some other mechanism, go for it.
The fact is, PF will do line rate layer 3 packet filtering if you've got the hardware to support it. Try and and see.
Peter
On Fri, Dec 18, 2009 at 10:49 PM, sadas sadas mailrc@abv.bg wrote:
The syntax is not a problem. The problem is in the performance. I suppose that if I configure OpenBSD to process the in/out packets only to layer 2 the performance will be much more than linux with iptables.
I don't know jack about IPSet, but I know enabling or disabling hosts in bare stock PF without the gui in front of it is about as easy as it
gets.
IPTALES is the same;
iptables -A [INPUT/FORWARD] -d -j [REJECT/DROP]
The PF configuration file syntax was designed from the ground up to be sane, unlike iptables, which typically needs some decent sysadmin
scripting
or using fwbuilder to make any good sense of.
I beg to differ here. IPTABLES is not that hard when you understand it.
Like
anything else, once you know what you are doing it isn't that hard. And
no,
I have never used any GUI program to configure my firewalls.
There is no finer opensource firewall product on the market, in terms of
performance, ease of configuration and use, and other issues.
This is all subjective to the user. I would say that PF is a nightmare and
IPTABLES is easier to use.
If you're not opposed to vi, for what you're looking to accomplish,
moving
to BSD and pf is a no-brainer. PF can definitely handle a list of 500 hosts and anything else you've mentioned. It's absolutely capable,
easier,
and in general, for anything that involves packet filtering at all,
about
as good as it gets.
Again this is all subjective to the user.
--
Regards Robert
Linux User #296285 http://counter.li.org _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Serwe wrote:
So basically, you're saying you'd want to allow or disallow traffic based on mac address? Seems like you could put mac filters on a number switches, Cisco being the most easily documented by Mr. Google.
Be a lot faster than any kernel, and a total waste of BSD. If you can do it on Linux via some other mechanism, go for it.
Or perhaps use a VLAN trunk to the switch with the devices you want to isolate on different VLANs. This gives you a different interface/subnet per VLAN for more natural control.
I'd argue handling it at the layer 3 level to be preferable than splitting every customer into their own vlan.
If you split into vlans like that, if you have single-box customers, you'll have to have subnet boundaries for every /30...
OTOH, vlan isolation for customers is pretty much the norm, as long as you've got the IP's to waste, why not..
Peter On Sat, Dec 19, 2009 at 8:42 AM, Les Mikesell lesmikesell@gmail.com wrote:
Peter Serwe wrote:
So basically, you're saying you'd want to allow or disallow traffic based on mac address? Seems like you could put mac filters on a number switches, Cisco being the most easily documented by Mr. Google.
Be a lot faster than any kernel, and a total waste of BSD. If you can do it on Linux via some other mechanism, go for it.
Or perhaps use a VLAN trunk to the switch with the devices you want to isolate on different VLANs. This gives you a different interface/subnet per VLAN for more natural control.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sadas sadas wrote:
The syntax is not a problem. The problem is in the performance. I suppose that if I configure OpenBSD to process the in/out packets only to layer 2 the performance will be much more than linux with iptables.
You know SQUAT about filtering on Linux. You want a bridging solution? Then forget about Linux. Even FreeBSD will perform better at bridging firewalling than Linux and OpenBSD is the best performer available.
That ipset solution came way after OpenBSD and pf had such a feature and which was already mature and stable too. I should know, I tested ipset while it was still new some years ago.
-
Chan Chung Hang Christopher -
Les Mikesell -
Peter Serwe -
sadas sadas