·10 min read

Container Networking Deep Dive: Connecting Docker and Podman Containers

Understand container networking fundamentals: bridge networks, host networking, port mapping, and inter-container communication in Docker and Podman.

DockerPodmanNetworkingContainersDevOps

Containers don't exist in isolation. They need to talk to each other, reach external services, and accept incoming connections. Understanding container networking is essential for building multi-service applications.

This guide covers networking concepts that apply to both Docker and Podman, with practical examples you can test immediately.

Network Drivers Overview

Both Docker and Podman support several network drivers:

Bridge (Default)

Creates a private network on the host. Containers on the same bridge can communicate.

docker run -d --name web nginx
docker run -d --name api myapp
# Both containers are on the default 'bridge' network

Host

Container shares the host's network stack. No isolation.

docker run -d --network host nginx
# Nginx binds directly to host's port 80

None

No network access. Useful for batch jobs or security isolation.

docker run --network none alpine ping google.com
# Fails: no network

Custom Networks

User-defined bridges with specific configurations.

docker network create --subnet 172.20.0.0/16 mynet
docker run -d --network mynet --ip 172.20.0.10 nginx

Bridge Networking: The Default

When you start a container without specifying a network, it joins the default bridge network.

How It Works

Host Machine
├── docker0 (bridge interface: 172.17.0.1)
│   ├── Container A (172.17.0.2)
│   ├── Container B (172.17.0.3)
│   └── Container C (172.17.0.4)

The docker0 bridge acts as a virtual switch. Containers get IPs from the bridge's subnet.

Inspecting the Network

docker network inspect bridge

Output shows connected containers, their IPs, and network settings.

Container-to-Container Communication

On the default bridge, containers can only communicate by IP:

docker exec -it container-a ping 172.17.0.3
# Works: ping container-b by IP

docker exec -it container-a ping container-b
# Fails: DNS not available on default bridge

Custom Bridge: Enable DNS

Create a custom bridge network to enable DNS-based communication:

docker network create mynet

docker run -d --name web --network mynet nginx
docker run -d --name api --network mynet myapp

docker exec -it web ping api
# Works! DNS resolution via container name

