Docker Bridge Networks and Service Reachability

2026-01-04

An investigation into why Docker containers on custom bridge networks cannot reliably reach services bound to the bridge gateway IP, despite successful ping tests.

The Problem

Attempting to run pgAdmin in a Docker container to connect to a PostgreSQL database exposed via SSH reverse tunnel:

SSH tunnel binds to 172.19.0.1:5432 (bridge gateway)
From VPS host: nc -zv 172.19.0.1 5432 succeeds
From container: ping to 172.19.0.1 succeeds
From container: TCP connection to 172.19.0.1:5432 times out

Root Cause

Network namespace routing behavior, not Docker iptables blocking. Services bound to bridge gateway IPs from the host's perspective exist in the host network namespace. Container network namespaces have different routing tables that don't properly resolve the gateway as a service endpoint.

ICMP (ping) and TCP connection establishment follow different code paths in the kernel, which explains the "ping works but connection fails" behavior.

Solutions Attempted

host-gateway mapping: Docker's host.docker.internal resolves to 172.17.0.1 (default bridge), not custom network gateways
socat bridges: Failed due to same network namespace isolation—socat in container can't reach socat on host via gateway IP
Public IP exposure: Works but creates security concerns

Recommended Approach

Run services that need to reach SSH-tunneled endpoints directly on the host, not in containers. The network boundary between container and host namespaces makes gateway-bound services fundamentally problematic.

For pgAdmin specifically: install on VPS host, bind to localhost, reverse proxy with Traefik.

Read the full technical paper for detailed architecture diagrams showing the attempted solutions and routing analysis.