So here is a hot take : You have just ended your migration to Debian Buster and were pretty chocked by some warnings about firewall deep changes ?
Well, you’re right.
There is plenty of documentation addressing this deprecation on the WWW, but what about a step-by-step guide summing up the whole idea behind this migration ?
Pretty easy for a first step, huh ?
Convert your existing legacy rules
(Re-)write your own rules
The step above is actually a “stupid” syntax converter from
nft, without a real extensive “processing” to optimize them.
So at this moment, you may wanna rewrite your existing rules.
I’d advise you the official guide, some of the below examples and some others packaged and already available right from your shell :
OMG, did that guy really used
nanoin its snippet ?
1) I don’t care very much about what people think ;
nanogot by default a syntax highlighting for
EDIT 2020-03-07 : I’ve (finally) written a syntax definition for Sublime Text 3+, it’s available here.
At this step, I assume you got some
nftables rules set under
/etc/nftables.conf (the default packaged location).
We will first be checking whether they actually pass the
nft validation procedure :
If that’s the case :
If you’re working on a remote server, at this step, I really hope that your SSH connection is still running
Post-configuration : The whole system
Well, you got brand new rules set and running, but there may be some cave-eats : Other pieces of software.
Typically, you are maybe running a quiet Fail2Ban instance, and on its side, it will be still using the legacy
Fixing this issue is pretty straightforward (if you got a
filter table with an
input chain already defined) :
You got the point : This was a friendly reminder for the other services, that will probably keep messing with
iptables behind your back…
EDIT 2020-03-25 : If you are a virtualization guy, please notice that libvirt does not support nftables yet. Docker is working well on Buster, but full nftables support is still expected.
Getting rid of legacy
(Optional) Make Buster “nickel-chrome”
When we upgrade from Stretch to Buster, the upgrade process might have tweaked a bit your setup to keep it backward compatible with potential existing
As we now use the default framework shipped in and advised by the Debian community, we may rollback to what a fresh Buster should look like :
Well, you’d have understood, the real idea behind this is to take some time to fully rewrite its own firewall using this “new” tool.
It might also be a good time to review existing rules, to decide whether they are still required or not, and maybe to optimize them with the awesome features brought by