Version: Docker 29.6.2, Docker Compose v5.3.1, ufw-docker (current master), Ubuntu 24.04 LTS.
The documented pattern for allowing traffic between containers on two different bridge networks — sudo ufw route allow proto tcp from <subnet-a> to <container-ip-on-network-b> port <port> — no longer has any effect starting with Docker's introduction of the DOCKER-FORWARD iptables chain (moby/moby#49518, landed as part of the Docker 27/28 iptables rework).
Reproduction:
Step 1: Two containers on separate bridge networks (A and B), both with pinned IPs.
Step 2: Add a ufw route allow proto tcp from <container-A-subnet> to <container-B-ip> port <port> rule (the standard ufw-docker cross-network pattern).
Step 3: Attempt the connection from container A to container B — it fails.
Step 4: sudo iptables -L -n -v shows 0 packet matches on the added rule, despite it being syntactically correct and appearing normal in ufw status.
Root cause: Docker now inserts a DOCKER-FORWARD chain that intercepts cross-bridge container traffic before ufw's own chains get a chance to evaluate it. The rule isn't wrong, it's just never reached.
Workaround we used: instead of routing between two isolated bridge networks, attach the container that needs access directly to the target network (docker network connect, or listing both networks in Compose) — same-network container-to-container traffic is handled by Docker's own icc setting and never touches ufw/iptables FORWARD at all, so it isn't affected by this.
This seems like a fairly fundamental change for a tool whose entire purpose is managing Docker's interaction with ufw's FORWARD chain — wanted to flag it in case others hit the same silent failure (rule looks correct, traffic just doesn't move, no error anywhere). Happy to help test if a DOCKER-FORWARD-aware fix is being considered, or to add a note to the README about the cross-bridge limitation if that's more appropriate than a code fix.
Version: Docker 29.6.2, Docker Compose v5.3.1, ufw-docker (current master), Ubuntu 24.04 LTS.
The documented pattern for allowing traffic between containers on two different bridge networks —
sudo ufw route allow proto tcp from <subnet-a> to <container-ip-on-network-b> port <port>— no longer has any effect starting with Docker's introduction of theDOCKER-FORWARDiptables chain (moby/moby#49518, landed as part of the Docker 27/28 iptables rework).Reproduction:
Step 1: Two containers on separate bridge networks (A and B), both with pinned IPs.
Step 2: Add a
ufw route allow proto tcp from <container-A-subnet> to <container-B-ip> port <port>rule (the standard ufw-docker cross-network pattern).Step 3: Attempt the connection from container A to container B — it fails.
Step 4:
sudo iptables -L -n -vshows 0 packet matches on the added rule, despite it being syntactically correct and appearing normal inufw status.Root cause: Docker now inserts a
DOCKER-FORWARDchain that intercepts cross-bridge container traffic before ufw's own chains get a chance to evaluate it. The rule isn't wrong, it's just never reached.Workaround we used: instead of routing between two isolated bridge networks, attach the container that needs access directly to the target network (
docker network connect, or listing both networks in Compose) — same-network container-to-container traffic is handled by Docker's owniccsetting and never touches ufw/iptables FORWARD at all, so it isn't affected by this.This seems like a fairly fundamental change for a tool whose entire purpose is managing Docker's interaction with ufw's FORWARD chain — wanted to flag it in case others hit the same silent failure (rule looks correct, traffic just doesn't move, no error anywhere). Happy to help test if a
DOCKER-FORWARD-aware fix is being considered, or to add a note to the README about the cross-bridge limitation if that's more appropriate than a code fix.