LFCE 26 🐧 Network Namespaces — Practical Use - KandZ

⏱️ Estimated read: 16 min | |

The previous chapter established the concepts: a network namespace is a logical copy of the kernel network stack, isolated from the default namespace and from every other namespace. This chapter is the practical application. It covers the four patterns that account for nearly every real-world use of network namespaces: connecting two namespaces with a veth pair, connecting multiple namespaces through a bridge, providing outbound internet access with NAT, and isolating a process behind a VPN tunnel interface. Each pattern builds on the commands introduced in the previous chapter, and each one produces a working configuration that can be verified with ping and ip route get.

Key point: A network namespace alone provides isolation but not connectivity. A namespace with only a loopback interface can talk to itself and nothing else. Connectivity requires a veth pair—one end in the namespace, one end outside—and the outside end must be attached to something that forwards: a bridge for Layer 2 connectivity, or a routed interface with NAT for Layer 3 access. The namespace does not know about the host’s network unless an explicit link connects it.

Why practical patterns matter more than individual commands

The isolation-without-connectivity problem.

Creating a namespace with ip netns add produces a blank stack. The loopback interface exists but is down. There is no route to any destination outside the namespace. This is correct for isolation, but most practical uses require the namespace to reach something. The veth pair is the mechanism that provides the connection, and the placement of each end determines what the namespace can reach. If both ends are in the same namespace, the pair is useless. If one end is in the namespace and the other is attached to a bridge, the namespace can reach every other namespace on that bridge. If the other end is attached to a routed interface with NAT, the namespace can reach the internet.

The bridge-for-multiple-namespaces problem.

A veth pair connects exactly two endpoints. If two namespaces need to communicate, one veth pair is sufficient: one end in each namespace. If three or more namespaces need to communicate, a bridge is required. Each namespace gets its own veth pair, with one end in the namespace and the other end attached to the bridge. The bridge forwards frames between all attached interfaces, creating a shared Layer 2 segment. This is the same architecture that container runtimes use: a bridge on the host, and a veth pair for each container .

The NAT-for-outbound-access problem.

A namespace connected to a bridge can reach other namespaces on the same bridge, but it cannot reach the internet unless the host forwards and translates its traffic. The host must enable IP forwarding (net.ipv4.ip_forward=1) and add a NAT rule that masquerades traffic from the namespace’s subnet as traffic from the host’s external interface. Without the NAT rule, the namespace’s packets reach the host, but the host does not know how to route the return traffic back to the namespace .

The VPN-isolation problem.

A namespace can be used to force a process’s traffic through a VPN tunnel. The WireGuard interface is created in the default namespace, moved into the namespace, and configured with a default route inside the namespace. The process inside the namespace has only one path out: the WireGuard interface. If the tunnel goes down, the process has no network access at all—it cannot leak traffic outside the tunnel. This is a stronger guarantee than policy routing, which operates within a single stack and can be bypassed by processes with sufficient privileges .

a. Two namespaces connected by a veth pair

The simplest practical pattern is two namespaces connected directly. Each namespace receives one end of a veth pair, an IP address on a shared subnet, and a route to the peer.

# Create two namespaces
ip netns add red
ip netns add blue

# Create a veth pair
ip link add veth-red type veth peer name veth-blue

# Move each end into its namespace
ip link set veth-red netns red
ip link set veth-blue netns blue

# Assign addresses and bring up the interfaces
ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue
ip netns exec red ip link set lo up
ip netns exec red ip link set veth-red up
ip netns exec blue ip link set lo up
ip netns exec blue ip link set veth-blue up

# Test connectivity
ip netns exec red ping -c 2 192.168.15.2

The /24 prefix on each address is essential. Without it, the kernel does not install a route for the subnet, and ping fails with “Network is unreachable.” The veth pair is a point-to-point link, but the kernel treats it as a broadcast-capable Ethernet segment because the prefix defines a subnet. The loopback interface must also be brought up inside each namespace for local processes to function correctly.

b. Multiple namespaces connected by a bridge

When more than two namespaces need to communicate, a bridge replaces the direct veth pair. The bridge acts as a virtual switch in the host namespace. Each namespace gets a veth pair; one end goes into the namespace, and the other end attaches to the bridge .

