CentOS 8 firewalld + nftables or just nftables

Question

I've been on CentOS 7 for a long time and was used to building my custom iptables configurations on a variety of both personal and business boxes.

I've recently started working with CentOS 8 and learned of the move from iptables to nftables and so I was able to rewrite my rulesets and got everything up and running. The problem was that my custom nft rulesets were not persisting after a reboot, I had to manually systemctl restart nftables to get my rules back into force.

I learned that the culprit was firewalld, which from my understanding (because I never used it in CentOS 7), is a front end management tool for both iptables and nftables... correct? Once I systemctl disable firewalld and tried a reboot, my nftables rulesets were in place as expected. Problem solved.

My question is, what are the repercussions of not using firewalld, nftables is still running and active, so I'm assuming that my actual firewall is still in place, is there any reason why I should leave firewalld running and instead adjust a setting to ensure it's using my nftables ruleset instead. Any clarity on it's use would be greatly appreciated!

Solution

I think the answer is fairly straightforward. First, you have done exactly the right thing...

Firewalld is a pure frontend. It's not an independent firewall by itself. It only operates by taking instructions, then turning them into nftables rules (formerly iptables), and the nftables rules ARE the firewall. So you have a choice between running "firewalld using nftables" and running "nftables only". Nftables in turn works directly as part of the kernel, using a number of modules there, which are partly new, and partly repeat the "netfilter" system of kernel hooks and modules which became part of the kernel around 2000.

It gets quite confusing to run firewalld and nftables (formerly, iptables) in parallel, though I believe some people do so. If you were accustomed to run your own iptables rules anyway, it is the perfect solution to have converted them to nftables rules, and let them be the rules of your firewall. The best thing indeed is to completely disable and preferably mask firewalld - to be slightly pedantic, you can run:

sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask --now firewalld

There is nothing else you need to do. I myself run directly with nftables too. I find that much more transparent than using a front end (there are others than firewalld of course) - it gives you a complete understanding of what you are doing, and you can easily get a complete review of the effect of your rules by running sudo nft list ruleset > /etc/nftables.conf . And the use of separate nft tables in /etc/nftables.d is a nice and easy way of tracking what you have done, and where things are...

It was subsequently asked in comments by @eriknelson why you would mask a service at all. This is done, afaik, for practical reasons of user experience, and to protect against mistakes and hard-to-find bugs. It is highly undesirable to have more than one firewall system running, as the results for most people would be unpredictable, and it is unlikely that you get clear error messages from any firewall about its interaction with another firewall that is not expected to be there. The kernel however tries to process whatever it is given. If you use either nftables or iptables, you should not use firewalld. Or ufw. Or any other higher level system. And if you mainly use a higher-level firewall like firewalld, you don't like to mess around with the detailed low-level instructions (although occasionally it is done for a particular difficult situation that you find it too difficult to specify in the more high-level firewall).

When you mask a systemd service, you can neither start nor enable it straightaway. If you find / realise that the service is masked, you can unmask it - and then do what you want. This is set up to prevent any such changes made inadvertently or automatically. You can see for yourself if you have masked services on your computer by running sudo systemctl list-unit-files | grep mask

So this situation that you may not necessarily want to remove firewalld completely, but equally don't want to run it perhaps inadvertently, is precisely one of the cases where using sudo systemctl mask xyz.service can come in handy.

I suppose from what you write that you know all this. But I am a bit of an evangelist for nftables, and if others read this answer, they might be helped by these small hints. The documentation of nftables is good, but not excessive.

Comments

[oucil]

Thanks, that clears things up for me. I feel the same about working directly with nftables. I'm sure that the front end will be a help to get more people using their firewalls properly, but if I can work directly with the files and bootstrap them for repetition, direct is always the answer.

[eriknelson]

> completely disable and preferably mask firewalld Why is it preferable to not only disable, but mask firewalld? What does masking accomplish?

[henrystrick]

@eriknelson I expanded my original answer with a few paragraphs explaining why you would mask a systemd service.

[simon]

@henrystrick is it possible to configure the firewall by firewalld, and then disable it to save RAM on very low-RAM VM, so only nftables will be running? how this can be achieved?