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

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

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. Passt already seems to use that as a 
fallback for --address but that never triggers on my machine, probably 
because when "offline" I still do have ip-addresses from docker bridges 
but no default gateway?

> 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". :)
> 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? 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.

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