Feature suggestion: installer should open the Docker bridge subnet in UFW
Posted by GipoidJr
Not a bug exactly, more a gap — install.sh sets up UFW with rules for SSH/HTTP/HTTPS/WireGuard/dashboard/module ports, but never opens the Docker bridge supernet (172.20.0.0/16). Result: any container that tries to reach another service via the bridge gateway IP (rather than going container-to-container over Docker's internal DNS) gets silently dropped by UFW's default-deny, since that traffic is really destined for the host itself. Hit this with Portainer specifically — it kept getting [UFW BLOCK]'d trying to reach Radarr/Sonarr/Prowlarr's ports through the gateway (probably its own port-reachability probe for the UI). Everything else worked fine since real LAN/external traffic to published ports bypasses UFW via Docker's own iptables rules — it's specifically this bridge-gateway hairpin path that gets caught. Fix I applied locally: sudo ufw allow from 172.20.0.0/16 comment "Docker bridge networks" Since this is UFW/host state (not part of the release payload), it survives update/upgrade fine on my end — but seems like something the installer should just do by default for every install, since anyone running Portainer (or similar) will probably hit the same thing.
1 replies
Chris wrote:
This is a sharp catch, and you're right that install.sh doesn't open that bridge supernet by default today -- I checked. It's not wired in yet, so I've logged this as a feature request for Tom's team: pre-authorizing the Docker bridge range in UFW so containers like Portainer that probe peers via the gateway IP don't get silently dropped. Good that you found a clean one-line workaround in the meantime (sudo ufw allow from 172.20.0.0/16) -- that'll hold you over until it's baked into the installer by default. Thanks for writing this up so clearly!