# Create the bridge
ip link add br0 type bridge
ip link set br0 up

# Create three namespaces
ip netns add ns1
ip netns add ns2
ip netns add ns3

# For each namespace, create a veth pair and attach one end to the bridge
ip link add veth1 type veth peer name br-veth1
ip link set veth1 netns ns1
ip link set br-veth1 master br0
ip link set br-veth1 up

ip link add veth2 type veth peer name br-veth2
ip link set veth2 netns ns2
ip link set br-veth2 master br0
ip link set br-veth2 up

ip link add veth3 type veth peer name br-veth3
ip link set veth3 netns ns3
ip link set br-veth3 master br0
ip link set br-veth3 up

# Configure each namespace
ip netns exec ns1 ip addr add 10.0.1.1/24 dev veth1
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip link set veth1 up

ip netns exec ns2 ip addr add 10.0.1.2/24 dev veth2
ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set veth2 up

ip netns exec ns3 ip addr add 10.0.1.3/24 dev veth3
ip netns exec ns3 ip link set lo up
ip netns exec ns3 ip link set veth3 up

# Verify connectivity between any two namespaces
ip netns exec ns1 ping -c 2 10.0.1.2
ip netns exec ns1 ping -c 2 10.0.1.3

The bridge does not need an IP address for the namespaces to communicate with each other. The bridge forwards frames based on MAC addresses, and the namespaces share the same subnet. If the host needs to communicate with the namespaces, it can have an address on the bridge, but that address is not required for namespace-to-namespace connectivity.

c. Providing outbound internet access with NAT

A namespace connected to a bridge can reach other namespaces, but it cannot reach the internet without NAT. The host must forward packets from the namespace and translate the source address to the host’s external interface.

# Enable IP forwarding on the host
sysctl -w net.ipv4.ip_forward=1

# Add a NAT rule for the namespace subnet
# Replace eth0 with the host's external interface
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE

# Inside the namespace, add a default route pointing to the bridge
ip netns exec ns1 ip route add default via 10.0.1.254

# The bridge must have the gateway address
ip addr add 10.0.1.254/24 dev br0

The MASQUERADE target performs source NAT, replacing the namespace’s source address with the host’s external address. The return traffic is automatically translated back to the namespace’s address. This is the same mechanism that home routers use to share a single public IP address among multiple devices .

The default route inside the namespace points to the bridge’s IP address. The namespace sends all non-local traffic to the bridge, the bridge forwards it to the host’s routing stack, and the host forwards it out the external interface after applying NAT. Without the default route, the namespace does not know where to send traffic destined for the internet.

d. Isolating a process behind a VPN tunnel

A namespace can force all of a process’s traffic through a VPN interface. The WireGuard interface is created in the default namespace and moved into the namespace, where it becomes the only path out .

# Create the namespace
ip netns add vpnns

# Create the WireGuard interface in the default namespace
ip link add wg0 type wireguard

# Move it into the namespace
ip link set wg0 netns vpnns

# Configure it inside the namespace
ip netns exec vpnns ip addr add 192.168.4.33/32 dev wg0
ip netns exec vpnns ip link set wg0 up
ip netns exec vpnns ip route add default dev wg0

# Configure the WireGuard peer (keys, endpoint, allowed IPs)
ip netns exec vpnns wg setconf wg0 /etc/wireguard/wg0.conf

# Run a process inside the namespace
ip netns exec vpnns curl https://example.com

The namespace has no other interface except loopback and wg0. The default route points to wg0. If the WireGuard tunnel is not established, the curl command fails because there is no other path. This is the strongest form of VPN isolation: the process cannot leak traffic outside the tunnel because the namespace has no interface connected to the outside world except the tunnel itself .

The WireGuard configuration file must be accessible inside the namespace, or the keys must be passed through wg set with explicit arguments. The endpoint address must be reachable from the namespace, which is possible because the WireGuard interface handles the encapsulation and sends the encrypted packets out through the host’s routing stack after they leave the namespace.

Complete Example Session

