Iptables Tutorial 1.2.2 | Hacker News Reader

Iptables Tutorial 1.2.2

frozentux.net

69 pointsfedericoponzi30 comments

www.frozentux.net uses an invalid security certificate. The certificate expired on October 19, 2017, 9:59 PM. The current time is October 20, 2017, 11:04 AM.

Here's an alternate url

https://web.archive.org/web/20170921014253/https://www.froze...

I hate to say it, but I will never forget the day I first stumbled upon PF.

Up to that point, setting up a router/firewall had been exceedingly painful, using Linux and iptables.

The syntax of pf.conf is beautiful. Somebody (I forgot who) once said that in order to write a rule set one needs to consult the (excellent) man page constantly, but once it is done, reading and understanding it takes no effort at all. As far as the "UI" goes, PF is so far ahead of anything I know of that most other metrics to judge a firewall / packet filter by seem to disappear.

Just to be clear: I have nothing against Linux, in fact most of my computers run Linux. But the syntax of pf.conf is just so sweet, once I tasted it, it spoiled me forever. And now iptables scripts look like something out of a Lovecraftian nightmare.

nftables is iptables' successor:

http://www.netfilter.org/projects/nftables

https://hn.algolia.com/?query=nftables

How mature is nftables? Do people regularly use it in production? I see that it was added to the kernel in 2014.

nftables probably works but usability is god-awful. AFAIK it was created by the same people who created tc, which is so unusable that Linux might as well not support traffic shaping. If you don't believe me, please go ahead and try using it.

Oh god, not tc. Anything but that.

It's like criticizing libpng library, tc is necessary complex.

This is more like hand-decoding Huffman tables in an especially convoluted representation when using Gimp to crop a PNG image.

That's really weird. I haven't used nftables, but I'm planning to do so the next time I upgrade my router. https://stosb.com/blog/explaining-my-configs-nftables/ makes it look nearly as pretty as pf. Is there something under the hood that's awful?

That actually doesn't look too bad.

I do wish they'd just adopted the PF syntax tho. It really is the gold standard for stateful firewall definition

Was anyone involved in the discussions around the creation of nftables that can comment on whether this was considered?

Let's see: Getting started

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page#...

None of these is anything like a tutorial or introduction. "Quick reference, nftables in 10 minutes" claims to be a ten-minute guide but it's actually just an information dump without any guidance.

Some highlights: "matches are clues used to access to certain packet information and create filters according to them." My translation: "Matches are conditions for rules to apply. They match certain properties (hyperlink) of packets."

"position is an internal number that is used to insert a rule before a certain handle." My translation: "position is an index into the list of rules. It can be used to insert rules at a given position in the list."

I don't know if my translations are correct due to the absurdly bad originals. It is like the authors explain verbs without explaining the nouns they act on. For the nouns, there are mostly just tables of them without any explanation at all. In other places, the few most important nouns are explained.

This alien logic is not only in the documentation, it is also in the syntax. Nobody I know thinks like that.

Wow, that NAT syntax is just plain awful as well. :-/

For reference: https://wiki.nftables.org/wiki-nftables/index.php/Multiple_N...

That example is made needlessly complicated to compress down to a one-liner and show off maps.

It does look nicer when properly formatted as part of a rule file, however.

The docs needs some work.

Yes, I see that now and yes those docs definitely need work.

It was declared ready for "experimentation" about a year ago or so, so not very mature. If you are on current upstream versions it is not too bad, I'm using it here and there on not very important things.

It is a bit hit and miss with kernel/nftables versions on release distributions. I probably would not use it with any kernels older than 4.10 for example. So any current LTS kernel is out.

Surprising to see iptables articles still being posted. Guess with the article being from a decade ago it makes sense, but here?

I wanted to use nftables but I think Docker doesn't support it.

Given that the underlying kernel implementation will be the same, it seems likely that you can fix that easily.

https://wiki.nftables.org/wiki-nftables/index.php/Main_diffe...

This tutorial is pretty old actually. Hope someone updates it, then we have nftables on the way to replace iptables, so might be just update to nftables directly.

I found 'nft', along with other commands such as 'ip' and 'tc' are pretty hard to use. I hope someone can create all possible auto-completion to guide the users, it is so hard to memorize those abbrev tags/options for those commands.

Being old and of itself isn’t bad. A lot of us are still using IPv4, and everything still applies. To few people know the basic concepts in this tutorial and can’t patch/fix problems that are trivial on any server.

OTOH, it’s really long for a tutorial and starts with a dissection of IP headers, the audience who needs it most have probably tuned out after the first dozen, and certainly by STCP.

For those referring nftables, there’s a LOT of stuff in iptables that doesn't work in nftables: from simple things like xt_time to complex ones like xt_TPROXY. so nftables isn't a viable replacement for iptables just yet. In theory there's a compat layer in nftables to get around those, but I have never able to successfully build a binary that works.

I'm currently working on an nftables setup script (removes iptables). I plan to release under gplv3. As I understand it nftables is designed to replace iptables (though they both use netfilter methinks), so I am ripping out iptables everywhere currently.

That said, I love the effort in this documentation.

Eventually someone or me should make a firewall 'fs' with fuse, it would map nicely and would be much less of a pain in the ass to work with.

Does anyone know of a humane QoS tutorial? I've tried to understand it a few times but it's been beyond me.

Please keep in mind that RHEL / Centos 7 has changed the default firewall from iptables to firewalld.

Isn't firewalld just a front-end for iptables?

Pretty much. It's basically a front-end for netfilter, which is actually what iptables is -- a way for the user/admin to interact with netfilter.

It's also an overly complex pain in the ass, IMO (but I've already dealt with ipfwadm -> ipchains -> iptables and not excited about having to learn yet another way to do it).

I think firewalls basically come down to matching a packet against an n-tuple of attributes and taking an indicated action. This is an oversimplification but this is how it looks when you view the rules.

I think that can potentially be expressed very simply and consistently with a basic grammar. You could still keep the concept of zones, which are a useful abstraction. Learning and applying something like that would be much quicker for me personally, because I don't normally work with it, and when I do, I just need something that gets the job done so I can move on.

UFW comes close, but it's use cases are limited and the syntax is not consistent - it changes based on what attributes you are matching.

Yep, ufw works well for relatively simple use cases. I've always written my rulesets by hand (since ipfwadm) -- even for ASAs and SSGs and so on -- and prefer to. When I started using Ansible, however, I started looking for an easier way and have since switched to using ufw on all Ansible-managed (RHEL/CentOS) publicly-accessible hosts.

I tried using firewalld (on RHEL/CentOS) since that's now the "official way" but I just had too many issues, said "f--k it", and gave up on it. Mostly I didn't like that it tried to be helpful and auto-create certain rules (that I didn't need nor want) but I also had issues with it not respecting the ordering of my rules. Creating a "raw" iptables ruleset (one that can be loaded with iptables-restore) gives me complete control over my firewall rules -- and that's what I want.

Reply on news.ycombinator.com