Custom bridges provide:

  • Automatic DNS resolution by container name
  • Better isolation (containers on different networks can't communicate)
  • Configurable subnet, gateway, and IP range

Port Mapping: Exposing Services

Containers have their own network namespace. To access a container's service from outside, you must map ports.

Basic Port Mapping

docker run -d -p 8080:80 nginx

Syntax: -p <host_port>:<container_port>

Now access Nginx at http://localhost:8080. Traffic flows:

Browser → Host:8080 → Docker Proxy → Container:80

Specify Binding Address

# Bind to localhost only (not accessible from other machines)
docker run -d -p 127.0.0.1:8080:80 nginx

# Bind to specific interface
docker run -d -p 192.168.1.100:8080:80 nginx

Port Ranges

# Map a range of ports
docker run -d -p 8000-8010:8000-8010 myapp

Random Port Assignment

docker run -d -p 80 nginx
docker port <container_id>
# Shows assigned random port, e.g., 0.0.0.0:32768->80/tcp

View Mapped Ports

docker ps
# PORTS column shows mappings

docker port <container_name>
# Shows all port mappings for a container

Host Networking: Maximum Performance

Host networking removes the network isolation layer.

docker run -d --network host nginx

Advantages:

  • No port mapping needed (container uses host ports directly)
  • Slightly better performance (no NAT overhead)
  • Simpler configuration

Disadvantages:

  • No port isolation (container can bind to any host port)
  • Security risk (container has full network access)
  • Port conflicts (can't run two containers on same port)

Use cases:

  • Performance-critical applications
  • Network monitoring tools
  • When container needs to bind to privileged ports (< 1024)

Inter-Container Communication

Multi-service applications require containers to communicate.

Method 1: Shared Network (Recommended)

docker network create appnet

docker run -d --name db --network appnet postgres
docker run -d --name api --network appnet myapi
docker run -d --name web --network appnet nginx

# In API code, connect to database:
# DATABASE_URL=postgresql://user:pass@db:5432/mydb

Containers resolve each other by name via built-in DNS.

Method 2: Legacy Links (Deprecated)

docker run -d --name db postgres
docker run -d --name api --link db myapi

Links are deprecated. Use custom networks instead.

Method 3: Host Networking

All containers share the host network, so they communicate via localhost.

docker run -d --network host postgres
docker run -d --network host myapi
# API connects to postgresql://localhost:5432

Not recommended for production (no isolation).

Network Troubleshooting

Check Container IP

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container>
# Output: 172.18.0.2

Test Connectivity

# From host to container
curl http://<container_ip>:80

# From container to container
docker exec -it container-a ping container-b

# From container to external
docker exec -it container-a ping google.com

Check Network Rules

# List iptables rules
sudo iptables -L -n -v | grep docker

# List NAT rules
sudo iptables -t nat -L -n -v | grep docker

Debug DNS Resolution

docker exec -it container nslookup other-container
# Should resolve to container's IP

Common Issues

Problem: Can't connect to container by name.

Fix: Ensure both containers are on the same custom network (not default bridge).

Problem: Port mapping doesn't work.

Fix: Check if another process is using the host port:

lsof -i :8080

Problem: Container can't reach internet.

Fix: Check Docker daemon network config:

cat /etc/docker/daemon.json
# Ensure no restrictive DNS settings

Advanced: Macvlan Networks

Macvlan allows containers to get IPs from your physical network.

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  mymacvlan

docker run -d --network mymacvlan --ip 192.168.1.100 nginx

Now the container appears as a separate device on your LAN with its own IP.

Use cases:

  • Legacy applications that expect direct LAN access
  • Network monitoring appliances
  • When you need containers to be reachable by other LAN devices

Caveat: Not all WiFi adapters support macvlan.

Pod-Specific Networking (Podman)

Podman introduces pods: groups of containers sharing the same network namespace.

podman pod create --name mypod -p 8080:80

podman run -d --pod mypod nginx
podman run -d --pod mymypod myapi

# Both containers share the same network namespace
# API can reach Nginx at localhost:80

This mirrors Kubernetes pods, making migration easier.

Network Security

Restrict Inter-Container Traffic

By default, containers on the same network can communicate freely. Restrict this with firewall rules:

# Create network
docker network create securenet

# Add iptables rule to block traffic between specific containers
iptables -I DOCKER-USER -s 172.18.0.2 -d 172.18.0.3 -j DROP

Encrypt Container Traffic

For sensitive data, encrypt traffic between containers:

  • Use TLS/SSL in application protocols (HTTPS, PostgreSQL SSL)
  • Use service meshes (Istio, Linkerd) for automatic mTLS
  • Use WireGuard or IPSec tunnels between hosts

Network Policies (Kubernetes)

If you're moving to Kubernetes, network policies provide fine-grained control:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

FoxTerm Container Networking UI

FoxTerm visualizes container networking:

Network List

View all networks and connected containers:

  • Network name and driver
  • Subnet and gateway
  • Connected containers with IPs

Port Mapping Display

For each container, see active port mappings:

  • Host port → Container port
  • Protocol (TCP/UDP)
  • Binding address

One-Click Port Forward

Need to access a container's internal service? Click "Forward Port" and FoxTerm sets up SSH local port forwarding automatically:

Your Machine → SSH Tunnel → Server → Container:port

No manual ssh -L commands needed.

Conclusion

Container networking seems complex at first, but the fundamentals are straightforward: bridge networks for isolation, port mapping for external access, and custom networks for DNS-based communication. Whether you use Docker or Podman, these concepts apply universally.

Master these basics, and you'll build robust multi-container applications with confidence.

FoxTerm Pro manages Docker and Podman containers visually. Download at foxterm.app.