Re: Support for equivalent to slirp guestfwd

[Stefano Brivio <sbrivio@redhat.com>]

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