I would really love to see "pf" on Linux.

When I began using Linux, "ipfwadm" had just been incorporated into the kernel. It was replaced in 2.2 by "ipchains" which was replaced in 2.4 by "iptables". Now we have "nftables".

I'll admit to not knowing much about nftables but from what I've read about it in the last few days, it's still not even close to what OpenBSD's "pf" is capable of.

Ahhh, well, I can wish, right?

Given that the kernel portion of nftables appears to just be a byte code interpreter, it probably would be possible to make something that takes pf syntax and puts out nftables byte code.

I think that would be pretty slick. As a long time pf user, I've always preferred it's syntax, and the nftables syntax looks like a step in the right direction at least, given the horror that was previous syntax methods.

I've heard this about every linux firewall, can you give some good examples of what either iptables or nftables can't do that pf can?

I don't have good examples of what can or cannot be done.

But I find pf much easier to understand. I can write pf rules myself and understand, clearly, what my firewall is doing. I haven't found iptables near as approachable, and depend on firewall configuration tools to generate the rules and chains for me.

I'd definitely agree that iptables is not nearly as approachable as i've seen pf be. I've yet to see something that can't be done with it if you take the time (this is discounting performance, i know that it can get a little hairy after a few hundred rules if not setup correctly).

Many people use something like denyhosts or fail2ban to help with brute force attacks. PF has built-in support for building rules with options which will throw potential attackers into a 'penalty box' based on certain factors like connection rate.

You can use iptables for that:

  $ sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

  $ sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

Copied from http://kvz.io/blog/2007/07/28/block-brute-force-attacks-with... but I agree that pf ist just much more sane config wise.

Since nftables is supposed to be backwards compatible, I'd guess it can do this too. I wonder what it'll look like for that. A lot of the other syntax looks nicer, i suspect that this will be better too.

That one I haven't seen before, I wonder if the new nftables might be able to implement any of that. Based on the state machine specs probably not, since I don't think there's any storage or any way for it to generate new rules on itself based on what I've read.

I've found PF easier to get started with and more manageable due to the config syntax. Now onto something that PF can do but iptables can't: address family translation. There is a module somewhere on github that does NAT64, but is somewhat limited compared to PF. Now if you want to go the other way around, i.e. NAT46, it is currently not possible on Linux in kernelland.

its not about what can be done, its about the learning curve and conciseness of the rules. pf has nice user space tools and easy, powerful syntax.

netfilter's iptables syntax well.. over the last, what, 10 years? we all got used to it. seems like nftables is going to required another 5 to become more or less known among people...

Anchors?

Tables?

Or my very favourite: last match wins, which shortens your ruleset considerably.

Anchors look suspiciously like creating a new chain in iptables. Tables there doesn't seem to be any direct analog, though can be done similarly by creating a chain that matches the list of addresses you're interested in and forwarding the rules there.

That said both of pf's versions look better than iptables. nftables looks like it does a better job of this like pf does, which is definitely a good thing.

I've used all of the above. pf is much, much over-rated. iptables is just about as capable. Plus, in a speed test I did a while ago, a Linux firewall vastly outperformed an OpenBSD firewall on the same hardware, in terms of amounts of traffic it could handle before keeling over and dying.

OpenBSD is neat, but creating a cult around it doesn't help with anything.

>I would really love to see "pf" on Linux.

Well, there's at least a Linux port of FreeBSD's ipfw and dummynet: http://info.iet.unipi.it/~luigi/dummynet/. I tried it briefly on my home server (Ubuntu 12.04 LTS with a stock 3.2.0 kernel) and it appeared to work as expected with rulesets written for FreeBSD.

I woudn't, pf is good and the learning curve is easier but Iptables is more advanced and powerful ( many modules that don't exist in pf )

Sorry, NIH. And we won't see dtrace either

DTrace and ZFS are both available for Linux as out-of-tree kernel modules. Sun intentionally used a GPL-incompatible license... it has nothing to do with NIH.

Even the Linux clones of DTrace are gratuitously incompatible when it probably would have been easier for users to clone DTrace exactly.

nftables sounds like a great example of why you should learn compilers: http://steve-yegge.blogspot.com/2007/06/rich-programmer-food... You can write reams of code that work, but still have limits, and overcoming those limits would require further endless reams of code (iptables). Or you can write something simpler that breaks the problem down into primitives which a compiler will let you put together arbitrary ways, and despite being more flexible, is still less code (nftables).

snapshot in case the server is overwhelmed : http://archive.is/M1R6K

Being able to load a whole configuration with nft -f instead of having to hack a script to do the same is also a nice feature (makes it more pf-like)

This is easy with iptables too:

  iptables-restore < yourfilterfile

Yeah.. true.. still prefer the config file format[1] nftables brings along though.

[1] https://home.regit.org/netfilter-en/nftables-quick-howto/