On Wed, 25 Feb 2026 17:35:06 -0500
Peter Foley
Hi,
I'm investigating migrating Google-internal uses of qemu's slirp-based networking to passt. One major gap I've discovered is the apparent lack of support in passt for something like the "guestfwd" flag the slirp network backend handles: https://www.qemu.org/docs/master/system/invocation.html This allows us to open outbound connections from the VM to an external service listening on a known port.
I think libslirp's "guestfwd", strictly speaking, is only needed if you want to map ports to a character device or standard streams of a process that's started upon outbound connections (neither one is your case I guess). In all other cases, you could, with both libslirp and passt, connect from the VM to a local (non-loopback) address configured on the host, to reach other services running there. But I guess you want specific addressing (both for source and destination), so:
As far as I can tell, passt's tcp-ports and udp-ports flags appear to map to slirp's hostfwd flags, only allowing traffic to flow into the VM.
Am I missing something?
...yes, the --map-guest-addr and --map-host-loopback options. By default, connections from the VM to the address of the default gateway shown to the guest (a somewhat arbitrary choice that was convenient for KubeVirt's usage) are mapped to the host, with loopback source, see the "Handling of traffic with loopback destination and source addresses" note in the man page. You can change this address using --map-host-loopback. With it, the traffic will still appear as coming from the host's loopback. Or you can use specify an address with --map-guest-addr, and outbound connections will be seen on the host as coming from a local, but non-loopback address. The current description in the man page might be a bit confusing, see also https://bugs.passt.top/show_bug.cgi?id=132. This takes care of the first part of 'guestfwd', that is, instead of "guestfwd=tcp:10.0.2.100:1234-..." you would simply use --map-guest-addr 10.0.2.100. For the second part of it:
If this functionality indeed isn't supported, are there plans to add it?
...there's ongoing effort to make this more flexible, by adding support for generic NAT rules (https://bugs.passt.top/show_bug.cgi?id=140) so that you can specifically map different ports and addresses to specific ports and addresses. And do so dynamically, at runtime, too. We now have a rather generic "forwarding rules" table implementation, even if not entirely complete: https://archives.passt.top/passt-dev/20260116005926.616085-1-david@gibson.dr... and a very rudimentary draft of pesto(1), the client that would enable configuring all that at runtime (I'm working on it these days): https://archives.passt.top/passt-dev/20260204234209.455262-1-sbrivio@redhat.... ...there's quite a bit left to do, and patches are warmly welcome. -- Stefano