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

[Niklas Beierl <no.shoes@posteo.net>]

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

I don't know if the socket interface for netdev has such functionality? 
Sounds like something that could perhaps be added tho.

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.

Cheers!