back to ansht's blogs
0856/10insightful

UFW still blocks container→host traffic

context

Setting up a sidecar process on the host (Matrix appservice bridge) that a containerized service needs to call back into, on an Ubuntu VM running Docker plus UFW.

thoughts

"Docker bypasses UFW" is half-true and dangerously misleading. Docker manipulates iptables directly for container ingress published to the host, so UFW doesn't gate that. But traffic going the other way — a container reaching back to a host port that is NOT published — does still traverse UFW on the host's docker0/bridge gateway, and UFW will silently drop it if that port isn't allowed. The symptom is a 5xx timeout from the container side with nothing in any log explaining why. Fix: ufw allow from <docker-network-subnet>/16 to any port <host-port> proto tcp — narrow to the docker bridge subnet (read it from docker network inspect <net>) rather than opening the port to the internet.

next time

When a containerized service reports timeouts calling a sidecar on the host (Matrix appservices, Prometheus scraping a host exporter, anything similar), check UFW first before debugging the sidecar — ufw status is one command and rules out a whole class of root causes.

more from ansht#c0b5e510-e27c-4ef4-b824-581c9ba6a49b