Master Single‑Host Container Networking with Linux Namespaces, veth & Bridges

Prerequisites

Any Linux distribution works; the examples run on a Vagrant CentOS 8 VM.

$ vagrant init centos/8
$ vagrant up
$ vagrant ssh
[vagrant@localhost ~]$ uname -a
Linux localhost.localdomain 4.18.0-147.3.1.el8_1.x86_64

Network Namespace Isolation

Containers are isolated Linux processes. A network namespace provides a separate network stack with its own devices, routes, and firewall rules.

$ sudo ip netns add netns0
$ ip netns list
netns0

Enter the namespace with nsenter to see its isolated stack.

$ sudo nsenter --net=/var/run/netns/netns0 bash
[netns0]$ ip link
[netns0]$ ip route

Connecting Containers with veth

Virtual Ethernet (veth) devices come in pairs and act as a tunnel between namespaces.

$ sudo ip link add veth0 type veth peer name ceth0
$ sudo ip link set ceth0 netns netns0
$ sudo ip link set veth0 up
$ sudo ip addr add 172.18.0.11/16 dev veth0
$ sudo nsenter --net=/var/run/netns/netns0
[netns0]$ ip link set lo up
[netns0]$ ip link set ceth0 up
[netns0]$ ip addr add 172.18.0.10/16 dev ceth0

Ping tests show connectivity between the host side (veth0) and the container side (ceth0).

# Inside netns0
$ ping -c 2 172.18.0.11
# Inside root namespace
$ ping -c 2 172.18.0.10

Using a Virtual Bridge

When multiple containers share the same IP subnet, a Linux bridge works like a virtual switch, forwarding L2 frames between attached interfaces.

$ sudo ip link add br0 type bridge
$ sudo ip link set br0 up
$ sudo ip link set veth0 master br0
$ sudo ip link set veth1 master br0

After attaching both veth pairs to br0, containers can ping each other across namespaces.

# From netns0
$ ping -c 2 172.18.0.20
# From netns1
$ ping -c 2 172.18.0.10

Connecting to the External World (Routing & NAT)

Assign an IP to the bridge so the host can route traffic to the containers. $ sudo ip addr add 172.18.0.1/16 dev br0 Enable IP forwarding on the host.

# Enable forwarding
$ sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

Apply NAT (MASQUERADE) for outbound traffic.

$ sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE

Now containers can reach the Internet:

# Inside netns0
$ ping -c 2 8.8.8.8

Port Publishing

Expose a container service on the host’s external interface using DNAT.

# Forward host port 5000 to container 172.18.0.10:5000
$ sudo iptables -t nat -A PREROUTING -d 10.0.2.15 -p tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000
$ sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -p tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000

Load the br_netfilter module so the bridge sees iptables rules. $ sudo modprobe br_netfilter Test with curl from the host:

$ curl 10.0.2.15:5000

Understanding Docker Network Drivers

Docker’s default bridge mode mirrors the manual bridge setup shown above. The host mode disables network namespace isolation, while none provides only a loopback interface.

Rootless Containers and Networking

Rootless containers (e.g., Podman) cannot create veth pairs directly; they rely on slirp4netns to provide user‑space networking. This limits direct IP access and raw socket capabilities, but still offers basic connectivity.

Conclusion

The presented approach—network namespaces, veth pairs, a Linux bridge, routing, and NAT—covers a widely used method for single‑host container networking. While many alternative plugins exist, they all depend on Linux’s virtual networking primitives, making container networking fundamentally a form of OS‑level virtualization.

References

Docker network drivers

Podman container networking

slirp4netns project

Linux virtual networking intro