---
title: "Docker Bridge Network (172.x.x.x) Bypasses LAN-Based App Whitelists"
aliases: [docker-bridge-whitelist, docker-172-network, docker-container-lan-whitelist, dashbrr-qbittorrent-whitelist]
tags: [docker, networking, whitelist, homelab, qbittorrent, media-stack]
sources:
  - "daily/2026-05-03.md"
created: 2026-05-03
updated: 2026-05-03
---

# 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

```bash
# 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`):
```ini
[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.

## Related Concepts

- [[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
