The Network Isolation Problem

Imagine an apartment building where every apartment is completely soundproof and sealed.

The Apartments are the containers. Each has its own phone line (network interface), its own phone number (IP address), and its own phone (ports).

Problem: Someone outside the building wants to call apartment 3B.

They don’t have apartment 3B’s direct number. The building’s apartments have private, internal numbers that only work within the building.

Solution: The building has a receptionist (the host’s network).

When someone calls the building’s main number, the receptionist answers. Based on which extension the caller asks for, the receptionist routes the call to the correct apartment.

This is port mapping. The outside world calls the building’s main number (the host’s IP) and specifies an extension (a port like 8080). The receptionist forwards the call to the right apartment (the container).

Inter-apartment communication:

If apartment 3B wants to call apartment 5C, they can use the internal phone system. There’s a directory (DNS) that says “apartment 5C is at extension 205.”

This is Docker’s networking. Containers can reach each other using names, and Docker’s internal DNS resolves those names to IP addresses.

When Docker creates a container, it:

1. Creates a new network namespace
2. Creates a virtual Ethernet pair (veth pair)
   • One end goes into the container (appears as eth0)
   • One end stays on the host (appears as veth...)
3. Connects the host end to a bridge (virtual switch)
4. Assigns the container an IP address from the bridge’s subnet

The result:

• The container has its own eth0 interface with an IP like 172.17.0.2
• The host has a veth... interface connected to the container
• All containers are connected to the same bridge (default: docker0)
• The bridge acts like a virtual switch, allowing containers to talk to each other

But:

• The container’s IP is private. The host can reach it, other containers can reach it, but the outside world can’t directly.
• This is where port mapping comes in.

When Docker is installed, it creates a default bridge network.

View the default bridge:

docker network ls

You’ll see:

NETWORK ID     NAME      DRIVER    SCOPE
xxxxxxxxxxxx   bridge    bridge    local
xxxxxxxxxxxx   host      host      local
xxxxxxxxxxxx   none      null      local

The bridge network is the default.

View bridge details:

docker network inspect bridge

You’ll see something like:

{
    "Name": "bridge",
    "Driver": "bridge",
    "IPAM": {
        "Config": [{"Subnet": "172.17.0.0/16"}]
    },
    "Containers": {}
}

The subnet 172.17.0.0/16 means containers get IPs from 172.17.0.1 to 172.17.255.255.

Start a container and check its IP:

docker run -d --name web nginx
docker inspect web --format='{{.NetworkSettings.IPAddress}}'

You’ll see something like 172.17.0.2.

Try to ping it from the host:

ping 172.17.0.2

This works! The host can reach the container.

Try from your laptop (not the Docker host):

If your Docker host is a VM or remote server, try pinging the container IP from your laptop.

It won’t work. The container’s IP is private to the Docker host.

Docker networking solves three problems:

1. External → Container (Port Mapping)

How does a user’s browser reach a web server running in a container?

Solution: Port mapping (-p 8080:80). The host listens on port 8080 and forwards traffic to the container’s port 80.

2. Container → Container (Bridge Network)

How does a web container talk to a database container?

Solution: Both containers are on the same bridge network. They can reach each other using the bridge’s subnet (like 172.17.0.x). Even better, Docker provides DNS so they can use names instead of IPs.

3. Container → Internet (NAT)

How does a container make an HTTP request to Google?

Solution: Docker uses NAT (Network Address Translation). The container’s private IP is translated to the host’s public IP when making outbound connections.

---