# ============================================
# PART 1: CREATE A BRIDGE AND TWO NAMESPACES
# ============================================
ip link add br0 type bridge
ip link set br0 up

ip netns add web
ip netns add db

# ============================================
# PART 2: CONNECT WEB TO THE BRIDGE
# ============================================
ip link add veth-web type veth peer name br-web
ip link set veth-web netns web
ip link set br-web master br0
ip link set br-web up

ip netns exec web ip addr add 10.0.1.10/24 dev veth-web
ip netns exec web ip link set lo up
ip netns exec web ip link set veth-web up

# ============================================
# PART 3: CONNECT DB TO THE BRIDGE
# ============================================
ip link add veth-db type veth peer name br-db
ip link set veth-db netns db
ip link set br-db master br0
ip link set br-db up

ip netns exec db ip addr add 10.0.1.20/24 dev veth-db
ip netns exec db ip link set lo up
ip netns exec db ip link set veth-db up

# ============================================
# PART 4: VERIFY NAMESPACE-TO-NAMESPACE CONNECTIVITY
# ============================================
ip netns exec web ping -c 2 10.0.1.20

# ============================================
# PART 5: PROVIDE INTERNET ACCESS WITH NAT
# ============================================
# Assign a gateway address to the bridge
ip addr add 10.0.1.254/24 dev br0

# Enable forwarding
sysctl -w net.ipv4.ip_forward=1

# Add NAT rule (replace eth0 with the host's external interface)
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE

# Add default routes inside the namespaces
ip netns exec web ip route add default via 10.0.1.254
ip netns exec db ip route add default via 10.0.1.254

# ============================================
# PART 6: TEST OUTBOUND ACCESS
# ============================================
ip netns exec web ping -c 2 8.8.8.8

# ============================================
# PART 7: ISOLATE A PROCESS BEHIND A VPN
# ============================================
# (Assuming WireGuard is installed and configured)
ip netns add vpnns
ip link add wg0 type wireguard
ip link set wg0 netns vpnns
ip netns exec vpnns ip addr add 192.168.4.33/32 dev wg0
ip netns exec vpnns ip link set wg0 up
ip netns exec vpnns ip route add default dev wg0
# ip netns exec vpnns wg setconf wg0 /etc/wireguard/wg0.conf

# ============================================
# PART 8: VERIFY ISOLATION
# ============================================
# The namespace has only wg0 and lo
ip netns exec vpnns ip addr show
# Attempting to reach the internet without the tunnel fails
ip netns exec vpnns ping -c 1 -W 1 8.8.8.8

# ============================================
# PART 9: CLEAN UP
# ============================================
ip netns pids web | xargs -r kill
ip netns pids db | xargs -r kill
ip netns pids vpnns | xargs -r kill
ip netns delete web
ip netns delete db
ip netns delete vpnns
ip link delete br0

The nine parts demonstrate the four practical patterns: bridge creation, namespace attachment, connectivity verification, NAT configuration, outbound access testing, VPN isolation, and cleanup. The critical verification steps are Part 4 (namespace-to-namespace ping) and Part 6 (outbound internet ping). If Part 4 succeeds but Part 6 fails, the problem is NAT or forwarding. If Part 4 fails, the problem is the bridge or the veth pair.

Quick Reference

Pattern Summary

Pattern	Components	Use Case
Direct veth	Two namespaces, one veth pair	Point-to-point test, two-process isolation
Bridge	Bridge + N veth pairs	Multi-namespace communication, container networking
NAT	Bridge + forwarding + MASQUERADE	Outbound internet access from namespace
VPN isolation	WireGuard interface moved into namespace	Force process through tunnel, prevent leaks

Key Commands

Task	Command
Create bridge	`ip link add br0 type bridge`
Attach veth to bridge	`ip link set br-veth master br0`
Enable forwarding	`sysctl -w net.ipv4.ip_forward=1`
Add NAT rule	`iptables -t nat -A POSTROUTING -s <subnet> -o <if> -j MASQUERADE`
Move WireGuard to namespace	`ip link set wg0 netns <ns>`
Default route in namespace	`ip netns exec <ns> ip route add default via <gw>`

Verification Checklist

