Master Single-Host Container Networking with Linux Namespaces, veth, and Bridges

Introduction

Containers feel magical, but for those who understand the underlying Linux mechanisms they are simply isolated processes. This guide solves single‑host container networking problems by virtualizing network resources, allowing containers to think they have exclusive networks, communicate safely, and reach the outside world.

Prerequisites

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

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

Network Namespace Isolation

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

<code># Create a namespace
$ sudo ip netns add netns0
$ sudo ip netns list
netns0

# Enter the namespace
$ sudo nsenter --net=/var/run/netns/netns0 bash
# Inside netns0 you see only a loopback device</code>

Virtual Ethernet (veth) Pair

veth devices come in pairs and act as a tunnel between namespaces.

<code>$ sudo ip link add veth0 type veth peer name ceth0</code>

Move one end into the namespace:

<code>$ sudo ip link set ceth0 netns netns0</code>

Assign IP addresses and bring interfaces up:

<code># Host side
$ sudo ip link set veth0 up
$ sudo ip addr add 172.18.0.11/16 dev veth0

# Inside netns0
$ sudo nsenter --net=/var/run/netns/netns0
$ ip link set lo up
$ ip link set ceth0 up
$ ip addr add 172.18.0.10/16 dev ceth0</code>

Ping tests confirm connectivity between the two ends.

Bridge (Virtual Switch)

Connecting multiple containers via a Linux bridge allows L2 forwarding.

<code># Create bridge
$ sudo ip link add br0 type bridge
$ sudo ip link set br0 up

# Attach veth devices to the bridge
$ sudo ip link set veth0 master br0
$ sudo ip link set veth1 master br0</code>

After assigning IPs to the container ends, they can ping each other through the bridge.

Connecting to the External World

Assign an IP to the bridge and add a default route inside each namespace.

<code>$ sudo ip addr add 172.18.0.1/16 dev br0
$ sudo nsenter --net=/var/run/netns/netns0
$ ip route add default via 172.18.0.1</code>

Enable IP forwarding on the host:

<code>sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'</code>

Apply NAT so container traffic appears to come from the host:

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

Now containers can reach the Internet (e.g., ping 8.8.8.8).

Port Publishing

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

<code># 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</code>

After loading the

br_netfilter

module, external clients can access the service via the host’s IP.

Docker Network Drivers Overview

Docker’s

--network host

mode shares the host’s network stack,

--network none

provides only a loopback interface, and the default

--network bridge

implements the veth‑bridge model described above.

Rootless Containers

Rootless containers (e.g., Podman) cannot create veth devices directly; they rely on

slirp4netns

to provide user‑space networking. Without CAP_NET_RAW they cannot use

ping

, and they lack a real IP address.

Conclusion

The presented approach—using network namespaces, veth pairs, a Linux bridge, routing, and iptables—is a widely used, simple solution for single‑host container networking. Many other methods exist, but they all depend on Linux network virtualization.