Iptables Tutorial 1.2.2(frozentux.net)
frozentux.net
Iptables Tutorial 1.2.2
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
10 comments
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.
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
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.
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.
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.
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.
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?
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.
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...
For reference: https://wiki.nftables.org/wiki-nftables/index.php/Multiple_N...
Oh god, not tc. Anything but that.
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...
https://wiki.nftables.org/wiki-nftables/index.php/Main_diffe...
Surprising to see iptables articles still being posted. Guess with the article being from a decade ago it makes sense, but here?
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.
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.
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.
Copyright 2006, "...the new Linux 2.4.x kernels", dead SSL cert
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.
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).
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.
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.
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.
Here's an alternate url
https://web.archive.org/web/20170921014253/https://www.froze...