Drop iptables global rule to drop packets in the forward chain by default

[xnox]

docker is not the only daemon, it shouldn't drop everything on the floor by default.

[tianon]

is this related to moby/moby#45280? 👀

(I think this is something the Moby project is probably keen to improve/collaborate on, FWIW)

[zhsj]

Are you talking the same thing at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975 (docker.io changes iptables default FORWARD policy to DROP, breaks VM and others). You can read my summary at Message#91.

[xnox]

this is more to do with the fact that docker snap currently conflicts with microk8s & lxd. But the consequences of moby/moby#14041 are peculiar, thus I wonder what lxd does there.

[xnox]

@tomponline given moby/moby#14041 how does lxd avoid such exposure of containers, without the default drop rule?

[tomponline]

@tomponline given moby/moby#14041 how does lxd avoid such exposure of containers, without the default drop rule?

In short, it doesn't. However it will not enable IP forwarding until one or more managed bridge networks have been created by the user. So it doesn't happen it automatically when the service is started for the first time.

Additionally IP forwarding is not enabled when the bridge network has ipv{n}.address set to none or if ipv{n}.routing is set to false. So this is controllable by the user.

https://linuxcontainers.org/lxd/docs/master/reference/network_bridge/#configuration-options

I wrote more about this here: https://discuss.linuxcontainers.org/t/reasoning-behind-in-out-fwd-netfilter-rules/14444/5?u=tomp

In theory, if we were going to make it so that LXD managed bridges were not reachable from the LAN, but still supported egress SNAT (which requires forwarding be enabled) we wouldn't modify the global FORWARD policy to be DROP/REJECT (because of the disruption that would cause to other applications).

Instead I suspect we would add bridge interface specific DROP/REJECT rules so that LXD instances connected to LXD managed bridges were not reachable from the LAN, without affecting other interfaces. Although enabling IP forwarding would still potentially make other applications reachable from the LAN.