[systemd-devel] [HEADSUP] nspawn/networkd: moving from iptables to nftables

Lennart Poettering lennart at poettering.net
Fri May 29 08:49:12 PDT 2015


Heya,

just a small heads-up:

Currently there are two firewall APIs used on Linux: iptables and
nftables. iptables is the older one, nftables the new
replacement. systemd-nspawn and systemd-networkd currently interface
with iptables via the libiptc library: nspawn to implement the --port=
switch for opening up container ports on the host, and networkd to
implement IPMasquerade=.

Generally nftables is the future and iptables is supposed to be phased
out sooner or later. Your firewall should either use only iptables or
only nftables, but not both. Supporting only iptables in systemd is
hence a dead-end: we know already now, that it has no future and we
need to rework this sooner or later.

The hookup with iptables in nspawn+networkd is very recent only. After
discussing this many times internally we now are sure we should better
change from iptables to nftables quickly and do that fully and without
transition: the rules networkd adds are in a certain way API, since
your own iptables/nftables rules need to be ordered against them. And
when we establish a new API then we better should make sure to make it
a stable, future-proof one. THis will even become more important in
the future, should we add further firewalling support to systemd
components.

Hence: if you currently use networkd's IPMasquerade= or nspawn's
--port= support please be aware that the implementation of these
switches will change soonishly: and generate nftables rather than
iptables rules.

Yes, we are aware this is unfortunate, and that many people are still
using iptables. For this reason we would like to make the switch
quickly to ensure not too many users start using the iptables hook-up
before it goes away.

Note that this change should not matter to you if you use the switches
already, but do not have any other firewall configured. As the effect
of the switches should stay the same you shouldn't notice much.

Why not support both subsystems in parallel controllable via a runtime
or compile-time switch? The reason for this is that the rules
nspawn/networkd create *are* API, as mentioned and as such should be
the same on all systems, and not be completely different depending on
compile-time or runtime options...

I hope this makes sense?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list