Problem
A Docker container couldn't reach Ollama on the host at 100.86.150.70:11434 — connections timed out. The host itself reached Ollama fine on every interface, and the container could reach other services (Qdrant on :6333) on the same IP. The lab's other containers had the same problem; it had been silently broken for a while.
Investigation
The confusing part: the container could reach Qdrant but not Ollama, on the same IP. I added ACCEPT rules to Docker's DOCKER-USER chain — no effect. Traced with tcpdump: the SYN appeared on the docker bridge but never left the host.
The key insight came from the routing table:
ip route get 100.86.150.70 from 172.19.0.2 iif br-fb8c2b17300b
local 100.86.150.70 ... dev lo table localThe destination is the host's own Tailscale IP, so the packet is routed as local — it goes to the INPUT chain, not FORWARD. All my FORWARD/DOCKER-USER rules were never evaluated. The INPUT chain (ufw, policy DROP) dropped the SYN because the docker bridge subnet isn't in the trusted-subnet allowlist.
Fix
Allow the docker subnets to reach Ollama through ufw (which manages the INPUT chain):
sudo ufw allow from 172.18.0.0/16 to 100.86.150.70 port 11434 proto tcp
sudo ufw allow from 172.19.0.0/16 to 100.86.150.70 port 11434 proto tcpVerification
curl http://100.86.150.70:11434/api/tagsfrom inside the container returned 200.- The lab's other containers (honcho-api, etc.) could now reach Ollama too.
Lesson
Container-to-host traffic to the host's own tunnel IP is treated as local delivery, not forwarding. When debugging container connectivity, check ip route get first — it tells you whether the packet will hit INPUT or FORWARD, which determines which firewall rules matter.