[PATCH] tools: add a systemd unit for static rulesets

[PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

There is a customer request (bugreport) for wanting to trivially load a ruleset
from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
service unit is hereby added to provide that functionality. This is based on
various distributions attempting to do same, cf.

https://src.fedoraproject.org/rpms/nftables/tree/rawhide
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/nftables.initd
https://gitlab.archlinux.org/archlinux/packaging/packages/nftables

Cc: Matthias Gerstner <matthias.gerstner@suse.com>
---
 .gitignore                |  1 +
 Makefile.am               | 16 ++++++++++++----
 configure.ac              | 10 ++++++++++
 files/nftables/main.nft   | 24 ++++++++++++++++++++++++
 tools/nftables.service.8  | 18 ++++++++++++++++++
 tools/nftables.service.in | 21 +++++++++++++++++++++
 6 files changed, 86 insertions(+), 4 deletions(-)
 create mode 100644 files/nftables/main.nft
 create mode 100644 tools/nftables.service.8
 create mode 100644 tools/nftables.service.in

diff --git a/.gitignore b/.gitignore
index a62e31f3..f92187ef 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ autom4te.cache
 build-aux/
 libnftables.pc
 libtool
+tools/nftables.service
 
 # cscope files
 /cscope.*
diff --git a/Makefile.am b/Makefile.am
index fb64105d..050991f4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -375,18 +375,19 @@ dist_pkgdata_DATA = \
 	files/nftables/netdev-ingress.nft \
 	$(NULL)
 
-pkgdocdir = ${docdir}/examples
+exampledir = ${docdir}/examples
 
-dist_pkgdoc_SCRIPTS = \
+dist_example_SCRIPTS = \
 	files/examples/ct_helpers.nft \
 	files/examples/load_balancing.nft \
 	files/examples/secmark.nft \
 	files/examples/sets_and_maps.nft \
 	$(NULL)
 
-pkgsysconfdir = ${sysconfdir}/nftables/osf
+pkgsysconfdir = ${sysconfdir}/${PACKAGE}
+osfdir = ${pkgsysconfdir}/osf
 
-dist_pkgsysconf_DATA = \
+dist_osf_DATA = \
 	files/osf/pf.os \
 	$(NULL)
 
@@ -410,3 +411,10 @@ EXTRA_DIST += \
 
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = libnftables.pc
+unit_DATA = tools/nftables.service
+man_MANS = tools/nftables.service.8
+doc_DATA = files/nftables/main.nft
+
+tools/nftables.service: tools/nftables.service.in ${top_builddir}/config.status
+	${AM_V_GEN}${MKDIR_P} tools
+	${AM_V_at}sed -e 's|@''sbindir''@|${sbindir}|g;s|@''pkgsysconfdir''@|${pkgsysconfdir}|g' <${srcdir}/tools/nftables.service.in >$@
diff --git a/configure.ac b/configure.ac
index 80a64813..64a164e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,6 +114,16 @@ AC_CHECK_DECLS([getprotobyname_r, getprotobynumber_r, getservbyport_r], [], [],
 #include <netdb.h>
 ]])
 
