Podman Networking: Bridge, Host, and Slirp4netns (2026)

Podman’s default networking is actually a lot smarter and more secure than you probably think.

Let’s see it in action. Imagine we’re running a simple web server in a container.

First, we need a container image with a web server. We can use docker.io/library/nginx.

podman run -d --name my-nginx -p 8080:80 docker.io/library/nginx

This command starts an Nginx container in detached mode (-d), names it my-nginx, and maps port 8080 on your host machine to port 80 inside the container (-p 8080:80).

Now, let’s check where this container is actually listening.

podman port my-nginx

This will output something like:

80/tcp -> 0.0.0.0:8080

This shows that port 80 inside the container is accessible on all network interfaces (0.0.0.0) of your host machine, specifically on port 8080. You can now open http://localhost:8080 in your browser and see the default Nginx welcome page.

This is Podman’s default networking mode, which uses slirp4netns. It’s a user-mode network stack that runs entirely in userspace, providing a NAT-like environment for the container. This is crucial because it means your container doesn’t get its own IP address on your host’s network by default. Instead, Podman (via slirp4netns) acts as a router and firewall for the container.

Here’s how it builds the mental model:

The Problem: Running containers often means isolating them from your host network for security. You also need a way for the container to access external services and for you to access services running inside the container.
slirp4netns (Default): This is the magic behind Podman’s default networking. When you run podman run ... without specifying a network, slirp4netns is invoked.
- No Host IP: The container doesn’t get an IP address on your physical network. This prevents direct access to the container from other machines on your network.
- NAT-like Behavior: slirp4netns creates a virtual network interface for the container. It then intercepts outgoing traffic from the container, translates its source IP and port (a process called Network Address Translation or NAT), and forwards it to the host. Incoming traffic is also managed by slirp4netns, directing it to the correct container based on port mappings.
- Port Mapping (-p): The -p HOST_PORT:CONTAINER_PORT flag tells slirp4netns to forward traffic arriving at HOST_PORT on your host to CONTAINER_PORT inside the container.
- Security: Because the container doesn’t have a direct IP, it can’t be directly attacked from the external network. All communication is mediated by slirp4netns.
podman network create: You can create and manage your own networks using podman network.
- bridge Network: This is a more traditional container networking approach. When you create a bridge network (podman network create my-bridge), Podman sets up a virtual Ethernet bridge on your host. Containers attached to this bridge network get their own IP addresses on a private subnet managed by Podman (e.g., 10.88.0.0/24).
```
podman network create my-bridge
podman run -d --name my-bridge-nginx --network my-bridge -p 8081:80 docker.io/library/nginx
```
  Now, if you inspect the my-bridge-nginx container, you’ll see an IP address assigned to it within the my-bridge network. You can also use podman exec my-bridge-nginx ip addr to see its internal IP.
  - Why it works: The bridge acts like a virtual switch. Podman manages a DHCP server for this virtual network, assigning IPs to containers. Your host machine acts as the gateway for this bridge network.
- host Network: This is the least isolated mode. When you run a container with --network host, the container shares the network namespace of your host machine.
```
podman run -d --name my-host-nginx --network host docker.io/library/nginx
```
  In this mode, the container directly uses your host’s IP address. If you expose port 80 on the container, it will bind to port 80 on your host, potentially conflicting with other services. You don’t use -p with --network host because the container is directly on the host’s network.
  - Why it works: It bypasses all network isolation. The container’s network interfaces are the same as the host’s. This offers maximum performance but minimal security and isolation.

The key takeaway is that slirp4netns provides a secure, NAT-like experience by default, without requiring you to explicitly manage network configurations for simple use cases. Bridge networks offer more control and a traditional container networking model, while host networking sacrifices isolation for performance.

When you try to access a service on a container using slirp4netns and get a connection refused error, even though you mapped the port, it’s often because the service inside the container isn’t actually listening on 0.0.0.0 or :: (all interfaces) but on 127.0.0.1 (localhost) within its own network namespace.

The next step is understanding how to manage DNS resolution within these different network modes.