3 ms·

I'll take what seems to be the contrarian view and say I really like the looks of this. There's nothing about this implementation that isn't at least as good as

I'll take what seems to be the contrarian view and say I really like the looks of this. There's nothing about this implementation that isn't at least as good as what came before, and almost every aspect of it is better (sometimes dramatically so, as in the case where you have a lot of rules). I'm not easy to please on firewall management questions, and consider FirewallD a step backward from plain old iptables on most fronts (though I understand it has value in laptops and other devices that have frequently changing networks). FirewallD is a different class of tool, of course, but it has some overlap...many of our customers demanded FirewallD support (our projects have a GUI for several firewall tools across Linux and the BSDs), even though it doesn't really make a lot of sense on a server. It seems clear that people don't love iptables unless they've been using it for years. I don't find iptables difficult (coming from ipchains, it was a breath of fresh air), but I understand folks who do, and this provides a clear improvement over iptables. So, even though I don't find iptables hard, I think I'll find this easier in a short time. Maybe the simplification of the "standard" firewall tool will help reduce the propagation of big firewall scripts and rule generators; I find them distasteful in that they generate huge lists of rules, most of which have no relevance to the deployment. So, it's often difficult to troubleshoot problems with the firewall because there's so much crap in there. Anyway, as others note, it does remind me of pf, which is a good thing. pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables).

e12e 10y ago
> pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables). Having just set up opensmtpd on Linux, and seeing how integrated pf is in such simple tasks on openbsd - what usecases do you have in mind that iptables is suitable for, but not pf? Honestly curious - I generally try to stay away from iptables as I mostly run small, private Linux servers - and I prefer just turning off services rather than fighting the duality of listen on port X on ip n and open firewall for service y on port X for ip n. I realize å lot of complex setups does need a bit of filtering though.
- SwellJoe 10y ago
  I am, by no means, an expert on pf, but I strongly suspect that many of the iptables extensions have no comparable capability in pf. Specifically, I don't know of any deep packet inspection extensions for pf, ipsec headers (such as authentication info) can be used for filtering decisions in iptables, iptables has some cluster capabilities built in, iptables has DCCP congestion control rules, and so on. iptables, like Linux itself, just has so many people working on it, that almost anything you can think to do with it has already been done by someone and they've created a module for it. If you haven't run into the missing capabilities, they probably don't matter. I'm not suggesting people who are happy with their pf firewalls should replace them with iptables because iptables is somehow "better". It just has a lot more users and a lot broader ecosystem because of it. To be more clear: I don't generally use any of those features that iptables has that pf doesn't, and I don't think most other people to either; at least no such features come to mind. I think I have once or twice used things like the user extension in nearly two decades of system administration. I'm always surprised at how strong people's aversion to iptables is. It's really not that complicated. I mean, most of the people here are writing software in far more complex languages daily and don't consider it a huge endeavor. iptables is a very simple declarative language, with only a few syntactical elements, in most cases. But, I guess it doesn't look like what folks are used to, and networking is its own category of complexity that many people never dive into.

e12e 10y ago

> pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables). Having just set up opensmtpd on Linux, and seeing how integrated pf is in such simple tasks on openbsd - what usecases do you have in mind that iptables is suitable for, but not pf? Honestly curious - I generally try to stay away from iptables as I mostly run small, private Linux servers - and I prefer just turning off services rather than fighting the duality of listen on port X on ip n and open firewall for service y on port X for ip n. I realize å lot of complex setups does need a bit of filtering though.

SwellJoe 10y ago
I am, by no means, an expert on pf, but I strongly suspect that many of the iptables extensions have no comparable capability in pf. Specifically, I don't know of any deep packet inspection extensions for pf, ipsec headers (such as authentication info) can be used for filtering decisions in iptables, iptables has some cluster capabilities built in, iptables has DCCP congestion control rules, and so on. iptables, like Linux itself, just has so many people working on it, that almost anything you can think to do with it has already been done by someone and they've created a module for it. If you haven't run into the missing capabilities, they probably don't matter. I'm not suggesting people who are happy with their pf firewalls should replace them with iptables because iptables is somehow "better". It just has a lot more users and a lot broader ecosystem because of it. To be more clear: I don't generally use any of those features that iptables has that pf doesn't, and I don't think most other people to either; at least no such features come to mind. I think I have once or twice used things like the user extension in nearly two decades of system administration. I'm always surprised at how strong people's aversion to iptables is. It's really not that complicated. I mean, most of the people here are writing software in far more complex languages daily and don't consider it a huge endeavor. iptables is a very simple declarative language, with only a few syntactical elements, in most cases. But, I guess it doesn't look like what folks are used to, and networking is its own category of complexity that many people never dive into.