Check	Command	Expected
Namespace-to-namespace	`ip netns exec ns1 ping <ns2-ip>`	Replies
Namespace-to-internet	`ip netns exec ns1 ping 8.8.8.8`	Replies (NAT configured)
Namespace interfaces	`ip netns exec ns1 ip addr show`	Only lo + veth/wg
Host forwarding	`sysctl net.ipv4.ip_forward`	`= 1`
NAT rule exists	`iptables -t nat -L POSTROUTING`	MASQUERADE rule

Best Practices

✅ Do This:

# Bring up loopback inside every namespace
ip netns exec <ns> ip link set lo up                          # ✅

# Use a bridge for more than two namespaces
ip link add br0 type bridge                                   # ✅

# Enable forwarding before adding NAT rules
sysctl -w net.ipv4.ip_forward=1                               # ✅

# Add default route inside namespace for internet access
ip netns exec <ns> ip route add default via <bridge-ip>       # ✅

# Verify connectivity in stages (peer first, then internet)
ip netns exec <ns> ping <peer>; ip netns exec <ns> ping 8.8.8.8 # ✅

# Kill processes before deleting namespaces
ip netns pids <ns> | xargs -r kill                            # ✅

❌ Don’t Do This:

# Forget loopback inside the namespace
ip netns exec <ns> ping 127.0.0.1    # Fails if lo is down    # ❌

# Use a veth pair for three namespaces
# A veth connects exactly two endpoints                       # ❌

# Expect internet access without NAT
# The namespace's private address is not routable              # ❌

# Forget the default route inside the namespace
ip netns exec <ns> ping 8.8.8.8    # "Network is unreachable" # ❌

# Delete a namespace with running processes
ip netns delete <ns>    # Interfaces may be trapped           # ❌

# Assume NAT applies without checking the interface name
# MASQUERADE must use the correct external interface            # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Namespace cannot ping peer	Bridge not up, or veth not attached	Check `ip link show master br0`
Namespace cannot reach internet	Forwarding disabled or NAT missing	`sysctl ip_forward=1`; add MASQUERADE
“Network is unreachable”	No default route in namespace	`ip netns exec <ns> ip route add default ...`
NAT rule exists but no traffic	Wrong external interface in MASQUERADE	Match `-o` to the host’s outbound interface
Loopback unreachable	`lo` down in namespace	`ip netns exec <ns> ip link set lo up`
VPN namespace leaks traffic	Another interface present in namespace	Verify only `wg0` and `lo` exist

Real-World Examples

1. Two namespaces with veth

ip link add veth-a type veth peer name veth-b
ip link set veth-a netns ns1
ip link set veth-b netns ns2

2. Bridge for multiple namespaces

ip link add br0 type bridge
ip link set veth1 master br0

3. Enable forwarding

sysctl -w net.ipv4.ip_forward=1

4. NAT for outbound access

iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE

5. Default route in namespace

ip netns exec ns1 ip route add default via 10.0.1.254

6. Verify peer connectivity

ip netns exec ns1 ping 10.0.1.2

7. Verify internet access

ip netns exec ns1 ping 8.8.8.8

8. Move WireGuard into namespace

ip link set wg0 netns vpnns

9. VPN default route

ip netns exec vpnns ip route add default dev wg0

10. Clean up namespaces

ip netns pids ns1 | xargs -r kill; ip netns delete ns1

Visual

The Bridge Pattern

┌──────────────────────────────────────────────────────────────┐
│  BRIDGE CONNECTS MULTIPLE NAMESPACES                         │
│                                                              │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐                   │
│  │ ns1     │    │ ns2     │    │ ns3     │                   │
│  │ veth1   │    │ veth2   │    │ veth3   │                   │
│  └────┬────┘    └────┬────┘    └────┬────┘                   │
│       │              │              │                        │
│       ▼              ▼              ▼                        │
│  ┌─────────────────────────────────────────────┐             │
│  │              br0 (bridge)                   │             │
│  │         (virtual switch in host)            │             │
│  └─────────────────────────────────────────────┘             │
│                                                              │
│  Each namespace has one end of a veth pair.                  │
│  The other end is attached to br0.                           │
│  All namespaces share the same subnet.                       │
│  The bridge forwards frames between all ports.               │
└──────────────────────────────────────────────────────────────┘

