Should we be reverting iptables to iptables-legacy for eoan?

[Jamie Strandboge]

On Tue, 10 Sep 2019, Julian Andres Klode wrote:

> Hi folks,
> 
> it turns out that lxd is broken by iptables now using the nft
> based stuff, because lxd is still using the legacy one from
> inside the snap.
> 
> This provides a terrible experience because networking in lxd
> is not working at all once you enable ufw.

Is this because ufw uses whatever is on the system (ie, nft default) and
lxd is using whatever is in the snap (ie, historic iptables which with
iptables 1.8 translates to 'iptables-legacy') and this means that both
backends are in use, which results in a mixed view of things?

The man pages for iptables-nft/iptables-legacy don't call this out as a
problem, but README.Debian does:

  NOTE: make sure you don't mix iptables-legacy and iptables-nft
  rulesets in the same machine at the same time just for sanity and to
  avoid unexpected behaviours in your network.

> I'd suggest we increase the priority of iptables-legacy for eoan,
> so that it is the default, and move the switch to xtables-nft-based
> one to next release.
> 
> This will allow us to have working lxd networking, and gives
> the lxd team some breathing room.

This makes sense to me. Besides, there are still bugs trickling in where
the nft backend isn't acting fully compatibly anyway. However, it would
be nice to use the nft backend by default by 20.04, ie, at the opening
of the cycle.

That said, this is a very real immediate problem for snaps on 19.10+,
Buster+ and Ubuntu Core (CC'ing Samuele and Michael specifically) since
the only available bases are based on xenial and bionic and snaps can
only stage-packages from xenial and bionic, so snaps that plugs
'firewall-control' (or classic snaps) will by definition by far tend to
use 'legacy' (unless they build iptables from source). Even though the
system might have the nft backend enabled. Furthermore, the man page for
iptables-nft says that kernel >= 4.17 is required for the nft backend
(but ISTR issues in Debian with > 4.19) and its entirely possible
someone could be running a system with an older kernel with a newer user
space (eg, core20 snap with bionic kernel snap).

I'm not sure how to fix this. The only thing that seems reasonable is
for snaps to only be able to use the correct one that matches the
host/kernel. To pull that off snapd would need to examine the
capabilities and configuration of the running system then bind mount
iptables/etc from the host into runtime of the snap (the review-tools
could flag if snaps ship these binaries). Alternatively, an iptables
snapcraft part could be created that at runtime can interrogate whether
to use the nft or legacy backends (or snapd exposes which backend is in
use to the snap so it can decide).

I suspect that Michael and Samuele will want to move the snap-specific
parts of this discussion to the snapcraft forum, but +1 from me to
prefer 'legacy' for the time being in Ubuntu.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20190910/c36549fd/attachment.sig>