Fix a Firewall Blocking a Docker Container from Reaching the Host
A small engineering team hosts its Git repositories on a self-managed Gitea server. Gitea runs directly on the host, behind an Nginx reverse proxy. It listens on port 3000 on all addresses of the host, but the server's ufw firewall allows only ports :22 (SSH) and :80 (HTTP) from the network, so the team can reach Gitea only through the proxy.
The team is gradually moving its infrastructure to Docker. As a first step, they moved Nginx into a container, leaving Gitea on the host. The new proxy container uses the host's bridge address to reach Gitea on the host:
docker run -d --name proxy \
-p 80:80 \
--add-host host.docker.internal:host-gateway \
-v /srv/proxy/default.conf:/etc/nginx/conf.d/default.conf:ro \
nginx:alpine
Since the migration, the Gitea web interface has been returning 504 Gateway Timeout,
even though Gitea itself is running normally and answers on port 3000 when opened from the host.
Your task is to make Gitea load through the proxy again.
Gitea must stay unreachable for other machines on the network, and the firewall must stay enabled. Change the server and the proxy container as you see fit, but keep the container's name, its port 80 published, and its default bridge network.
Hint 1
The docker logs proxy command is a good starting point in digging why the proxy cannot get the page from Gitea.
Hint 2
A connection that is refused means nothing listens on the address and port. A connection that times out usually means that something drops the packets on their way.
Hint 3
From the host's perspective, a connection from a container to the host's bridge address is incoming traffic, like a connection from another machine on the office network.
It arrives through the docker0 interface, and the firewall checks it against the same rules.
Use the sudo ufw status verbose command to see the firewall's default policies and rules.
Hint 4
Opening port 3000 for everyone would fix the proxy, but it would also let other machines on the office network reach Gitea directly. The firewall rule must match something that the proxy's packets have and the packets from other machines don't.
Hint 5
The firewall records the packets that it drops in the kernel log.
Look for the [UFW BLOCK] lines with DPT=3000 in the sudo dmesg output.
Their IN= field shows the interface that a packet arrived on, and the SRC= field shows its source address.
Compare them with the interfaces of the server (ip -br addr) and the subnet of the bridge network.
Hint 6
A ufw rule can match either of them together with the port:
in on <interface> matches the interface, and from <subnet> matches the source addresses.
The man ufw page describes the full syntax.
If you match the source, use the exact subnet of the bridge network, because a wider range can also cover other networks.
