Re: Passt port forwards to guest when host is "offline"

[David Gibson <david@gibson.dropbear.id.au>]

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

On Wed, May 27, 2026 at 06:51:48PM +0000, Niklas Beierl wrote:
> On 12/05/2026 02:49, David Gibson wrote:
> > On Mon, May 11, 2026 at 12:52:45PM +0000, Niklas Beierl wrote:
> > > On 11/05/2026 13:24, David Gibson wrote:
> > > > On Sun, May 10, 2026 at 01:40:56PM +0000, Niklas Beierl wrote:
> > > > > Hello,
> > > > > 
> > > > > I hope I am not violating any mailinglist etiquette. I am not too
> > > > > familiar
> > > > > with this way of communicating and I haven't found a guide for
> > > > > passts list.
> > > > > Please feel free to point me out.
> > > > > 
> > > > > I have the following Problem: I have a libvirt VM using
> > > > > passt as usermode
> > > > > networking backend. I set up a port-forward to access a service on
> > > > > the VM.
> > > > > In principle, this setup serves me well. There is just one edge-case
> > > > > that is
> > > > > very unergonomic:
> > > > > When the VM boots while the host (laptop) is offline, the VM
> > > > > get's no IP
> > > > > either and the the port-forward doesn't work since passt has no IP to
> > > > > forward to.
> > > > Ok, this is a known problem - or, rather a known cluster of
> > > > overlapping problems. There are some a fair few complications in
> > > > working out exactly how best to address it though, which is why it's
> > > > still there.
> > > > 
> > > > > 35.2917: ERROR:   Flow 0 (INI): No rules to forward HOST TCP
> > > > > [127.0.0.1]:42336 -> [127.0.0.1]:3389
> > > > > 
> > > > > This unfortunately happens quite frequently because I travel a lot.
> > > > > I know
> > > > > this scenario doesn't really have an obvious, well defined solution,
> > > > > because
> > > > > passt is supposed to just make the guest believe it has the same ip
> > > > > as the
> > > > > host and in this case the host has no ip. A few things I
> > > > > have considered:
> > > > > 
> > > > > Assigning an additional, static IP to the guest and somehow forcing
> > > > > traffic
> > > > > for it to passt. Not sure if/how this would work.
> > > > > Assigning an additional, static IP on some host interface, hoping
> > > > > passt will
> > > > > pick it up and advertise it via DHCP?
> > > > > Am I missing a more elegant approach?
> > > > > 
> > > > > I was also thinking that it would perhaps be cool if passt could make
> > > > > port-forwards for localhost connections work irrespective of
> > > > > whether the
> > > > > host otherwise has network connectivity. Haven't thought it
> > > > > 100% through,
> > > > > but if 127.0.0.1/8 is src and dst of the connection, there is no broken
> > > > > return route on the guest or anything so in theory this should be
> > > > > possible I
> > > > > guess? I'd be happy to bounce ideas back and forth.
> > > > > 
> > > > > For reference: The interface definition:
> > > > > 
> > > > >     <interface type='user'>
> > > > >       <mac address='52:54:00:16:63:9f'/>
> > > > >       <portForward proto='tcp'>
> > > > >         <range start='3389'/>
> > > > >       </portForward>
> > > > >       <model type='e1000e'/>
> > > > >       <backend type='passt' logFile='/tmp/win11passt.log'/>
> > > > >       <address type='pci' domain='0x0000' bus='0x01' slot='0x00'
> > > > > function='0x0'/>
> > > > >     </interface>
> > > > So, this isn't really related to port forwarding at all. As long as
> > > > the forward doesn't have a specific listening address (which your
> > > > example doesn't), it should work fine whatever the guest address -
> > > > even if the guest changes address.
> > > > 
> > > > The problem with forwards is just due to not getting an address at
> > > > all. The primary difficulty here is that if the host has no address,
> > > > we have to conjure one out of thin air for the guest. But, if the
> > > > host later goes online, we don't want whatever we picked for the guest
> > > > to conflict with that. Finding a safe choice is quite tricky.
> > > I'd venture to say that RFC3927 link-local addresses
> > > (169.254.0.0/16)  would
> > > be the sanest choice.
> > I came to the same conclusion...
> > 
> > >  Passt already seems to use that as a fallback for
> > > --address but that never triggers on my machine,
> > .. which is why this is the case...
> > 
> > > probably because when
> > > "offline" I still do have ip-addresses from docker bridges but no default
> > > gateway?
> > .. ah. Right. That could explain why "local mode" isn't triggering
> > for you.
> > 
> > Nevertheless link-local addresses still introduce their own
> > complications. The basic question is whether the guest should be able
> > to observe a "link" (in the network sense) between itself and the
> > host. If it can, we can assign link-local addresses, and it simplifies
> > a number of other things. However, historically the approach of
> > passt/pasta has been to give the illusion to the guest that it's
> > sitting in the place of the host, which implies that there not be
> > guest-visible link to the host. We have real use cases that need that
> > to a pretty high level of fidelity. The most obvious real-world
> > consequence is whether the guest can talk to link-local neighbours of
> > the host - or if the host has multiple links *which* link neighbours
> > the guest can talk to.
> > 
> > It's currently an active topic of investigation and debate whether we
> > need explicit different modes (passt-link visible vs. not visible), or
> > whether we can auto-select / auto-switch in some suitable way.
> > 
> > This might seem a bit pedantic in the case of RFC3927 addresses, which
> > are so rarely used. However, the analagous case for IPv6 is pretty
> > routine, and we don't want to introduce inconsistencies if we don't
> > have to.
> > 
> > > > Jon Maloy is currently working on a series of patches that reworks the
> > > > management of guest addresses. The primary aim is to support multiple
> > > > concurrent guest addresses. However, it will also provide a better
> > > > foundation on which to handle the assignment of addresses when we
> > > > can't take one from the host.
> > > Multiple ips would be pretty cool as you could use a link-local
> > > address as
> > > "fallback". :)
> > Right, that's one reason why this series is a good basis or improving
> > our behaviour here.
> > 
> > > > In the meantime there's are some workarounds you could try:
> > > > 
> > > > * What version of passt do you have? Newer versions have "local
> > > > mode". It isn't perfect, but it has at least some ability to
> > > > assign a guest address when the host doesn't have one.
> > > > 
> > > > * If it's not important to you that the guest take the host address
> > > > when the host *is* online, then passt has the ability to explicitly
> > > > assign a guest address. You can use that via libvirt by adding
> > > > lines like:
> > > > <ip address='172.17.2.0' family='ipv4' prefix='24'/>
> > > > <ip address='2001:db8:ac10:fd01::feed' family='ipv6'/>
> > > > to the interface block.
> > > Version: passt 2026_05_07.1afd4ed. What exactly is "local mode" ? I
> > > couldn't
> > > identify something relevant in the man page?
> > Ah, sorry, it's not an explicitly enabled feature. Instead it is
> > fallback to a RFC3927 address which you observed. Older versions
> > would simply fail to start if they couldn't pick an address.
> > 
> > > I tried static IPs but it
> > > seemed to me that when I use that, I also need to statically
> > > configure the
> > > gateway, which makes the whole thing a hassle when I do have
> > > "internet" and
> > > want to use it from the guest.
> > Statically configuring the gateway shouldn't preclude that. We set
> > the guest's gateway to match the host to maintain that illusion of the
> > guest sitting in place of the host. There are some cases where it
> > matters, but for most purposes it's cosmetic. You can set the gateway
> > address to anything (e.g. another RFC3927 address) and the guest
> > should get connectivity, even though that doesn't match the host
> > configuration. passt itself is the only thing that sees where the
> > guest directs the packets at the routing level, and it will make the
> > given address act as a working gateway, whether or not it exists in
> > the outside world.
> > 
> > > For the record, here is my workaround for the moment: I am adding a dummy
> > > (as in type dummy) interface with a private ipv4 range and a default
> > > route
> > > with the lowest possible precedence (high prio). This has the
> > > obvious caveat
> > > that I might encounter a conflict If I ever want to connect to a network
> > > with the chosen CIDR.
> > > 
> > > ip link add dummy0 type dummy
> > > ip link set dummy0 up
> > > ip addr add 192.168.250.5/24 dev dummy0
> > > ip route add default via 192.168.250.1 dev dummy0 metric 4294967295
> > > 
> > > This ensures that there always is at least a faked "local network" on my
> > > machine that provides an address for the guest To persist it with
> > > NetworkManager:
> > > 
> > > nmcli connection add \
> > >   type dummy \
> > >   ifname dummy0 \
> > >   con-name dummy0 \
> > >   ipv4.method manual \
> > >   ipv4.addresses 192.168.250.5/24 \
> > >   ipv4.gateway 192.168.250.1 \
> > >   ipv4.route-metric 4294967295 \
> > >   ipv6.method disabled \
> > >   connection.autoconnect yes
> > That seems like a perfectly cromulent workaround, though statically
> > setting guest address and gateway to RFC3927 addresses might be a bit
> > more elegant.
> 
> I am not sure about the specifics, but it struck me today that perhaps it
> would be for passt to signal a physical medium disconnect to the interface
> in the guest.
> Qmp seems to provide such functionality via set_link
> https://qemu.eu/doc/8.0/interop/qemu-qmp-ref.html#qapidoc-1384, but QMP is
> probably rather unergonomic for passt to interface with. As far as I
> understand, QMP sockets only support one session that is typically occupied
> by someone else (libvirt).

Yeah, an out-of-band means of signalling like that won't really work.

> I don't know if the socket interface for netdev has such functionality?

Alas, it does not.  The socket netdev protocol is *extremely* simple.
It might be possible with the vhost-user backend, which we generally
prefer these days.

> Sounds like something that could perhaps be added tho.

Theoretically, yes, but it's a non-trivial change to a trivial
protocol, so I'm a bit leery of it.

> To tie this to the original problem: passt could offer a mode in which it
> tracks changes in host connectivity, i.e. default route becoming
> (un)available, then signals a medium dis- and re-connect to the guest to
> trigger DHCP.

There are probably easier ways for us to retrigger DHCP.  We can use
explicit DHCPNAKs, or set shorter timeouts than the ones we do now.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]