Unlocking Single‑Host Container Networking: From Namespaces to Bridge and NAT

Using containers can feel like magic: they are just isolated Linux processes, and you don’t even need an image to run one. This article tackles the single‑host container networking problem by answering how to virtualize network resources, isolate containers, enable inter‑container communication, reach the outside world, and publish ports.

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

We use Docker or Podman as the container runtime and focus on the simplest tools.

Network namespace isolation

Linux network namespaces provide a separate network stack with its own devices, routes, and firewall rules.

$ sudo ip netns add netns0
$ ip netns list
netns0
$ sudo ip netns exec netns0 bash
# inside netns0 you will see only lo

Creating a veth pair

A virtual Ethernet device appears as a pair; one end stays in the root namespace, the other moves into the container namespace.

$ 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 netns exec netns0 ip link set ceth0 up
$ sudo ip netns exec netns0 ip addr add 172.18.0.10/16 dev ceth0
$ sudo ip addr add 172.18.0.11/16 dev veth0

Ping tests confirm that each namespace sees its own isolated stack.

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

Connecting containers with a bridge

When multiple containers share the same IP subnet, a Linux bridge (L2 switch) forwards traffic between them.

$ 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 assigning IPs to the peer ends (ceth0, ceth1) and bringing the interfaces up, the containers can ping each other.

$ sudo ip netns exec netns0 ping -c 2 172.18.0.20
$ sudo ip netns exec netns1 ping -c 2 172.18.0.10

Connecting the bridge to the host

Assign an address to the bridge so the host can reach the containers.

$ sudo ip addr add 172.18.0.1/16 dev br0

Now the host can ping both containers, and the containers can reach the host.

Enabling external access (IP forwarding & NAT)

Enable packet forwarding on the host and add a MASQUERADE rule so containers can reach the Internet.

# enable forwarding
$ sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
# NAT for container subnet
$ sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE

After this, a ping to 8.8.8.8 from inside a container succeeds.

Port publishing

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

# forward traffic arriving at host IP:5000 to container
$ 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

Now curl 10.0.2.15:5000 reaches the HTTP server running inside the container.

Docker network drivers

Docker’s --network host mode shares the host’s network namespace, --network none provides only a loopback interface, and the default --network bridge implements the bridge scenario described above.

Rootless containers

Rootless containers (e.g., Podman) cannot create veth devices directly; they rely on slirp4netns to provide user‑space networking. While functional, they lack true IP addresses and cannot use ping without additional capabilities.

Conclusion

The presented approach—network namespaces, veth pairs, a Linux bridge, routing, and NAT—is one of the most common ways to wire containers on a single host. Many other solutions exist, but they all depend on Linux network virtualization primitives.

Original article: https://iximiuz.com/en/posts/container-networking-is-simple/