+AC_ARG_WITH([unitdir],
+	[AS_HELP_STRING([--with-unitdir=PATH], [Path to systemd service unit directory])],
+	[unitdir="$withval"],
+	[
+		unitdir=$("$PKG_CONFIG" systemd --variable systemdsystemunitdir 2>/dev/null)
+		AS_IF([test -z "$unitdir"], [unitdir='${prefix}/lib/systemd/system'])
+	])
+AC_SUBST([unitdir])
+
+
 AC_CONFIG_FILES([					\
 		Makefile				\
 		libnftables.pc				\
diff --git a/files/nftables/main.nft b/files/nftables/main.nft
new file mode 100644
index 00000000..8e62f9bc
--- /dev/null
+++ b/files/nftables/main.nft
@@ -0,0 +1,24 @@
+#!/usr/sbin/nft -f
+
+# template static firewall configuration file
+#
+# copy this over to /etc/nftables/rules/main.nft as a starting point for
+# configuring a rule set which will be loaded by nftables.service.
+
+flush ruleset
+
+table inet filter {
+	chain input {
+		type filter hook input priority filter;
+	}
+	chain forward {
+		type filter hook forward priority filter;
+	}
+	chain output {
+		type filter hook output priority filter;
+	}
+}
+
+# this can be used to split the rule set into multiple smaller files concerned
+# with specific topics, like forwarding rules
+#include "/etc/nftables/rules/forwarding.nft"
diff --git a/tools/nftables.service.8 b/tools/nftables.service.8
new file mode 100644
index 00000000..4a83b01c
--- /dev/null
+++ b/tools/nftables.service.8
@@ -0,0 +1,18 @@
+.TH nftables.service 8 "" "nftables" "nftables admin reference"
+.SH Name
+nftables.service \(em Static Firewall Configuration with nftables.service
+.SH Description
+An nftables systemd service is provided which allows to setup static firewall
+rulesets based on a configuration file.
+.PP
+To use this service, you need to create the main configuration file in
+/etc/nftables/rules/main.nft. A template for this can be copied from
+/usr/share/doc/nftables/main.nft. The static firewall configuration can be
+split up into multiple files which are included from the main.nft
+configuration file.
+.PP
+Once the desired static firewall configuration is in place, it can be tested by
+running `systemctl start nftables.service`. To enable the service at boot time,
+run `systemctl enable nftables.service`.
+.SH See also
+\fBnft\fP(8)
diff --git a/tools/nftables.service.in b/tools/nftables.service.in
new file mode 100644
index 00000000..8d94e0fc
--- /dev/null
+++ b/tools/nftables.service.in
@@ -0,0 +1,21 @@
+[Unit]
+Description=nftables static rule set
+Documentation=nftables.service(8)
+Wants=network-pre.target
+Before=network-pre.target shutdown.target
+Conflicts=shutdown.target
+DefaultDependencies=no
+ConditionPathExists=@pkgsysconfdir@/rules/main.nft
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+StandardInput=null
+ProtectSystem=full
+ProtectHome=true
+ExecStart=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
+ExecReload=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
+ExecStop=@sbindir@/nft flush ruleset
+
+[Install]
+WantedBy=sysinit.target
-- 
2.48.1

Re: [PATCH] tools: add a systemd unit for static rulesets

[Pablo Neira Ayuso]

Hi Jan,

I added a few more people to Cc.

On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
> There is a customer request (bugreport) for wanting to trivially load a ruleset
> from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
> service unit is hereby added to provide that functionality. This is based on
> various distributions attempting to do same, cf.
> 
> https://src.fedoraproject.org/rpms/nftables/tree/rawhide
> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/nftables.initd
> https://gitlab.archlinux.org/archlinux/packaging/packages/nftables

Any chance to Cc these maintainers too? Given this is closer to
downstream than upstream, I would like to understand if this could
cause any hypothetical interference with distro packagers.

Only subtle nitpick I see with this patch is that INSTALL file is not
updated to provide information on how to use --with-unitdir=.

Thanks.

> Cc: Matthias Gerstner <matthias.gerstner@suse.com>
> ---
>  .gitignore                |  1 +
>  Makefile.am               | 16 ++++++++++++----
>  configure.ac              | 10 ++++++++++
>  files/nftables/main.nft   | 24 ++++++++++++++++++++++++
>  tools/nftables.service.8  | 18 ++++++++++++++++++
>  tools/nftables.service.in | 21 +++++++++++++++++++++
>  6 files changed, 86 insertions(+), 4 deletions(-)
>  create mode 100644 files/nftables/main.nft
>  create mode 100644 tools/nftables.service.8
>  create mode 100644 tools/nftables.service.in
> 
> diff --git a/.gitignore b/.gitignore
> index a62e31f3..f92187ef 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -14,6 +14,7 @@ autom4te.cache
>  build-aux/
>  libnftables.pc
>  libtool
> +tools/nftables.service
>  
>  # cscope files
>  /cscope.*
> diff --git a/Makefile.am b/Makefile.am
> index fb64105d..050991f4 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -375,18 +375,19 @@ dist_pkgdata_DATA = \
>  	files/nftables/netdev-ingress.nft \
>  	$(NULL)
>  
> -pkgdocdir = ${docdir}/examples
> +exampledir = ${docdir}/examples
>  
> -dist_pkgdoc_SCRIPTS = \
> +dist_example_SCRIPTS = \
>  	files/examples/ct_helpers.nft \
>  	files/examples/load_balancing.nft \
>  	files/examples/secmark.nft \
>  	files/examples/sets_and_maps.nft \
>  	$(NULL)
>  
> -pkgsysconfdir = ${sysconfdir}/nftables/osf
> +pkgsysconfdir = ${sysconfdir}/${PACKAGE}
> +osfdir = ${pkgsysconfdir}/osf
>  
> -dist_pkgsysconf_DATA = \
> +dist_osf_DATA = \
>  	files/osf/pf.os \
>  	$(NULL)
>  
> @@ -410,3 +411,10 @@ EXTRA_DIST += \
>  
>  pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = libnftables.pc
> +unit_DATA = tools/nftables.service
> +man_MANS = tools/nftables.service.8
> +doc_DATA = files/nftables/main.nft
> +
> +tools/nftables.service: tools/nftables.service.in ${top_builddir}/config.status
> +	${AM_V_GEN}${MKDIR_P} tools
> +	${AM_V_at}sed -e 's|@''sbindir''@|${sbindir}|g;s|@''pkgsysconfdir''@|${pkgsysconfdir}|g' <${srcdir}/tools/nftables.service.in >$@
> diff --git a/configure.ac b/configure.ac
> index 80a64813..64a164e5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -114,6 +114,16 @@ AC_CHECK_DECLS([getprotobyname_r, getprotobynumber_r, getservbyport_r], [], [],
>  #include <netdb.h>
>  ]])
>  
> +AC_ARG_WITH([unitdir],
> +	[AS_HELP_STRING([--with-unitdir=PATH], [Path to systemd service unit directory])],
> +	[unitdir="$withval"],
> +	[
> +		unitdir=$("$PKG_CONFIG" systemd --variable systemdsystemunitdir 2>/dev/null)
> +		AS_IF([test -z "$unitdir"], [unitdir='${prefix}/lib/systemd/system'])
> +	])
> +AC_SUBST([unitdir])
> +
> +
>  AC_CONFIG_FILES([					\
>  		Makefile				\
>  		libnftables.pc				\
> diff --git a/files/nftables/main.nft b/files/nftables/main.nft
> new file mode 100644
> index 00000000..8e62f9bc
> --- /dev/null
> +++ b/files/nftables/main.nft
> @@ -0,0 +1,24 @@
> +#!/usr/sbin/nft -f
> +
> +# template static firewall configuration file
> +#
> +# copy this over to /etc/nftables/rules/main.nft as a starting point for
> +# configuring a rule set which will be loaded by nftables.service.
> +
> +flush ruleset
> +
> +table inet filter {
> +	chain input {
> +		type filter hook input priority filter;
> +	}
> +	chain forward {
> +		type filter hook forward priority filter;
> +	}
> +	chain output {
> +		type filter hook output priority filter;
> +	}
> +}
> +
> +# this can be used to split the rule set into multiple smaller files concerned
> +# with specific topics, like forwarding rules
> +#include "/etc/nftables/rules/forwarding.nft"
> diff --git a/tools/nftables.service.8 b/tools/nftables.service.8
> new file mode 100644
> index 00000000..4a83b01c
> --- /dev/null
> +++ b/tools/nftables.service.8
> @@ -0,0 +1,18 @@
> +.TH nftables.service 8 "" "nftables" "nftables admin reference"
> +.SH Name
> +nftables.service \(em Static Firewall Configuration with nftables.service
> +.SH Description
> +An nftables systemd service is provided which allows to setup static firewall
> +rulesets based on a configuration file.
> +.PP
> +To use this service, you need to create the main configuration file in
> +/etc/nftables/rules/main.nft. A template for this can be copied from
> +/usr/share/doc/nftables/main.nft. The static firewall configuration can be
> +split up into multiple files which are included from the main.nft
> +configuration file.
> +.PP
> +Once the desired static firewall configuration is in place, it can be tested by
> +running `systemctl start nftables.service`. To enable the service at boot time,
> +run `systemctl enable nftables.service`.
> +.SH See also
> +\fBnft\fP(8)
> diff --git a/tools/nftables.service.in b/tools/nftables.service.in
> new file mode 100644
> index 00000000..8d94e0fc
> --- /dev/null
> +++ b/tools/nftables.service.in
> @@ -0,0 +1,21 @@
> +[Unit]
> +Description=nftables static rule set
> +Documentation=nftables.service(8)
> +Wants=network-pre.target
> +Before=network-pre.target shutdown.target
> +Conflicts=shutdown.target
> +DefaultDependencies=no
> +ConditionPathExists=@pkgsysconfdir@/rules/main.nft
> +
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +StandardInput=null
> +ProtectSystem=full
> +ProtectHome=true
> +ExecStart=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
> +ExecReload=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
> +ExecStop=@sbindir@/nft flush ruleset
> +
> +[Install]
> +WantedBy=sysinit.target
> -- 
> 2.48.1
> 

Re: [PATCH] tools: add a systemd unit for static rulesets

[Eric Garver]

On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
> There is a customer request (bugreport) for wanting to trivially load a ruleset
> from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
> service unit is hereby added to provide that functionality. This is based on
> various distributions attempting to do same, cf.
> 
> https://src.fedoraproject.org/rpms/nftables/tree/rawhide
> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/nftables.initd
> https://gitlab.archlinux.org/archlinux/packaging/packages/nftables
> 
> Cc: Matthias Gerstner <matthias.gerstner@suse.com>
> ---
>  .gitignore                |  1 +
>  Makefile.am               | 16 ++++++++++++----
>  configure.ac              | 10 ++++++++++
>  files/nftables/main.nft   | 24 ++++++++++++++++++++++++
>  tools/nftables.service.8  | 18 ++++++++++++++++++
>  tools/nftables.service.in | 21 +++++++++++++++++++++
>  6 files changed, 86 insertions(+), 4 deletions(-)
>  create mode 100644 files/nftables/main.nft
>  create mode 100644 tools/nftables.service.8
>  create mode 100644 tools/nftables.service.in
> 
> diff --git a/.gitignore b/.gitignore
> index a62e31f3..f92187ef 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -14,6 +14,7 @@ autom4te.cache
>  build-aux/
>  libnftables.pc
>  libtool
> +tools/nftables.service
>  
>  # cscope files
>  /cscope.*
> diff --git a/Makefile.am b/Makefile.am
> index fb64105d..050991f4 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -375,18 +375,19 @@ dist_pkgdata_DATA = \
>  	files/nftables/netdev-ingress.nft \
>  	$(NULL)
>  
> -pkgdocdir = ${docdir}/examples
> +exampledir = ${docdir}/examples
>  
> -dist_pkgdoc_SCRIPTS = \
> +dist_example_SCRIPTS = \
>  	files/examples/ct_helpers.nft \
>  	files/examples/load_balancing.nft \
>  	files/examples/secmark.nft \
>  	files/examples/sets_and_maps.nft \
>  	$(NULL)
>  
> -pkgsysconfdir = ${sysconfdir}/nftables/osf
> +pkgsysconfdir = ${sysconfdir}/${PACKAGE}
> +osfdir = ${pkgsysconfdir}/osf
>  
> -dist_pkgsysconf_DATA = \
> +dist_osf_DATA = \
>  	files/osf/pf.os \
>  	$(NULL)
>  
> @@ -410,3 +411,10 @@ EXTRA_DIST += \
>  
>  pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = libnftables.pc
> +unit_DATA = tools/nftables.service
> +man_MANS = tools/nftables.service.8
> +doc_DATA = files/nftables/main.nft
> +
> +tools/nftables.service: tools/nftables.service.in ${top_builddir}/config.status
> +	${AM_V_GEN}${MKDIR_P} tools
> +	${AM_V_at}sed -e 's|@''sbindir''@|${sbindir}|g;s|@''pkgsysconfdir''@|${pkgsysconfdir}|g' <${srcdir}/tools/nftables.service.in >$@
> diff --git a/configure.ac b/configure.ac
> index 80a64813..64a164e5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -114,6 +114,16 @@ AC_CHECK_DECLS([getprotobyname_r, getprotobynumber_r, getservbyport_r], [], [],
>  #include <netdb.h>
>  ]])
>  
> +AC_ARG_WITH([unitdir],
> +	[AS_HELP_STRING([--with-unitdir=PATH], [Path to systemd service unit directory])],
> +	[unitdir="$withval"],
> +	[
> +		unitdir=$("$PKG_CONFIG" systemd --variable systemdsystemunitdir 2>/dev/null)
> +		AS_IF([test -z "$unitdir"], [unitdir='${prefix}/lib/systemd/system'])
> +	])
> +AC_SUBST([unitdir])
> +
> +
>  AC_CONFIG_FILES([					\
>  		Makefile				\
>  		libnftables.pc				\
> diff --git a/files/nftables/main.nft b/files/nftables/main.nft
> new file mode 100644
> index 00000000..8e62f9bc
> --- /dev/null
> +++ b/files/nftables/main.nft
> @@ -0,0 +1,24 @@
> +#!/usr/sbin/nft -f
> +
> +# template static firewall configuration file
> +#
> +# copy this over to /etc/nftables/rules/main.nft as a starting point for
> +# configuring a rule set which will be loaded by nftables.service.
> +
> +flush ruleset
> +
> +table inet filter {
> +	chain input {
> +		type filter hook input priority filter;
> +	}
> +	chain forward {
> +		type filter hook forward priority filter;
> +	}
> +	chain output {
> +		type filter hook output priority filter;
> +	}
> +}
> +
> +# this can be used to split the rule set into multiple smaller files concerned
> +# with specific topics, like forwarding rules
> +#include "/etc/nftables/rules/forwarding.nft"
> diff --git a/tools/nftables.service.8 b/tools/nftables.service.8
> new file mode 100644
> index 00000000..4a83b01c
> --- /dev/null
> +++ b/tools/nftables.service.8
> @@ -0,0 +1,18 @@
> +.TH nftables.service 8 "" "nftables" "nftables admin reference"
> +.SH Name
> +nftables.service \(em Static Firewall Configuration with nftables.service
> +.SH Description
> +An nftables systemd service is provided which allows to setup static firewall
> +rulesets based on a configuration file.
> +.PP
> +To use this service, you need to create the main configuration file in
> +/etc/nftables/rules/main.nft. A template for this can be copied from
> +/usr/share/doc/nftables/main.nft. The static firewall configuration can be
> +split up into multiple files which are included from the main.nft
> +configuration file.

I think it's worth mentioning that a user could alternatively do:

  # nft list ruleset > /etc/nftables/rules/main.nft

to save the entire running ruleset. That's what I do. Mostly because I
want to make sure runtime accepts it before I make it permanent.

Perhaps this is not mentioned due to the `flush ruleset`. We could
suggest saving runtime to a file that's included from main.nft, thus
retaining the flush.

> +.PP
> +Once the desired static firewall configuration is in place, it can be tested by
> +running `systemctl start nftables.service`. To enable the service at boot time,
> +run `systemctl enable nftables.service`.
> +.SH See also
> +\fBnft\fP(8)
> diff --git a/tools/nftables.service.in b/tools/nftables.service.in
> new file mode 100644
> index 00000000..8d94e0fc
> --- /dev/null
> +++ b/tools/nftables.service.in
> @@ -0,0 +1,21 @@
> +[Unit]
> +Description=nftables static rule set
> +Documentation=nftables.service(8)
> +Wants=network-pre.target
> +Before=network-pre.target shutdown.target
> +Conflicts=shutdown.target
> +DefaultDependencies=no
> +ConditionPathExists=@pkgsysconfdir@/rules/main.nft
> +
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +StandardInput=null
> +ProtectSystem=full
> +ProtectHome=true
> +ExecStart=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
> +ExecReload=@sbindir@/nft -f @pkgsysconfdir@/rules/main.nft
> +ExecStop=@sbindir@/nft flush ruleset
> +
> +[Install]
> +WantedBy=sysinit.target

The service definition is pretty close to the RHEL one [1]. The major
difference is DefaultDependencies=no, i.e. early boot service. I think
setting this to 'no' is okay for nftables. I don't see any
incompatibilities with the RHEL version.

[1]: https://gitlab.com/redhat/centos-stream/rpms/nftables/-/blob/6e830a1e31e5984cec278fe33de2518e2000514b/nftables.service

Re: [PATCH] tools: add a systemd unit for static rulesets

[Phil Sutter]

Hi,

I'm comparing this with what we have in RHEL/Fedora:

On Thu, Mar 06, 2025 at 09:16:05AM -0500, Eric Garver wrote:
> On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
[...]
> > diff --git a/files/nftables/main.nft b/files/nftables/main.nft
> > new file mode 100644
> > index 00000000..8e62f9bc
> > --- /dev/null
> > +++ b/files/nftables/main.nft
> > @@ -0,0 +1,24 @@
> > +#!/usr/sbin/nft -f
> > +
> > +# template static firewall configuration file
> > +#
> > +# copy this over to /etc/nftables/rules/main.nft as a starting point for
> > +# configuring a rule set which will be loaded by nftables.service.
> > +
> > +flush ruleset

We do flush here as well, but in our case it's a bit redundant. (See
below.)

> > +
> > +table inet filter {
> > +	chain input {
> > +		type filter hook input priority filter;
> > +	}
> > +	chain forward {
> > +		type filter hook forward priority filter;
> > +	}
> > +	chain output {
> > +		type filter hook output priority filter;
> > +	}
> > +}
> > +
> > +# this can be used to split the rule set into multiple smaller files concerned
> > +# with specific topics, like forwarding rules
> > +#include "/etc/nftables/rules/forwarding.nft"
> > diff --git a/tools/nftables.service.8 b/tools/nftables.service.8
> > new file mode 100644
> > index 00000000..4a83b01c
> > --- /dev/null
> > +++ b/tools/nftables.service.8
> > @@ -0,0 +1,18 @@
> > +.TH nftables.service 8 "" "nftables" "nftables admin reference"
> > +.SH Name
> > +nftables.service \(em Static Firewall Configuration with nftables.service
> > +.SH Description
> > +An nftables systemd service is provided which allows to setup static firewall
> > +rulesets based on a configuration file.
> > +.PP
> > +To use this service, you need to create the main configuration file in
> > +/etc/nftables/rules/main.nft. A template for this can be copied from
> > +/usr/share/doc/nftables/main.nft. The static firewall configuration can be
> > +split up into multiple files which are included from the main.nft
> > +configuration file.
> 
> I think it's worth mentioning that a user could alternatively do:
> 
>   # nft list ruleset > /etc/nftables/rules/main.nft
> 
> to save the entire running ruleset. That's what I do. Mostly because I
> want to make sure runtime accepts it before I make it permanent.
> 
> Perhaps this is not mentioned due to the `flush ruleset`. We could
> suggest saving runtime to a file that's included from main.nft, thus
> retaining the flush.

In RHEL/Fedora, the unit script feeds /etc/sysconfig/nftables.conf into
nft. So this is the "top level" config which by default contains:

| # Uncomment the include statement here to load the default config sample
| # in /etc/nftables for nftables service.
| 
| #include "/etc/nftables/main.nft"
| 
| # To customize, either edit the samples in /etc/nftables, append further
| # commands to the end of this file or overwrite it after first service
| # start by calling: 'nft list ruleset >/etc/sysconfig/nftables.conf'.

The last paragraph is crucial: We want to allow users to either:

- Customize the sample config provided by the distribution (more on that later)
- Extend it by extra ruleset snippets (similar to a /etc/vim/vimrc.local)
- Override the whole thing without much hassle

To support the latter, our unit script does:

| ExecReload=/sbin/nft 'flush ruleset; include "/etc/sysconfig/nftables.conf";'

This way nftables.conf may contain just the output of 'nft list
ruleset', no initial 'flush ruleset' is needed.

The sample configs are not just empty chains as proposed here but
actually contain rules which should not just help users get going but
also showcase nftables features a bit. Also there is mitigation of the
Port Shadow attack (CVE-2021-3773) in the sample nat.nft file:

https://src.fedoraproject.org/rpms/nftables/blob/rawhide/f/main.nft
https://src.fedoraproject.org/rpms/nftables/blob/rawhide/f/router.nft
https://src.fedoraproject.org/rpms/nftables/blob/rawhide/f/nat.nft

IMO we should at least include the builtin 'flush ruleset' in ExecReload
action. What are your opinions about Fedora's sample configs? The
content should be fine for generic purposes, merely
/etc/sysconfig/nftables.conf location should be changed, maybe to
/etc/nftables/nftables.conf.

Cheers, Phil

Re: [PATCH] tools: add a systemd unit for static rulesets

[Arturo Borrero Gonzalez]

On 3/5/25 22:35, Pablo Neira Ayuso wrote:
> Hi Jan,
> 
> I added a few more people to Cc.
> 
> On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
>> There is a customer request (bugreport) for wanting to trivially load a ruleset
>> from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
>> service unit is hereby added to provide that functionality. This is based on
>> various distributions attempting to do same, cf.
>>
>> https://src.fedoraproject.org/rpms/nftables/tree/rawhide
>> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/ 
>> nftables.initd
>> https://gitlab.archlinux.org/archlinux/packaging/packages/nftables
> Any chance to Cc these maintainers too? Given this is closer to
> downstream than upstream, I would like to understand if this could
> cause any hypothetical interference with distro packagers.
> 
> Only subtle nitpick I see with this patch is that INSTALL file is not
> updated to provide information on how to use --with-unitdir=.
> 

I have mixed feelings about having this systemd service file in this repository.
Will this file be maintained wrt. systemd ecosystem updates? Or will it be 
outdated and neglected after a few years?

For most folks, I assume they will run nftables via firewalld or any other 
ruleset manager, unless they know what they are doing. And if they know what 
they are doing (i.e, they have crafted their own firewalling system), then most 
likely the systemd config in this repo is ignored.

Re: [PATCH] tools: add a systemd unit for static rulesets

[Duncan Roe]

On Fri, Mar 21, 2025 at 02:29:46PM +0100, Arturo Borrero Gonzalez wrote:
>
> On 3/5/25 22:35, Pablo Neira Ayuso wrote:
> > Hi Jan,
> >
> > I added a few more people to Cc.
> >
> > On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
> > > There is a customer request (bugreport) for wanting to trivially load a ruleset
> > > from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
> > > service unit is hereby added to provide that functionality. This is based on
> > > various distributions attempting to do same, cf.
> > >
> > > https://src.fedoraproject.org/rpms/nftables/tree/rawhide
> > > https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/
> > > nftables.initd
> > > https://gitlab.archlinux.org/archlinux/packaging/packages/nftables
> > Any chance to Cc these maintainers too? Given this is closer to
> > downstream than upstream, I would like to understand if this could
> > cause any hypothetical interference with distro packagers.
> >
> > Only subtle nitpick I see with this patch is that INSTALL file is not
> > updated to provide information on how to use --with-unitdir=.
> >
>
> I have mixed feelings about having this systemd service file in this repository.
> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
> outdated and neglected after a few years?
>
> For most folks, I assume they will run nftables via firewalld or any other
> ruleset manager, unless they know what they are doing. And if they know what
> they are doing (i.e, they have crafted their own firewalling system), then
> most likely the systemd config in this repo is ignored.
>
>
http://www.slackware.com/ doesn't use systemd

Re: [PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

On Saturday 2025-03-22 02:49, Duncan Roe wrote:
>>
>> I have mixed feelings about having this systemd service file in this repository.
>> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
>> outdated and neglected after a few years?

There are no changes expected to be necessary.

>> For most folks, I assume they will run nftables via firewalld or any other
>> ruleset manager, unless they know what they are doing. And if they know what
>> they are doing (i.e, they have crafted their own firewalling system), then
>> most likely the systemd config in this repo is ignored.

This is just a launcher, not the ruleset itself.
And with /etc/init.d/boot.local practically gone on modern systems,
it's not as simple anymore to just slap nft -f.. in boot.local.

Re: [PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

On Thursday 2025-03-06 15:16, Eric Garver wrote:
>
>to save the entire running ruleset. That's what I do. Mostly because I
>want to make sure runtime accepts it before I make it permanent.
>
>Perhaps this is not mentioned due to the `flush ruleset`. We could
>suggest saving runtime to a file that's included from main.nft, thus
>retaining the flush.

I'll add it.

>> +[Install]
>> +WantedBy=sysinit.target
>
>The service definition is pretty close to the RHEL one [1]. The major
>difference is DefaultDependencies=no, i.e. early boot service. I think
>setting this to 'no' is okay for nftables. I don't see any
>incompatibilities with the RHEL version.

The patch already contains DefaultDependencies=no.
https://lore.kernel.org/netfilter-devel/Z9wgoHjQhARxPtqm@orbyte.nwl.cc/T/#m8f856650f1553a3b6a0ed17af37ce1ad5acb3227

Re: [PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

On Thursday 2025-03-20 15:05, Phil Sutter wrote:

>IMO we should at least include the builtin 'flush ruleset' in ExecReload
>action.

Yes

>The sample configs are not just empty chains as proposed here but
>actually contain rules which should not just help users get going but
>also showcase nftables features a bit.
>
>What are your opinions about Fedora's sample configs?

That's all considered "documentation".

>The content should be fine for generic purposes, merely
>/etc/sysconfig/nftables.conf location should be changed, maybe to
>/etc/nftables/nftables.conf.

We're not using /etc/sysconfig (it's deprecated or so).

Re: [PATCH] tools: add a systemd unit for static rulesets

[Arturo Borrero Gonzalez]

On 3/22/25 10:24, Jan Engelhardt wrote:
> 
> On Saturday 2025-03-22 02:49, Duncan Roe wrote:
>>>
>>> I have mixed feelings about having this systemd service file in this repository.
>>> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
>>> outdated and neglected after a few years?
> 
> There are no changes expected to be necessary.
> 

How so?

Is the systemd ecosystem not evolving? Won't systemd see any updates? Will it 
not deprecate options, or introduce new ones, thus making the systemd service 
file outdated?

I don't think 'no changes expected to be necessary' is a statement that can be 
applied to any software system.

Re: [PATCH] tools: add a systemd unit for static rulesets

[Pablo Neira Ayuso]

On Fri, Mar 21, 2025 at 02:29:46PM +0100, Arturo Borrero Gonzalez wrote:
> 
> On 3/5/25 22:35, Pablo Neira Ayuso wrote:
> > Hi Jan,
> > 
> > I added a few more people to Cc.
> > 
> > On Fri, Feb 28, 2025 at 09:59:35PM +0100, Jan Engelhardt wrote:
> > > There is a customer request (bugreport) for wanting to trivially load a ruleset
> > > from a well-known location on boot, forwarded to me by M. Gerstner. A systemd
> > > service unit is hereby added to provide that functionality. This is based on
> > > various distributions attempting to do same, cf.
> > > 
> > > https://src.fedoraproject.org/rpms/nftables/tree/rawhide
> > > https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nftables/
> > > nftables.initd
> > > https://gitlab.archlinux.org/archlinux/packaging/packages/nftables
> > Any chance to Cc these maintainers too? Given this is closer to
> > downstream than upstream, I would like to understand if this could
> > cause any hypothetical interference with distro packagers.
> > 
> > Only subtle nitpick I see with this patch is that INSTALL file is not
> > updated to provide information on how to use --with-unitdir=.
> > 
> 
> I have mixed feelings about having this systemd service file in this repository.
> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
> outdated and neglected after a few years?

From your words, I guess you don't find this useful for the Debian
case?

I understand your concerns of having a file in the tree that gets no
attention, for me, it is one less file to maintain TBH.

But maybe common ground on this helps reinvent the wheel if there is
consensus on this.

Having said this, I am a not so close downstream packager
requirements.

Re: [PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

On Sunday 2025-03-23 11:00, Arturo Borrero Gonzalez wrote:
>> On Saturday 2025-03-22 02:49, Duncan Roe wrote:
>>>>
>>>> I have mixed feelings about having this systemd service file in this
>>>> repository.
>>>> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
>>>> outdated and neglected after a few years?
>> 
>> There are no changes expected to be necessary.
>
> How so? Is the systemd ecosystem not evolving?

I do not have a crystal ball that shows me what will (or will not)
happen in the future, so as far as I can tell, it is perfect as it is.
And I have no indication that unit files are planned to be ditched
anytime soon.

Re: [PATCH] tools: add a systemd unit for static rulesets

[Phil Sutter]

On Sun, Mar 23, 2025 at 02:34:01PM +0100, Jan Engelhardt wrote:
> 
> On Sunday 2025-03-23 11:00, Arturo Borrero Gonzalez wrote:
> >> On Saturday 2025-03-22 02:49, Duncan Roe wrote:
> >>>>
> >>>> I have mixed feelings about having this systemd service file in this
> >>>> repository.
> >>>> Will this file be maintained wrt. systemd ecosystem updates? Or will it be
> >>>> outdated and neglected after a few years?
> >> 
> >> There are no changes expected to be necessary.
> >
> > How so? Is the systemd ecosystem not evolving?
> 
> I do not have a crystal ball that shows me what will (or will not)
> happen in the future, so as far as I can tell, it is perfect as it is.
> And I have no indication that unit files are planned to be ditched
> anytime soon.

Even if things will change and this thing gets outdated, who cares? The
bottom line is what we do currently, namely maintain nftables.service
ourselves downstream.

Apart from having to deal with heated debates over its content on the ML
there is no real burden for upstream to maintain it, either.

To me, this is an opportunity to share knowledge (e.g. others performing
a needed unit file update before I find time reading up on systemd's
latest "invention") and it may even encourage downstream maintainers in
collecting/discussing sample config best practices.

Cheers, Phil

Re: [PATCH] tools: add a systemd unit for static rulesets

[Dan Winship]

On 3/20/25 10:05, Phil Sutter wrote:
> IMO we should at least include the builtin 'flush ruleset'

Boooo!

In kubernetes, kube-proxy's iptables mode polls the iptables rules once
every 30 seconds to make sure that the admin didn't do "systemctl
restart iptables" or "firewall-cmd --restart" and COMPLETELY BREAK
KUBERNETES[1]. The kube-proxy nftables mode *doesn't* currently do this,
because it assumes nobody would be so rude as to flush the entire nft
ruleset rather than only deleting and recreating their own table...[2]

(If the nftables "owner" flag thwarts "flush ruleset", then that's
definitely *better*, though that flag is still too new to help very much.)

Once upon a time, it was reasonable for the system firewall scripts to
assume that they were the only users of netfilter on the system, but
that is not the world we live in any more. Sure, *most* Linux users
aren't running Kubernetes, but many people run hypervisors, or
docker/podman, or other things that create a handful of dynamic
iptables/nftables rules, and then expect those rules to not suddenly
disappear for no apparent reason later.

If you're going to have a static nftables ruleset thing, please restrict
it to a single table, and never ever ever do "flush ruleset".

-- Dan

[1]
https://github.com/kubernetes/kubernetes/blob/v1.31.7/pkg/util/iptables/iptables.go#L80-L90
[2]
https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/3866-nftables-proxy/README.md?plain=1#L1274-L1296

Re: [PATCH] tools: add a systemd unit for static rulesets

[Phil Sutter]

On Mon, Mar 24, 2025 at 09:34:26PM -0400, Dan Winship wrote:
> On 3/20/25 10:05, Phil Sutter wrote:
> > IMO we should at least include the builtin 'flush ruleset'
> 
> Boooo!

Hi Dan!

> In kubernetes, kube-proxy's iptables mode polls the iptables rules once
> every 30 seconds to make sure that the admin didn't do "systemctl
> restart iptables" or "firewall-cmd --restart" and COMPLETELY BREAK
> KUBERNETES[1]. The kube-proxy nftables mode *doesn't* currently do this,
> because it assumes nobody would be so rude as to flush the entire nft
> ruleset rather than only deleting and recreating their own table...[2]

The suggested 'flush ruleset' stems from Fedora's nftables.service and
is also present in CentOS Stream and RHEL. So anyone running k8s there
either doesn't use nftables.service (likely, firewalld is default) or
doesn't restart the service. Maybe k8s should "officially" conflict with
nftables and iptables services?

> (If the nftables "owner" flag thwarts "flush ruleset", then that's
> definitely *better*, though that flag is still too new to help very much.)

Yes, "owned" tables may only be manipulated by their owner. Firewalld
will use it as well, for the same reason as k8s.

> Once upon a time, it was reasonable for the system firewall scripts to
> assume that they were the only users of netfilter on the system, but
> that is not the world we live in any more. Sure, *most* Linux users
> aren't running Kubernetes, but many people run hypervisors, or
> docker/podman, or other things that create a handful of dynamic
> iptables/nftables rules, and then expect those rules to not suddenly
> disappear for no apparent reason later.

The question is whether the nftables and iptables services are meant for
the world we live in now. At least with iptables, it is very hard not to
stomp on others' feet when restarting. With nftables, we could cache the
'add table' commands for use later when stopping the service. There is
margin for error though since the added table may well exist already.

> If you're going to have a static nftables ruleset thing, please restrict
> it to a single table, and never ever ever do "flush ruleset".

Cheers, Phil

Re: [PATCH] tools: add a systemd unit for static rulesets

[Jan Engelhardt]

On Wednesday 2025-03-26 16:56, Phil Sutter wrote:
>
>The suggested 'flush ruleset' stems from Fedora's nftables.service and
>is also present in CentOS Stream and RHEL. So anyone running k8s there
>either doesn't use nftables.service (likely, firewalld is default) or
>doesn't restart the service. Maybe k8s should "officially" conflict with
>nftables and iptables services?

It definitely should.

For example, in openSUSE we already added an extra constraint between
firewalld <-> nftables, so k8s should likely get a similar treatment.

fail2ban is also interesting, but a solved problem
(equally added ordering constraints to the distro years ago).

Re: [PATCH] tools: add a systemd unit for static rulesets

[Dan Winship]

On 3/26/25 11:56, Phil Sutter wrote:
> The suggested 'flush ruleset' stems from Fedora's nftables.service and
> is also present in CentOS Stream and RHEL. So anyone running k8s there
> either doesn't use nftables.service (likely, firewalld is default) or
> doesn't restart the service. Maybe k8s should "officially" conflict with
> nftables and iptables services?

(It's weird that nftables.service is part of the nftables package, when
with iptables it was in a separate package, iptables-services? But
that's not a discussion for this mailing list...)

>> (If the nftables "owner" flag thwarts "flush ruleset", then that's
>> definitely *better*, though that flag is still too new to help very much.)
> 
> Yes, "owned" tables may only be manipulated by their owner. Firewalld
> will use it as well, for the same reason as k8s.

So in the long run, this solves my problem, even if static firewalls are
using "flush ruleset".

>> Once upon a time, it was reasonable for the system firewall scripts to
>> assume that they were the only users of netfilter on the system, but
>> that is not the world we live in any more. Sure, *most* Linux users
>> aren't running Kubernetes, but many people run hypervisors, or
>> docker/podman, or other things that create a handful of dynamic
>> iptables/nftables rules, and then expect those rules to not suddenly
>> disappear for no apparent reason later.
> 
> The question is whether the nftables and iptables services are meant for
> the world we live in now.

If they're not, then distros shouldn't install them by default. Having
them installed on the system (or provided as an example in the nftables
sources) suggests to admins that it's reasonable to use them. (And
having nftables.service use "flush ruleset" suggests to admins that
that's a reasonable command for them to run when they are building their
own things based on our examples.)

> At least with iptables, it is very hard not to
> stomp on others' feet when restarting.

Sure, there's nothing that can be done to improve the situation with
iptables. It just doesn't have the features needed to support multiple
users well. But nftables does. That's the whole point of multiple tables
isn't it?

> With nftables, we could cache the
> 'add table' commands for use later when stopping the service. There is
> margin for error though since the added table may well exist already.

I was thinking more like, the service documents that all of your rules
have to be in the table 'firewall', and while it may not actually
*prevent* you from setting up rules in other tables, it doesn't make any
effort to make that work either:

ExecStart=/sbin/nft 'destroy table firewall; add table firewall; include
"/etc/sysconfig/nftables.conf";'
ExecReload=/sbin/nft 'destroy table firewall; add table firewall;
include "/etc/sysconfig/nftables.conf";'
ExecStop=/sbin/nft destroy table firewall

-- Dan

Re: [PATCH] tools: add a systemd unit for static rulesets

[Phil Sutter]

On Thu, Mar 27, 2025 at 07:12:29AM -0400, Dan Winship wrote:
> On 3/26/25 11:56, Phil Sutter wrote:
> > The suggested 'flush ruleset' stems from Fedora's nftables.service and
> > is also present in CentOS Stream and RHEL. So anyone running k8s there
> > either doesn't use nftables.service (likely, firewalld is default) or
> > doesn't restart the service. Maybe k8s should "officially" conflict with
> > nftables and iptables services?
> 
> (It's weird that nftables.service is part of the nftables package, when
> with iptables it was in a separate package, iptables-services? But
> that's not a discussion for this mailing list...)
> 
> >> (If the nftables "owner" flag thwarts "flush ruleset", then that's
> >> definitely *better*, though that flag is still too new to help very much.)
> > 
> > Yes, "owned" tables may only be manipulated by their owner. Firewalld
> > will use it as well, for the same reason as k8s.
> 
> So in the long run, this solves my problem, even if static firewalls are
> using "flush ruleset".
> 
> >> Once upon a time, it was reasonable for the system firewall scripts to
> >> assume that they were the only users of netfilter on the system, but
> >> that is not the world we live in any more. Sure, *most* Linux users
> >> aren't running Kubernetes, but many people run hypervisors, or
> >> docker/podman, or other things that create a handful of dynamic
> >> iptables/nftables rules, and then expect those rules to not suddenly
> >> disappear for no apparent reason later.
> > 
> > The question is whether the nftables and iptables services are meant for
> > the world we live in now.
> 
> If they're not, then distros shouldn't install them by default. Having
> them installed on the system (or provided as an example in the nftables
> sources) suggests to admins that it's reasonable to use them. (And
> having nftables.service use "flush ruleset" suggests to admins that
> that's a reasonable command for them to run when they are building their
> own things based on our examples.)

We're drifting into downstream details here, but I agree that we should
have nftables-service(s) RPM which is not installed by default.

> > At least with iptables, it is very hard not to
> > stomp on others' feet when restarting.
> 
> Sure, there's nothing that can be done to improve the situation with
> iptables. It just doesn't have the features needed to support multiple
> users well. But nftables does. That's the whole point of multiple tables
> isn't it?

Probably, yes. Tables only separate name spaces, though. The actual
merge points are the netfilter hooks and tables don't matter there. The
problem of rule ordering in a builtin iptables chain has become a
problem of base chain ordering in a hook. Eventually rules are
serialized and since one can't undo an earlier drop/reject, there's
still room for conflicts. Real concurrent use therefore requires a
mediating agent like firewalld and a more abstract language than "accept
this, drop that".

> > With nftables, we could cache the
> > 'add table' commands for use later when stopping the service. There is
> > margin for error though since the added table may well exist already.
> 
> I was thinking more like, the service documents that all of your rules
> have to be in the table 'firewall', and while it may not actually
> *prevent* you from setting up rules in other tables, it doesn't make any
> effort to make that work either:
> 
> ExecStart=/sbin/nft 'destroy table firewall; add table firewall; include
> "/etc/sysconfig/nftables.conf";'
> ExecReload=/sbin/nft 'destroy table firewall; add table firewall;
> include "/etc/sysconfig/nftables.conf";'
> ExecStop=/sbin/nft destroy table firewall

Since tables are bound to an IP version (or "inet"), a single table may
or may not suffice for users. Apart from that, one may even do:

| ExecStart=nft 'add table firewall { include "/etc/sysconfig/nftables.conf"; }'

One can't dump the current ruleset into that file anymore, though.

Anyway, I think we're playing hide'n'seek here: Even if nftables service
sticks to a given (set of) table(s), base chains may easily break k8s.
Marking the two as conflicting with systemd is a better choice IMO.

Cheers, Phil

Re: [PATCH] tools: add a systemd unit for static rulesets

[Pablo Neira Ayuso]

Hi Jan,

On Wed, Mar 26, 2025 at 11:21:09PM +0100, Jan Engelhardt wrote:
> 
> On Wednesday 2025-03-26 16:56, Phil Sutter wrote:
> >
> >The suggested 'flush ruleset' stems from Fedora's nftables.service and
> >is also present in CentOS Stream and RHEL. So anyone running k8s there
> >either doesn't use nftables.service (likely, firewalld is default) or
> >doesn't restart the service. Maybe k8s should "officially" conflict with
> >nftables and iptables services?
> 
> It definitely should.
> 
> For example, in openSUSE we already added an extra constraint between
> firewalld <-> nftables, so k8s should likely get a similar treatment.
> 
> fail2ban is also interesting, but a solved problem
> (equally added ordering constraints to the distro years ago).

I think this still needs one more iteration based on the feedback,
Phil mentioned one issue with flush ruleset that I can remember.

Thanks.