Port Publishing, NAT, Firewall Interaction, Direct Routing, Host Binding, and Exposure Security: Concepts, Architecture, and Mental Model

1. Why exposure must be traced, not guessed

Chapter 18 kept all traffic inside Docker networks. Chapter 19 crosses a trust boundary: clients outside the container network may reach an application through the Docker host. This introduces independent state at the application, container endpoint, Docker daemon, host socket/firewall, routing/NAT, and external-client layers.

A container may be healthy internally while no host port is published. A publish mapping may exist while the application listens on a different port. A host socket can appear correct while a host firewall or upstream router blocks the path. Conversely, an all-interface publish can expose a service farther than intended even if the developer only tested from localhost.

2. Mental model: listener → endpoint → publish → host path → client

The application first binds an address and port inside the container network namespace. Docker then associates a container port with a host bind address/port when -p/--publish or an equivalent Compose ports declaration is used. On a native Linux bridge network, Docker normally programs firewall/NAT/PAT rules. In direct-routing designs, the client can route to a container address under controlled gateway-mode/routing policy. Docker Desktop uses its managed networking/backend path rather than exposing the Linux VM's bridge exactly like a native host.

flowchart TD
  A[Application process listen address + port] --> E[Container endpoint network + container IP]
  E --> P[Docker publish state host IP:port -> container port]
  P --> H[Host bind/interface firewall + NAT/PAT or routing]
  H --> C[Client path local, LAN, routed, proxy]
  C --> R[Application response]
  X[EXPOSE metadata] -. documents intent only .-> P
            

3. State that must stay separate

4. Host bind address is part of the security policy

If you omit the host IP in a normal publish mapping, Docker publishes on all host addresses by default. That is convenient for demos and frequently wrong for databases, admin consoles, debug endpoints, and local-only development tools. Binding to 127.0.0.1 expresses a narrower local-host intent in the default NAT mode.

Do not infer “loopback-only” from a browser test performed on the Docker host. Inspect the mapping itself. Also record the Engine version: Docker documents a historical pre-28 behavior in which same-L2 hosts could reach localhost-published ports; current releases include the fix, but reproducibility requires the version to be known.

5. NAT, masquerading, and direct routing are different packet models

Default bridge gateway mode is nat. Published ports receive NAT/PAT/firewall rules and outbound container traffic normally masquerades as a host address. Docker also supports gateway modes such as routed, where no NAT/masquerade is configured for that address family and remote clients need a route to the container network; Docker still filters so that only published container ports are reachable. nat-unprotected deliberately removes that protection for unpublished ports and is unsuitable as a casual troubleshooting shortcut.

Direct routing is an infrastructure decision, not a faster spelling of -p. It requires route ownership and security review. The mandatory labs stay with default local NAT publication and inspect direct-routing concepts without changing daemon or router policy.

6. Docker and host firewalls share responsibility

On Linux bridge networks Docker creates firewall rules required for network isolation and port publishing. iptables is the default backend; Engine 29 also has an experimental nftables backend. Docker warns against disabling its rule management without replacing the required behavior. UFW/firewalld interactions also require Docker-specific understanding because packets can be diverted through Docker-managed rules before ordinary host-policy assumptions apply.

Therefore: do not “fix” a publish problem by flushing rules, disabling a firewall, or changing the daemon backend. Capture evidence first, identify the exact layer, and make the smallest authorized change.

7. EXPOSE is metadata, publication is runtime state

EXPOSE 8080 records an image author's intended listening port. It does not create a host mapping. docker run --expose behaves similarly. A runtime -p mapping can publish a port whether or not the image declares EXPOSE. -P uses exposed ports as input and assigns host ports automatically.

This distinction is valuable in incident response: image metadata can say “8080 intended,” container configuration can say “host 127.0.0.1:49153 maps to 8080,” while the process may actually be listening on 9090. Those are three separate facts.

8. Read-only baseline before changing exposure

docker version
docker info
docker context show
docker compose version || true

docker network ls
docker ps -a --no-trunc

docker pull busybox:1.36.1
docker image inspect busybox:1.36.1 --format 'ID={{.Id}} RepoDigests={{json .RepoDigests}}'

# Existing container mappings.
docker ps --format 'table {{.Names}}	{{.Status}}	{{.Ports}}'

# Replace <container> only with an object you are authorized to inspect.
docker port <container> 2>/dev/null || true
docker inspect <container> \
  --format   'Mode={{.HostConfig.NetworkMode}} Ports={{json .NetworkSettings.Ports}} Exposed={{json .Config.ExposedPorts}}' 2>/dev/null || true

# Native Linux optional read-only host evidence:
ss -lnt 2>/dev/null || true

# Windows PowerShell equivalent, run separately when useful:
# Get-NetTCPConnection -State Listen

On Docker Desktop, host-side Linux bridge/firewall state lives behind the Desktop backend/VM boundary, so Docker-visible mappings plus host connectivity tests are usually more portable evidence than looking for a native docker0 interface on Windows or macOS.

9. Exposure evidence belongs in the release record

Knowledge check

Official references and version notes

• Docker Docs — Port publishing and mapping — bind addresses, NAT/PAT, direct routing, gateway modes, and default binding behavior.
• Docker Docs — Packet filtering and firewalls — Docker-created firewall rules, iptables/nftables backends, forwarding, firewalld, and UFW interaction.
• Docker Docs — Docker with nftables — experimental Engine 29 nftables backend and migration cautions.
• Docker CLI — docker container run — --publish, --publish-all, host-IP binding, and runtime networking flags.
• Dockerfile reference — EXPOSE — image metadata versus actual host publication.
• Docker Desktop networking — Desktop forwarding architecture, host binding, and firewall integration differences.
• Docker Docs — Host network driver — host namespace semantics and why publish flags do not apply in host mode.
• Docker Engine 29 release notes — Engine 29 networking changes and experimental nftables support.