Docker Bridge Network (172.x.x.x) Bypasses LAN-Based App Whitelists

When a Docker container communicates with another service, it uses the Docker bridge network IP (typically in the 172.16.0.0/12 range), not the host machine's LAN IP. If the target application has an IP whitelist that only covers the LAN subnet (e.g., 192.168.1.0/24), Docker containers cannot connect — even when running on the same physical host.

Key Points

Docker containers source traffic from 172.x.x.x when communicating via the Docker bridge — not from the host's LAN IP
LAN-only whitelists (192.168.1.0/24) don't cover Docker containers — containers are on a separate virtual network
Fix: Add 172.16.0.0/12 (or the specific Docker bridge subnet) to the target app's whitelist
Affected services: qBittorrent IP filter, any app with IP-based access control, Grafana auth proxy
This affects monitoring and management tools (Dashbrr, Beszel, Portainer) that connect to media stack applications

Details

The Problem

Dashbrr container (172.17.0.5) → qBittorrent (192.168.1.230:8080)
qBittorrent whitelist: 192.168.1.0/24
→ 172.17.0.5 is not in 192.168.1.0/24
→ qBittorrent returns 403 Forbidden

Dashbrr logs show repeated connection failures despite qBittorrent being accessible from the browser.

Docker Bridge IP Ranges

Docker uses RFC-1918 private ranges for bridge networks:

Network	Range	Docker usage
`172.16.0.0/12`	172.16.0.0 – 172.31.255.255	Default bridge driver range
`172.17.0.0/16`	First bridge network (`docker0`)	Default network
Custom networks	Configurable	`docker network create --subnet`

The full 172.16.0.0/12 range covers all default Docker bridge networks, making it the safe choice for whitelists.

Finding the Actual Docker Bridge IP

# Check what network a container uses
docker inspect <container_name> | grep -A 5 '"Networks"'

# Find the gateway (Docker bridge) IP
docker network inspect bridge | grep Gateway
# "Gateway": "172.17.0.1"

# Check container's IP
docker inspect dashbrr | grep IPAddress
# "IPAddress": "172.17.0.5"

Fix: Add Docker Bridge to qBittorrent Whitelist

qBittorrent → Settings → Web UI → IP filter (or Bypass authentication for clients on localhost):

Bypass authentication for clients on:
192.168.1.0/24    ← existing LAN
172.16.0.0/12     ← ADD: covers all Docker bridge networks
127.0.0.1         ← loopback

Or in qBittorrent's config file (qBittorrent.conf):

[Preferences]
WebUI\AuthSubnetWhitelistEnabled=true
WebUI\AuthSubnetWhitelist=192.168.1.0/24, 172.16.0.0/12

When This Applies

Any app with an IP-based access filter that is accessed from a Docker container:

qBittorrent (Dashbrr monitoring)
Prometheus scrape targets with firewall rules
Any service with allow from 192.168.1.0/24 style rules

Does NOT apply when containers are on network_mode: host — host networking bypasses the bridge and uses the physical LAN IP.

wiki/concepts/docker-lxc-dns-configuration — another Docker networking difference: containers inherit router DNS, not AdGuard
wiki/connections/docker-dns-adguard-split-horizon — related Docker networking isolation pattern
wiki/homelab/_index — homelab media stack context

Sources

daily/2026-05-03.md — Dashbrr couldn't connect to qBittorrent API; root cause: Dashbrr container on Docker bridge (172.x.x.x), qBit whitelist only had 192.168.1.0/24; fixed by adding 172.16.0.0/12 to qBit whitelist

3.9 KiB Raw Blame History Unescape Escape