ufw blocks communication between docker containers

Question

I have setup two docker containers for a Magento instance and a redis instance. For now, I only want to allow certain IP addresses to access the website, so I enabled ufw and added some entries. The problem is that the Magento instance cannot connect to the redis instance with ufw enabled. If I disable it, everything works. Here are my ufw entries:

--                         ------      ----
7722/tcp                   ALLOW       Anywhere
443/tcp                    ALLOW       <censored>
Anywhere                   ALLOW       172.17.0.0/16
Anywhere                   ALLOW       <censored>
Anywhere                   ALLOW       172.20.0.0/16
Anywhere                   ALLOW       127.0.0.1
6379                       ALLOW       172.20.0.0/16
3306                       ALLOW       172.20.0.0/16
6379                       ALLOW       127.0.0.1
6379                       ALLOW       172.17.0.0/16
6379                       ALLOW       <censored>
6379                       ALLOW       172.20.0.5
6379                       ALLOW       172.20.0.7
Anywhere                   ALLOW       172.20.0.5
Anywhere                   ALLOW       172.20.0.7
Anywhere                   ALLOW       <censored>
Anywhere                   ALLOW       127.0.0.0/8
Anywhere                   ALLOW       172.16.0.0/16
6379/tcp                   ALLOW       Anywhere
7722/tcp (v6)              ALLOW       Anywhere (v6)
6379/tcp (v6)              ALLOW       Anywhere (v6)

Anywhere                   ALLOW OUT   172.17.0.0/16 on docker0

Aug 1 20:35:52 <censored> kernel: [14792.173011] [UFW BLOCK] IN=br-d212b7b554b0 OUT=br-d212b7b554b0 PHYSIN=veth9ca196b PHYSOUT=vethbce3637 MAC=<censored>:14:00:05:08:00 SRC=172.20.0.5 DST=172.20.0.7 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=35267 DF PROTO=TCP SPT=45680 DPT=6379 WINDOW=64240 RES=0x00 SYN URGP=0

Any ideas?

Answer 1

Docker, in its code, loads br_netfilter and thus enables the sysctl net.bridge.bridge-nf-call-iptables = 1.

This makes bridged traffic, at layer 2, firewalled by iptables. While iptables handles only IPv4 packets, br_netfilter converts Ethernet frames of type IPv4 back and forth to packets so they can be filtered.

In below schematic, that's green boxes (IPv4 filtering) in the blue field (Ethernet bridging), instead of usual green field (IPv4 routing).

Preferably Docker should not be used with other networking tools on the same system because clash will happen.

Many side effects are described there: http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html

Among them: 7. Two possible ways for frames/packets to pass through the iptables PREROUTING, FORWARD and POSTROUTING chains.

To be compatible with Docker you should follow the advice: always enable traffic from a LAN to itself. So to address OP's log:

ufw route allow from 172.20.0.0/16 to 172.20.0.0/16

which should normally make no sense since routing (forwarding) is not involved, except... section 7, so it should be added. And the same should be added for every LAN managed by Docker, else UFW will interfere with what Docker put in place. Of course this is problematic because these networks are dynamic, and UFW will quickly become limited for this.

iptables has a special match for this: physdev (which does depend on br_netfilter) which could be used with (-A could possibly be replaced with -I and the right chain is yet to be chosen depending on the configuration of Docker and UFW):

iptables -A choosetherightchain -m physdev --physdev-is-bridged -j ACCEPT

but integration with UFW will start making UFW not be only UFW but a mix of low level direct iptables rules and UFW rules.

See also a Q/A with the same problem where I answered how to integrate this with nftables while trying to stay generic: nftables whitelisting docker