NFTables To Replace iptables In the Linux Kernel 235
An anonymous reader writes "NFTables is queued up for merging into the Linux 3.13 kernel. NFTables is a four-year-old project by the creators of Netfilter to write a new packet filtering / firewall engine for the Linux kernel to deprecate iptables (though it now offers an iptables compatibility layer too). NFTables promises to be more powerful, simpler, reduce code complication, improve error reporting, and provide more efficient handling of packet filter rules. The code was merged into net-next for the Linux 3.13 kernel. Iptables will still be present until NFTables is finished, but it is possible to try it out now. LWN also has a writeup on NFTables."
again? (Score:5, Interesting)
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
Re:again? (Score:5, Interesting)
And the iptables docs haven't even been finished yet. I was at the North Carolina Biotechnology Center at the Linux Expo in 1997 when one of the speakers that was talking about iptables promised they would write docs for it. I think I was the only teen girl and only black female there, so if you were there, you'll probably remember me. How about finishing what you start rather than screwing the users with half-ass unfinished projects?
Re:again? (Score:5, Insightful)
Documentation: There is a quick howto available at Eric Leblond's website.
Yeah I guess a "quick howto" isn't quite going to cut it. I wonder if Linus would ever put his foot down and say "no docs = no patch accept".
Re:again? (Score:5, Funny)
Don't you know? Open-source software doesn't need docs, because the best docs available are the sources.
Re: (Score:2, Insightful)
Don't you know? Open-source software doesn't need docs, because the best docs available are the sources.
It's the most comphrehensive, but also one of the more incomphrehensible not fluent in code.
Yes, because then you can say that subtle bugs are actually features! It is great!
Seriously, I know both of you are joking. But this is a bad joke that should be put down once and for all. Documentation describing the intended function of a program can help you find the bugs that cause inconsistent behavior. Using source as documentation is not even an option the most skilled programmers. As long as we do not have mind-reading skills there is no way of knowing what the original programmer intended.
Captcha:
Re: (Score:2, Funny)
Re: (Score:3)
I've always found the iptables tutorial from frozentux to be reasonablly comprehensive, maybe it's missing some really fancy stuff but the important stuff about the theory of operation and what the targets do is all there.
Re: (Score:2)
I learned iptables from the data available online pretty quickly. There are lots of good guides and a decent man page too.
Granted, I already understood ipchains very well at the time it was released but I don't see the need for much more extensive documentation.
Re: (Score:2)
Well, there's a point in abandonning a project that can't even document itself.
But I'd disagree. Iptables was a huge success, and the fact that the official docs isn't that good was eclipsed by how powerfull the software is. But there's a point when you can't simply add features to an old software anymore, and needs to start from scratch. Looks like we are at that point.
Re:again? (Score:5, Interesting)
Hear hear! A bit of background to the politics of this:
NFTables is brought to you by a group of codes created when Alexey Kuznetsov decided to replaced the low level linux network stack for Linux 2.2 to make it more like what Cisco provided in IOS. The result added whole pile of new functionality to Linux (eg routing rules), and a shiny new highly module traffic control engine. Alexey produced a beautifully written postscript documentation [smc.edu] for the new user land routing tools (the "ip" command), and 100 line howto [columbia.edu] for the far more complex traffic control engine tools (the "tc" command).
Technically it was a was tour de force. But to end users it could at best be called a modest success. Alexey re-wrote the net-utils tools ("ifconfig", "route" and friends) to use the new system, and did such a good job very few bothered to learn the new "ip" command even though the documentation was good and it introduced a modest amount of new features. But real innovation was the traffic control engine, and to this day bugger all people know how to use it.
At this point it could have gone two ways. Someone could have brought tc's documentation up to the same standard Alexey provided for ip, or they could ignore the fact that almost no one used the code already written and add more of the same. They did the latter.
It was also at this time the network code wars started in the kernel. Not many people know that a modest amount of NAT, filtering and so on can be done by Alexey's new ip command. But rather than build on that Rusty Russell just ported the old ipfwadm infrastructure, called it ipchains (and later replaced it with iptables). There was some overlap between Rusty's work and tc, and this has grown over time. For example the tc U32 filter could do most of the packet tests ipchain's introduced over time on day 1. Technically the modular framework provided by tc was more powerful than ipchains, and inherently faster. Tc was however near impossible for mere mortals to use even if they had good documentation. There were some outside efforts to fix this - tcng [sourceforge.net] was an excellent out-of-tree attempt to fix the complexity problems of tc. But in what seems like a recurring theme, it was out of tree and ignored. In contrast, Rusty provided ipchains with the some best documentation on the planet. In the real world the result of these two efforts are plain to see - while man + dog uses iptables, there maybe 100 people on the planet who can use tc.
Another example of the same thing is IMQ [linuximq.net]. IMQ lets you unleash the full power of the traffic control engine on incoming traffic. (Natively the traffic control engine only deals with packets being sent, not incoming packets - a limitation introduced for purely philosophical reasons). IMQ was very well documented, and heavily used. The people who brought you tc had a list of technical objections to IMQ. I don't know whether they were real or just a case of Not Invented Here, but I'd give them the benefit of the doubt - they are pretty bright guys. So they replaced it with their own in-kernel-tree concoction. (For those of you who don't follow the kernel "in-tree" means it comes with the Linux Kernel. An out-of-tree module like IMQ means at the very least you have to compile the module source, and possibly the entire kernel.) For a while this discouraged the developers of IMQ so much they stopped working on it. If you follow that link, you will see it's back now. Why? Because the thing that replaced it had absolutely no documentation. They never do. So no one could use the replacement. Again, in the end, the thing code that was documented won the day.
By now you might be guess where this is heading. We have two groups in the kernel competing to provide the
Re:You go girl :D (Score:5, Informative)
Don't worry, iptables and arptables aren't going to magically disappear. A ridiculous amount of infrastructure depends on both, and the nftables announcement is severely over-hyped. Having alternatives is a good thing, and it doesn't mean the sky is falling.
Look to the real culprit (Score:2)
somebody decides they have a better way, and rather than keeping the two available until one stops being maintained they go and dump one as 'inferior'
To be fair, the kernel developers have (to my knowledge) never done this. If you have ever compiled a kernel yourself, you will have seen that new features are flagged as "experimental", older features as "deprecated", and defaults are applied judiciously.
You will most likely find that it is your distribution that is most guilty of foisting bleeding-edge, half-tested stuff on to its users. Linus and the kernel devs are (and have to be) almost fanatically conservative.
Re:again? (Score:4, Interesting)
Going to a random page: "If the IP filter implementation is strictly following the definition, it would in other words
No, "in other words" is only appropriate after you've worded things once and are about to re-iterate using different terminology, in other words are using "other words" to describe the same thing.
Re: (Score:2)
"Chain - A chain contains a ruleset of rules that are applied on packets that traverses the chain."
Recursion: see recursion
This is like shooting fish in a barrel. With dynamite. Whoever wrote that document should be ashamed. Or shot, to prevent him producing such crap again.
Re: (Score:2, Insightful)
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
Go to bed, grandpa. It will be transparent to the end user. I'm looking forward to it.
Re:again? (Score:5, Insightful)
Not trying to troll or flame here, BUT...
That's not the fault of "progress", it's just a Linux thing... Same thing happened with audio, file systems, and much more.
The BSDs:
* haven't changed their audio systems since their inception.
* Kept their file systems backwards-compatible for decades, and did not have a flood of XFS/JFS/ReiserFS/etc. options. There have been changes recently, but incredibly few by comparison.
* Used the powerful and simple IPF as their stateful firewall dating back before many /.ers were born... at least 1993 or so. Only changed to PF (with very similar syntax) after IPF's license was changed, and all the BSD still use it. There are some alternative projects, but again, even with several BSDs, there's still less churn than with Linux.
Re:again? (Score:4, Informative)
And they're down to 1.1% [w3techs.com] of all web servers, all FreeBSD. From the list of "Popular websites using FreeBSD" only one is in Alexa's top 500 and that's php.net [alexa.com]. The Alexa rankings:
php.net: 229
turbobit.net: 557
jvzoo.com: 771
cpanel.net: 1096
neoseeker.com: 5488
starpulse.co: 5818
salespider.com: 4710
weblancer.net: 5125
extranetinvestment.com: 5834
msi.com: 6702
It is literally less than a handful (the top four) that means BSD even still has a presence and 80% of that is probably just one site. I guess BSD code is lots of places like in OS X and embedded and routers and whatnot but BSD is practically dead as a server (cue and queue the Netcraft and Monty Python jokes, please take a number). Who, at this point, would be interested in building a new network stack for BSD? I guess Juniper would since they use it for Junos, but honestly not that many others...
Re: (Score:2)
Sure enough, I got NetDisco working and everything seemed great, until I decided to run and update on the system...
Still can't get apache to load... probably going back to openSUSE...
Re:again? (Score:4, Informative)
Re: (Score:3)
Who, at this point, would be interested in building a new network stack for BSD?
Nobody. Because it is excellent already. Ask ISPs.
Your argument for change for change's sake is invalid.
Also it's an obvious fallacy to restrict yourself to looking at www only.
Either you're stupid/ignorant, or you really are a troll. I'll give you the benefit of the doubt.
Re: (Score:2)
Only changed to PF (with very similar syntax) after IPF's license was changed, and all the BSD still use it ... there's still less churn than with Linux.
The BSD's are definitely more stable. Linux makes more progress, sometimes by adopting other projects' work when it's better. There's no way to have both rapid progress and stability, so it's good that the community has a choice (I avoided saying 'communities' on purpose).
I've been using BSD for routing and firewalling for about a decade, first by m0n0wal
Re: (Score:2)
cat iptables | ip2if_compile | iftables_decompile
Passing it through a compiler to the iftables virtual machine and then decompiling/describing avoids some "that phrases does not translate" problems. If one can't compile arbitrary iftables code for the vm, then the vm is formally incomplete (:-))
--dave
Re:again? (Score:5, Informative)
There is an intersection between the tasks iptables/ebtables/arptables can perform, so someties you need to decide which responsibility you want to delegate to which.
But you are correct, ebtables was never a replacement.for iptables.
This diagram [wikimedia.org] is very useful when you get deep in the weeds.
Bah (Score:5, Funny)
IPChains work just fine thank you very much!
Kernel 2.4 works fine for my needs. You kids today have no idea what it is like upgrading thousands of computers at work! Especially when you have to justify to a beancounter to upgrade an IP table that has worked fine since October 2001 and already works. It is an enterprise standard that works so why fix what isn't broken?
Last thing I need is another confusing IP table interface designed for teenagers.
With a modern AV I should be just fine if I do not go to questionable websites.
Re: (Score:3, Insightful)
Re: (Score:2)
Not to mentioned 2.4 was iptables already.
Ipchains was 2.0, maybe 2.2, if I recall.
Re: (Score:3)
Being unsupported is not a death sentence.
As long as iptables/ipchains works, and/or you don't have a ton of open ports, there's really no problem running old kernels.
80% of the routers in the world are running some really old kernels and have/will never get updates. Baring any newly discovered backdoors,
they are as secure today as they ever were.
Re:Bah (Score:5, Insightful)
All malware today uses ports 80 and 443. Port-based firewalling is a meaningless ritual from the previous century.
Re:Bah (Score:5, Insightful)
All malware today uses ports 80 and 443. Port-based firewalling is a meaningless ritual from the previous century.
I think you're confusing cause and effect, if we didn't have port based firewalls we'd still have Blaster-style worms spreading like wildfire. Because we've locked things down to a few approved ports, naturally that's where they try getting in.
Re: (Score:3)
That's not true -- port based firewalling prevents inbound packets to services you want to run but don't want to be accessed from the outside.
Re: (Score:2)
Much better to think in terms of servers you want to run but don't want to be accessed from the outside.
Re: (Score:2)
Well, that was really my point. Modern malware has nothing to do with looking for an open port with a vulnerable service listening on it, and hasn't for quite some time. The malware uses port 80/443 in the sense that the "vulnerable services" are now browser plug-ins, and users who download and run stuff.
Heck, the continuous hassle of negotiating with IT over ports has moved most legitimate enterprise software onto only ports 80 and 443 as well. On reason why "everything's a web service" now is to get IT
Re: (Score:2)
Second point: why would you need some kind of interface to your firewall rules. Its a text f
Re: (Score:2)
Not to mention, keeping a lot of said management facilities operational can very often waste as much time as they save. Another example is proprietary switch stack clustering protocols. They cost as much to manage their quirks and work around their defects as they save, unless you have a truly massive and abnormally homogeneous set of systems.
Re: (Score:2)
Noooooo (Score:5, Funny)
All my precious iptables knowledge gone!
Linus hates us precious! Hates us!
Re:Noooooo (Score:5, Interesting)
Okay so after RTFMing, I like the changes.
It reminds me of the ip command, which is so much better than route.
NFTables FTW!
Re: (Score:3)
IPv6 NAT is possible
I didn't realize they were working on that.
Re:Noooooo (Score:5, Interesting)
When NAT came in it was a pity we needed that shit due to a lack of numbers instead of having everything adressable, and now for some reason people like the smell of that shit. They think it smells like security.
If you think I'm wrong please spend at least five minutes learning how a firewall works and look up router on wikipedia or something before you reply. You should work out from that that the devices that provide the security will still be upstream whether you have NAT or not.
Re: (Score:3)
Re: (Score:2)
Topology hiding, sure throw away.
Loadbalanced multihoming is usefull. And the nice thing about it is that it does not strictly require NAT, it's just an implementation detail that could be changed.
Re: (Score:3)
All my precious iptables knowledge gone!
Linus hates us precious! Hates us!
1 minute later...
Okay so after RTFMing, I like the changes.
NFTables FTW!
Re: (Score:2)
There is so much depth to iptables that not one in 10,000 people ever used, that getting your head around the basics
was always a problem of separating wheat from chaff. You could literately route packets in circles, for what purpose I can't imagine.
I suspect the Netfilter folks haven't removed any of this, and merely hidden it.
Re: (Score:2)
You could literately route packets in circles, for what purpose I can't imagine.
Here is the best purpose for routing packets in circles I've ever seen: http://www.youtube.com/watch?v=Hkcdstw0qxU [youtube.com]
pf (Score:5, Informative)
Can't we have OpenBSD pf instead? Powerful, nice, decent documentation on how to use it, syntax that makes a lot more sense than iptables.
Re: (Score:2, Interesting)
Can't we have OpenBSD pf instead? Powerful, nice, decent documentation on how to use it, syntax that makes a lot more sense than iptables.
That would be nice. I was very happy when pf was imported into NetBSD (my preferred BSD). iptables is just meh in comparison. I'll reserve judgment on this NFTables until I see it for myself.
Re: (Score:3)
1) Use OpenBSD
2) Use FreeBSD
3) Use Debian with a FreeBSD kernel [debian.org]. This is debian and the kernel has PF. You get everything you want.
Re: (Score:2)
Go right ahead.. It's a free download.
Re: (Score:2)
Sure. You can use it in OpenBSD, in FreeBSD, in NetBSD or in OSX.
Re: pf (Score:2)
Re: (Score:2)
If you weren't already +5 informative, I would have up-voted you. pf has syntax so logical it's almost like speaking English. Then, in comparison, you have to memorize a variety of command flags to get anything done with iptables.
Mind you, personally i'm a FreeBSD user and (I think?) you can't actually get iptables for *BSD, and I don't have much use for a complicated firewall setup,
I really like the idea (Score:5, Interesting)
The main advantage of this is moving protocol knowledge out of the kernel into userspace.
Which means that the kernel doesn't need a million modules that understand the various bits of various protocols. If something new comes up, the userspace compiler can patched to deal with it.
It should also make the kernel part much smaller and easier to make secure.
Re:I really like the idea (Score:5, Interesting)
It should also make the kernel part much smaller and easier to make secure.
You hope.
I've learned to become suspicious of change for change sake.
Long running well debugged code is almost always better understood than new code.
Re:I really like the idea (Score:5, Funny)
Indeed. I see several possible outcomes:
- This never reaches the quality level of iptables
- It becomes fast and stable enough to use, but nobody cares
- It replaces iptables in the distant future
Iptables is not broken. Do not fix it.
Re: (Score:2)
Compare the command syntax of an iptables rule to a PF rule, and get back to me. There's good reason OpenBSD is commonly used as a firewall, while Linux almost never is...
Re: (Score:2)
You do know that most commercial software firewalls are Linux-based, right? They do not advertise this, but Checkpoint, Juniper, ... all Linux iptables under the hood. The problem with OpenBSD is that hardware support sucks.
The second point is however, that the rule syntax is _not_ the reason for the replacement.
Re: (Score:2)
Your firewall doesn't need an SB Audigy sound card...
Re: (Score:2)
Actually, iptables is sub-optimal, that's the problem: http://lwn.net/Articles/531752/ [lwn.net]
Re:I really like the idea (Score:5, Insightful)
This is not an improvement. This is a replacement. Replacing things that are not broken is stupid.
Re: (Score:2)
Replacing things that are not broken is stupid.
I take it you don't live in a country where revolutions have taken place. A perfectly enforced law which no one dares break, may not be a bad idea to replace... Your argument is refuted. Protip: Try not to speak in absolutes, or you'll almost always be wrong.
Re: (Score:2)
Revolutions replace things that are so broken even the common folk can see it.
You are not very bright, are you?
Re: (Score:2)
Re: (Score:2)
My horse and buggy is not broken, why are you trying to replace it?
Yes, the alarm bells go off in my head as well when someone says "rewrite", does this person know WTF he's talking about? I know most battle tested code isn't all that pretty and that many people like to rewrite what they don't understand, don't follow their ideas of good code, aren't following their design patterns or isn't generic or flexible enough. Worst are those that take a look at a convoluted mess and decide it's too complex to under
Re: (Score:2)
Your horse and buggy _are_ broken for most applications in the modern world. Sure, they do their original job, but the job of transportation has changed. Iptables is not broken, it does the job it is supposed to do today just fine.
Re: (Score:2)
Re: (Score:2)
You misunderstand what "broken" means. Rather obviously it means "broken for its main application". Iptables is not broken for its main purpose. (No, this is not about "great", we are talking engineering here, not marketing.) That horse carriage is as it does not adequately fulfill the task of transporting goods and people today in most instances. The rest of your posting is just cheap polemics that try to distort what I wrote. Pathetic.
Re: (Score:2)
What's the point of rearchitecting it so that it can handle large rulesets efficiently if the whole thing will just be abstracted away in a VM anyway? What's next? a javascript interpreter in the kernel?
Re: (Score:2)
People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.
There is a difference between incremental upgrades and wholesale rewrites. Windows 7 (to take one example) isn't a new OS written from scratch, but an incremental improvement on NT, which dates back to 1993. Rewriting from scratch is almost always a bad idea [joelonsoftware.com].
Re: (Score:2)
People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.
Win 95 programs still run great on windows 7. I use a few of them regularly and the Linux ABI is fully backwards compatible. I expect not to see shit break.
Old code is great when changing it is going to inconvenience you personally, but replacing it with something newer is just fine and not a problem when it is only going to inconvenience someone who is not you.
Its called discipline. There is no technical reason existing shit must break to make progress. If you want to develop something new to replace something old just provide a compatibility layer for existing interface as Linux has always done.
Re: (Score:2)
moving packets in and out of kernelspace will kill performance.. Well, I guess we'll see, anyway. iptables is used for more than just someone's dsl gateway, and even there, the hardware in use for those is already on the lean side.
Re: (Score:2)
Will NFTables still allow packets to be selectively (eg certain TCP SYN packets) passed to a user-space filter which both mangles the packet and dynamically changes the NATting? With IP tables this was relatively simple (both defining the Iptables rules and writing the userspace filter)
Re: (Score:2)
The abstraction will still kill performance, or at least drop it significantly.
Re: (Score:2)
There might be spots where this is true, but in others it will improve performance, e.g. skipping unneeded operations that occur on all rules like incrmenting conters. Remember, iptables is actually somewhat of an abstraction itself.
I haven't been keeping up with how much intelligence vendors are putting in ethernet cards these days, but as far as I know, actually having firewall rules use on-card features has sadly lagged way behind what is offered. It would seem to me that, on the one hand, using a simp
drunken troubleshooting in 3 years (Score:5, Funny)
[root@wang]# ifconfig
bash: ifconfig: command not found
[root@wang]# iptables -F
bash: iptables: command not found
Re: (Score:2)
> [root@wang]# iptables -F
Suddenly your INPUT chain policy of DROP kills all traffic and your ssh session drops. (You do have a default policy of DROP, right?)
Seriously, don't do that on an unknown system.
(I post this because I've had vendors' support try to remedy problems by disabling the firewall. :/)
Re: (Score:3)
The problem with that is now you have no means of getting into your machine remotely over ip after the vendor fucks it up. Vendors shouldn't be disabling firewalls as permanent solutions, but while troubleshooting, it does make sense to do it temporarily in order to ensure the firewall is not at fault. If your system is a highly sensitive target, you should already have means in place to troubleshoot problems without exposing yourself. Tell the vendor the procedures for that.
done that, now explicitly drop all, default accept (Score:3)
I've done that to Very Important Client.
Now I explicitly have a drop everything rule, with default accept. That way -F doesn't bite me.
Re: (Score:2)
Suddenly your INPUT chain policy of DROP kills all traffic and your ssh session drops. (You do have a default policy of DROP, right?)
No, but it's the last rule in the table. That way, iptables -F doesn't kill ssh.
Re: (Score:2)
[root@wang]# ethereal
bash: ethereal: command not found
Re: (Score:2)
IPTABLES too complex and shouldn't be in kernel (Score:4, Insightful)
I've been using linux since 2000. Two comments...
1) IPCHAINS was nice, simple, and usable. IPTABLES has stuff scattered all over the place. This may affect me more as a Gentoo user who configures his own kernel. I have to remember to...
a) enable Netfilter
b) enable "Advanced netfilter configuration" so that I can specify multi-port matches
c) check off the necessary items in "Core Netfilter Configuration"
d) check off the necessary items in "IP: Netfilter Configuration"
That's on a simple home system that doesn't attempt NAT/Masq/Routing/etc.
2) A problem with putting detailed specifications into the kernel is that when I want to enable new features (not just new rules), I have to tweak the kernel, rebuild it, and reboot. If we had to do this with new MTAs or crons or other system programs, there would be a huge outcry. Moving this out of the kernel looks logical.
Re: (Score:2)
well you could build them as modules and load them dynamically. However, on my router, I just enable all the netfilter related stuff and build it into the kernel. A lot easier.
Useful with Van Jacobson's Net Channels? (Score:2)
Is NFTables suitable as a generic packet classifier, or is it strictly limited to packet filtering? Van Jacobson's net channels offer the possibility of extraordinary improvements in efficiency and performance, great simplification of drivers, ease of development, and much improved flexibility. The one missing piece is a flexible packet classifier. While NFTables looks like it incorporates many of the essential ideas, it isn't clear wether it is built with this in mind. If not, I'd like to see this fixe
Come on now... (Score:3)
Said one developer... (Score:3)
"Too many people had figured out how to configure a host firewall, so we had to change it all around again."
Re: (Score:2)
Re: (Score:2)
You are still free to do that. You could even write a userspace program to build a tree from a set of rules if you like.
Re: (Score:2)
We couldn't find any way around that.
For good reason. That's just reflecting the fact that a program has to check a series of instructions. The code can't check multiple conditions at the same time. Branching out into a series of tables for different things is the best way to reduce the unnecessary checks by filtering out those that do/don't apply. My first rule is always to allow RELATED/ESTABLISHED packets, so only the first packet of any new connection goes any further.
openwrt puts that related/established rule first and it sucks. If I want an internet curfew I want it to take effect immediately, not when the current connection is finished. Same for an IP address that trips up the malware triggers. It has to stop and it has to stop now, not when the payload has finished downloading.
Re: (Score:2)
Then use -I to 'insert' a rule above the ESTABLISHED,RELATED line.
Re: (Score:2)
Yeah, but that VM will eat cpu with high bw loads and complex rulesets.
Re: (Score:2)
hm ok. I haven't looked at the code or anything, just the summary on netfilter.org. It'll be interesting to benchmark both and see..
Re: (Score:2)
Every firewall GUI for Linux is underdeveloped or abandoned and lacks complete control over all functions.
Different use cases need different features. The abandoned guis were made by people who didn't understand this when they began their projects. The development taught them that lesson.
No one should be forced to manually configure this, it should be point and click similar to free firewalls for Windows (excluding discussion on app based blocking in Win).
one-click solutions to complex problems are always bad. That said, simplistic solutions are simple to configure with iptables the way it is.
I hope someone develops a GUI for "NFTables", because manually configuring iptables (using ufw, or its lack of complete control/fine tuning gui or some other method) sucks. Some assume you know all about Linux networking.
Well, if you're designing a complex solution for a complex networking problem, you will need to know a bit more about the guts of a system regardless the platform. A gui flexible enough
Re: (Score:2)
The tendency to try to abstract activities that are essentially programs into a set of non-program-like objects has generally led to accumulation of byzantine cruft. This is especially true in the network packet processing and authentication domains. This isn't just a problem with GUIs. CLI utilities often want to just present the user with "objects" like rules and lists, and try to conceal flow control concepts by nesting contextually meaningful layers of these objects -- the meaning sof these layers of
Re: (Score:2)
What I find is that when you encounter a series of iptable statements, it seems obvious that the kernel is building some sort of table of data or rules (LISP: data == program).
But instead of providing the table to the system, you have to build it up, piece by excruciating piece.
Whoever thought that was a good idea should have his packets limited.
Re: (Score:2)
I have tried several GUIs for iptables, and also a few firewall scripts for both a few servers and my notebook. In the end, I have always been frustrated.
Finally, for my rather simple needs, I have a simple (~ 100-150 lines) file in "iptables-save" format, and a short custom init script which basically does iptables-restore from that file or saves to it.
I am not convinced that a GUI would be clearer / more readable / more flexible than that. At least, the ones I tried were not.
One interesting feature in NFT
Re: (Score:2)
Of course once you start doing something repetitive it's hard to beat a script with a loop or even cut and paste instead of ticking hundreds of boxes.
Re: (Score:2)
OK, I'll bite.
What do you think deprecate means?
Re: (Score:2)
The act of deprecating something, duh.
Re: (Score:3, Funny)
JUST MAKE a DECENT FUCKING GUI with DOCUMENTATION.
I don't think fucking needs a new GUI. The current touch-based interface works just fine. Most people don't need any documentation for it, but if you really need it, I think there's a lot of third-party stuff explaining every fucking detail. There are even videos demonstrating its use, look under "porn".
Re: (Score:2)
I know the feeling.
That feeling means that it's time to retire from IT, and move to a less trend-driven industry. Such as, uh, fashion.