Arch Linux

(Also, the commit message says "Use names in filter priority in default config." but the actual change wasn't committed? I'm guessing nftables.conf was supposed to say 'priority filter' but it still has 'priority 0'.)

Thanks! Something goes wrong during my last file edition. Will push a fix asap.

I didn't look at too many others distro but from my Ubuntu hosts, the config and reload were already different. Our reload tried to be atomic by flushing the ruleset and include the config file in one run, while Ubuntu has both ExecReload= and ExecStart= doing the same thing and expect the config file to delete/flush itself the correct tables. Like upstream examples.
On the contrary, with this change, I think we are getting closer to Ubuntu, by having compatible configuration files, which requires the tables/ruleset to be removed before (re-)loading.

Our ExecReload= and ExecStop= (which is run by a restart) were flushing the whole rulset, breaking rules created by others services (e.g docker, sshguard, etc), or not defined in the config file, so keeping this bad behavior to be like others distro is a bad idea. nft doesn't manage unloading.

We might restore ExecReload to be exactly like ExecStart, but this looks to be redundant and equivalent to a restart, so I'm not enthusiast.

On the topic of improving the default /etc/nftables.conf, could you replace the comments with the "comment" statements so that they show up in `nft list ruleset` output. E.g.:

ct state invalid drop comment "early drop of invalid connections"
iifname lo accept comment "allow from loopback"

Done.

Thanks for the updates.

Does the 'pkttype host reject' do anything? AFAIK, just 'reject' will already do the right thing for multicast/broadcast packets (i.e. quietly drop them without generating ICMP), so this looks redundant.

> Our ExecReload= and ExecStop= (which is run by a restart) were flushing the whole rulset, breaking rules created by others services (e.g docker, sshguard, etc)

Yeah, that's a problem, also for named @sets which lose all their dynamically-added entries.

I agree that flushing rules on stop isn't very useful and can occassionally lead to security problems.

> We might restore ExecReload to be exactly like ExecStart, but this looks to be redundant and equivalent to a restart, so I'm not enthusiast.

It looks redundant only when viewed in isolation, but if it still serves a purpose then that's what makes it not redundant. I know that nftables is *technically* not a userspace service, but it wouldn't be the first time this was done to make a kernel .service behave like everything else (e.g. NFS or iptables).

Well, to be honest, I don't really have a strong complaint, as I've recently been using my own 'nfreload' script anyway -- which shows me a diff of old/new 'list ruleset' (especially useful with counters) to make sure the file was parsed correctly. I just wish all of this stuff was somewhat more standard between distros (and not end up like Debian's iptables-persistent)...

I added the pkttype rejection on my hosts few months ago to fix something related to multicast/broadcast packets. My git comments are not enough to remember why this was introduced and from my last test it looks also redundant. Maybe it was a placebo. So, I will drop it. Thanks.

A week I've been trying to remember and now that I've written and pushed a new version, I remember.

The pkttype filtering is used to let the rate limiting apply to packets which will really go on the network and are not silently dropped by the reject target.
When you are on a network with many dropped multicast or broadcast packets, the rate limit is reached without any icmp reject being sent.