Podman Networking: A Comprehensive Guide (3/5)

Containerization has changed how we build and ship software, and Podman has earned its place as a daemonless, rootless-first alternative to Docker. But none of that matters if your containers can’t talk to each other — or to the outside world.

This part of the series breaks down how Podman networking actually works, with corrected, tested commands you can copy and run directly.

Podman Networking Basics

Podman manages container networking through pluggable backends — Netavark (default since Podman 4.0) handles bridge, macvlan, and ipvlan networking, while rootless containers without root privileges typically use pasta (default since Podman 4.4) or slirp4netns for user-mode networking.

Important distinction often glossed over: the default behavior depends on how you run Podman:

Mode Default networking Bridge interface Rootful (sudo podman / root user) Default podman bridge network podman0, subnet 10.88.0.0/16 Rootless (regular user) pasta (or slirp4netns) No host-visible bridge

This matters because several “default” behaviors — like containers getting a visible IP via NetworkSettings.IPAddress — only apply cleanly in rootful mode.

1. Creating a Container with Default Networking

podman run -d --name my_container nginx

This launches an Nginx container named my_container. If you're running rootful, it attaches to the default podman bridge. If rootless, it uses pasta/slirp4netns automatically — no manual setup required either way.

2. Inspecting Container Network Details

The classic format only works reliably in rootful mode with the default bridge:

podman inspect --format='{{.NetworkSettings.IPAddress}}' my_container

For custom networks (or to be safe in any mode), use the .Networks map instead — this is the format that actually works consistently across setups:

podman inspect my_container --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

⚠️ Rootless note: if the output is empty, that’s expected. Rootless containers without a custom network often don’t get a traditional routable IP. Use port mapping (-p) to reach them from the host instead.

Customizing Podman Networking

1. Creating a Custom Bridge Network

podman network create --driver bridge my_bridge_network

bridge is already the default driver, so you can drop the flag entirely:

podman network create my_bridge_network

Custom networks come with a real benefit over the default bridge: automatic DNS resolution between containers by name — something the default podman network doesn't provide.

2. Connecting Containers to a Custom Network

podman run -d --name my_container --network my_bridge_network nginx

Spin up a second container on the same network and you get name-based resolution for free:

podman run -d --name client_container --network my_bridge_network alpine sleep 3600
podman exec client_container ping -c 3 my_container

3. Inspecting Custom Networks

podman network inspect my_bridge_network

Returns subnet, gateway, connected containers, and DNS settings as JSON.

4. Defining Subnet and Gateway Explicitly

For production setups, don’t let Podman auto-assign a subnet — define it:

podman network create \
  --subnet 10.89.0.0/24 \
  --gateway 10.89.0.1 \
  app_network

5. Exposing Container Ports

podman run -d --name my_container -p 8080:80 nginx

Maps host port 8080 to container port 80. This works identically in rootful and rootless mode, though rootless containers can't bind to privileged host ports (<1024) without extra configuration (net.ipv4.ip_unprivileged_port_start or --cap-add=NET_BIND_SERVICE).

6. Host Networking

podman run -d --name my_container --network host nginx

The container shares the host’s network namespace entirely — no isolation, no port mapping needed, but also no separation from host services. Use sparingly and only when you understand the security trade-off.

Quick Troubleshooting Toolkit

When container-to-container communication breaks, this is the fastest path to a diagnosis:

# List all networks
podman network ls

# Confirm which containers are on a network
podman network inspect my_bridge_network

# Test connectivity by name (only works on custom networks, not default bridge)
podman exec container_a ping -c 1 container_b

# Test connectivity by IP
podman exec container_a ping -c 1 <container_b_ip>

# Check the network backend in use
podman info --format '{{.Host.NetworkBackend}}'

Conclusion

Podman’s networking model gives you the same flexibility you’d expect from Docker — bridge networks, custom subnets, port mapping, host networking — but with rootless operation as a first-class citizen rather than an afterthought. The key thing to internalize: rootful and rootless containers behave differently by default, and most networking confusion traces back to that distinction rather than to Podman itself.

Custom bridge networks with built-in DNS resolution should be your default choice for any multi-container setup — they’re easier to debug and far more production-realistic than relying on the default podman bridge.

Further reading:

1. Configuring container networking with Podman — Red Hat Enable Sysadmin
2. Podman Network documentation