Support for equivalent to slirp guestfwd

Support for equivalent to slirp guestfwd

[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.

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? If this functionality indeed isn't supported, are
there plans to add it?

Thanks,

Peter Foley

Re: Support for equivalent to slirp guestfwd

[Stefano Brivio]

On Wed, 25 Feb 2026 17:35:06 -0500
Peter Foley <pefoley@google.com> wrote:

> 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.dropbear.id.au/

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.com/

...there's quite a bit left to do, and patches are warmly welcome.

-- 
Stefano