Rootless Podman has a long-standing limitation reported since 2020: containers on bridge networks can’t see the real source IP of incoming connections. The `rootlessport` userspace proxy rewrites the source to the container’s own subnet address, breaking IP-based access control, logging, and rate limiting.

Pesto, a new companion tool from the passt project solves this. Pesto dynamically updates pasta’s forwarding table, telling pasta which ports to forward and where. Unlike `rootlessport`, pasta forwards traffic without rewriting the source address, so the original client IP is preserved all the way to the container.

How It Works

Enable it with one line in containers.conf:

[network]
rootless_port_forwarder = “pasta”

After changing this setting, stop all running rootless containers (podman stop --all` so the old pasta process (without the pesto control socket) is terminated and the rootless network namespace is recreated on the next container start.

The traffic path is: Client -> host:port -> pasta -> rootless netns -> netavark bridge -> container

A shared pasta process runs on the host and manages the rootless network namespace via a TAP device, with a control socket (-c pasta.sock) for pesto. On container start, netavark sets up the bridge and nftables rules, then pesto adds port forwarding entries to pasta’s table via pesto --add. On container stop, pesto --delete removes the entries and netavark tears down the bridge. Network connect, disconnect, and reload update the forwarding state accordingly.

All existing port mapping features (different host/container ports, per-HostIP binding, dual-stack, port reuse after stop) continue to work as before.

Known Limitations

• Not the default (yet): switching the default from rootlessport to pasta is a breaking change. rootlessport transparently forwards IPv6 host traffic to IPv4 inside the container, so services that only bind IPv4 or use an IPv4-only network can still receive IPv6 connections. With pasta, the container needs a proper dual-stack network and the service must bind IPv6 explicitly. While this is unlikely to affect many users, some may depend on it implicitly.
• No graceful upgrade path: if you change the default while containers are running, teardown won’t know they were started with a different forwarder. Network connect/disconnect on existing containers may also misbehave. To switch cleanly, stop all containers first, then change the setting and start them again (or simply reboot).

References

• #8193: Original feature request (Oct 2020)
• #28478: Initial implementation
• #29242: Target address mapping, IPv6, per-HostIP routing
• container-libs#755, container-libs#1004: Library work
• passt.top: pasta and pesto (requires ≥ `passt-0^20260507.g1afd4ed`)