NAT for Outbound Access

┌──────────────────────────────────────────────────────────────┐
│  NAMESPACE → BRIDGE → HOST → NAT → INTERNET                  │
│                                                              │
│  ┌─────────────┐                                             │
│  │ Namespace   │  src: 10.0.1.10                             │
│  │ 10.0.1.10   │                                             │
│  └──────┬──────┘                                             │
│         │                                                    │
│         ▼                                                    │
│  ┌─────────────┐                                             │
│  │ br0         │  Gateway: 10.0.1.254                       │
│  └──────┬──────┘                                             │
│         │                                                    │
│         ▼                                                    │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │ Host routing stack                                      │ │
│  │ ip_forward = 1                                          │ │
│  │ POSTROUTING: -s 10.0.1.0/24 -o eth0 -j MASQUERADE      │ │
│  └──────────────────────────┬──────────────────────────────┘ │
│                             │                                │
│                             ▼                                │
│  ┌─────────────┐                                             │
│  │ eth0        │  src: 203.0.113.5 (host's public IP)        │
│  └──────┬──────┘                                             │
│         │                                                    │
│         ▼                                                    │
│  ┌─────────────┐                                             │
│  │ Internet    │  Return traffic: dst 203.0.113.5            │
│  └─────────────┘  Host translates back to 10.0.1.10          │
└──────────────────────────────────────────────────────────────┘

VPN Isolation

┌──────────────────────────────────────────────────────────────┐
│  NAMESPACE WITH ONLY A WIREGUARD INTERFACE                   │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Namespace: vpnns                                       │  │
│  │                                                        │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │ Interfaces:                                      │  │  │
│  │  │   lo   (127.0.0.1/8)                             │  │  │
│  │  │   wg0  (192.168.4.33/32)                         │  │  │
│  │  │                                                  │  │  │
│  │  │ Default route: dev wg0                           │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  │                                                        │  │
│  │  Process: curl https://example.com                     │  │
│  │       │                                                │  │
│  │       └── Only path: wg0 → encrypted tunnel            │  │
│  │                                                        │  │
│  │  If tunnel is down: no network access at all.          │  │
│  │  No leak possible: no other interface exists.          │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Direct connectivity	veth pair, one end per namespace
Multi-namespace connectivity	Bridge + one veth pair per namespace
Outbound internet	`ip_forward=1` + MASQUERADE + default route
VPN isolation	WireGuard interface moved into namespace
Loopback	Must be brought up in every namespace
Prefix requirement	Addresses need `/24` or `/30` for routes
Cleanup	Kill processes before `ip netns delete`

Key takeaways:

A veth pair connects exactly two endpoints. For two namespaces, one pair is sufficient. For three or more, a bridge is required, with each namespace getting its own veth pair .
The bridge is a virtual switch. It forwards frames between all attached ports. Namespaces on the same bridge share a Layer 2 segment and can communicate without routing.
NAT is required for outbound internet access. The host must forward packets from the namespace subnet and masquerade them as traffic from its external interface. Without NAT, the namespace’s private address is not routable .
A default route inside the namespace points to the bridge. The namespace sends non-local traffic to the bridge, the bridge forwards it to the host, and the host applies NAT before sending it out.
VPN isolation is stronger than policy routing. A namespace with only a WireGuard interface cannot leak traffic outside the tunnel, because no other interface exists. If the tunnel is down, the namespace has no network access at all .
Cleanup requires killing processes first. ip netns delete removes the namespace name, but if processes are still running inside, the interfaces may be trapped until those processes exit.

Remember: Network namespaces are isolation primitives. They start empty, with only a down loopback. Connectivity requires a veth pair, and the outside end must attach to something that forwards—a bridge for peer-to-peer, or a routed interface with NAT for internet access. For VPN isolation, the tunnel interface is the only interface, and the namespace has no other path. Configure the veth, attach the bridge, enable forwarding, add the NAT rule, set the default route, and verify with ping. The namespace does not know about the host’s network unless you build the bridge to it.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!