NAT

The container has an address, a route, and no way to reach anything beyond the host. Its 10.0.0.2 is a private address from RFC 1918 — the packet gets out, and the reply has nowhere to come back to.

Network Address Translation fixes that by having the host rewrite the packet's source address to its own on the way out, remember the substitution, and undo it on the way back. Three iptables rules.

Find your real interface first

Everything below refers to the host's uplink, which is whatever your default route uses:

Take the name after dev. On a laptop it is usually wlan0; on a server, eth0 or something like enp3s0.

DIF="wlan0"              # the host's real interface
BRIDGE_IFACE="bridge0"

Enable forwarding

By default a Linux host will not route packets between its interfaces at all — it is a host, not a router. That has to be turned on:

sudo sysctl -w net.ipv4.ip_forward=1

This one setting is behind a surprising share of "containers have no internet" incidents, because a sysctl -w is lost on reboot unless it is written into /etc/sysctl.d/. Docker sets it on start; nothing sets it for you here.

The three rules

# 1. Masquerade container traffic as the host's own
sudo iptables -t nat -A POSTROUTING -o $DIF -j MASQUERADE

# 2. Allow container -> internet
sudo iptables -A FORWARD -i $BRIDGE_IFACE -o $DIF -j ACCEPT

# 3. Allow the replies back
sudo iptables -A FORWARD -o $BRIDGE_IFACE -m state --state RELATED,ESTABLISHED -j ACCEPT

Rule 1 is the translation. POSTROUTING in the nat table is the last point before a packet leaves; MASQUERADE rewrites its source address to whatever address the outgoing interface currently has. It is SNAT for interfaces whose address you don't know in advance — DHCP, a dial-up link, a laptop moving between networks.

Rule 2 permits forwarding from the bridge out to the world. Forwarding was enabled by the sysctl, but the FORWARD chain still has to accept the packet.

Rule 3 is the return path, and it is the interesting one. It does not permit the internet to initiate connections to your container — it permits packets belonging to a connection the container already started. RELATED,ESTABLISHED is conntrack, the kernel's connection tracking table, deciding that a packet is part of a flow it has already seen.

That asymmetry is why a container gets outbound internet access without becoming reachable from outside. Inbound access is a separate, deliberate act — a DNAT rule, which is what -p 8080:80 creates.

The packet counter on that rule is the fastest diagnostic there is: zero means traffic is not reaching NAT at all, and the problem is routing or the FORWARD chain rather than translation.

What NAT costs you

Worth knowing before you assume it is free.

• Conntrack has a table, and the table has a size. Every tracked flow occupies an entry. Under enough connections you hit nf_conntrack: table full, dropping packet in dmesg, and traffic fails in a way that looks like random packet loss.
• Inbound connections need explicit mapping. Hence port publishing, and hence the fact that two containers cannot both publish host port 8080.
• The container does not know its own public address. It sees 10.0.0.2; the world sees the host's address. Anything that advertises its own address — SIP, FTP in active mode, some clustering protocols — needs to be told what to say.
• It costs a little latency and CPU on every packet. Rarely decisive, occasionally measurable at high packet rates.

Kubernetes avoids most of this by giving every pod a routable address on a flat network, which is what a CNI plugin is for. The trade is complexity: you need something that actually routes those addresses.

Next up: cgroups — capping what the container is allowed to consume, rather than what it is allowed to see.