Passt port forwards to guest when host is "offline"
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. 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> Best Niklas
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. 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. 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. -- 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
On Mon, 11 May 2026 21:24:42 +1000
David Gibson
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.
See also: https://bugs.passt.top/show_bug.cgi?id=141 https://pad.passt.top/p/netlinkMonitor if you want to track progress / see more details about that. -- Stefano
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
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. -- 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
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!
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
participants (3)
-
David Gibson
-
Niklas Beierl
-
Stefano Brivio