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

Re: Support for equivalent to slirp guestfwd

[Peter Foley]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

On Thu, Feb 26, 2026 at 7:47 AM Stefano Brivio <sbrivio@redhat.com> wrote:

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

Alright, that's about what I expected.

We currently heavily rely on stuff
like guestfwd=udp:[::]:1000-udp:[::1]:14418,
where we want to redirect all outbound traffic from the guest to port 1000
to a different dynamically allocated port where a server binary is
listening on the host.

We don't need runtime configuration, just the ability to specify everything
statically when starting qemu.

I can't promise anything, but I'll see if this is something other people on
my team would have cycles to help out with.

Thanks,

Peter Foley

[-- Attachment #2: Type: text/html, Size: 2289 bytes --]

Re: Support for equivalent to slirp guestfwd

[Stefano Brivio]

On Thu, 26 Feb 2026 11:31:15 -0500
Peter Foley <pefoley@google.com> wrote:

> On Thu, Feb 26, 2026 at 7:47 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > ...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.
> 
> Alright, that's about what I expected.
> 
> We currently heavily rely on stuff
> like guestfwd=udp:[::]:1000-udp:[::1]:14418,
> where we want to redirect all outbound traffic from the guest to port 1000
> to a different dynamically allocated port where a server binary is
> listening on the host.

Hah, I see.

Somewhat curiously, that's the first time I see this kind of usage being
reported. I knew libslirp could do it but I wasn't aware of any
concrete usage.

> We don't need runtime configuration, just the ability to specify everything
> statically when starting qemu.

That will come pretty much for free once we have generic code for the
runtime updates, I think.

> I can't promise anything, but I'll see if this is something other people on
> my team would have cycles to help out with.

Thanks!

-- 
Stefano