Re: [PATCH 2/2] conf, fwd: Prefer same-scope address as inbound source address from host

On Thu, Jul 23, 2026 at 01:26:39AM +0200, Stefano Brivio wrote:

We might have situations, such as the one described in https://bugs.passt.top/show_bug.cgi?id=217, where using a link-local address as source in a given namespace doesn't guarantee that we can reach the intended destination, because, for instance, the inbound traffic we forward is in turn forwarded to a different interface, such as a bridge.

In that case, the assumption from 9618d247006a ("ndp, dhcpv6, tcp, udp: Always use link-local as source if gateway isn't") isn't a safe one: the user might have specified a valid gateway address, matching the scope of the destination address, but we won't use it as address of last resort, and prefer a link-local address with a mismatch in scope instead.

This should only be an issue in IPv6 local mode, because, otherwise, we source address and default gateway address (presumably compatible) from the host.

So, in local mode, if the user specifies a given default gateway address for IPv6, note that as 'our_tap_addr', like we would do with with IPv4, and stick to Rule 2 of RFC 6724, Section 5, when selecting a source address, by preferring an address with the same scope, if available.

Reported-by: Paul Holzinger Link: https://bugs.passt.top/show_bug.cgi?id=217 Signed-off-by: Stefano Brivio

Reviewed-by: David Gibson [snip]

diff --git a/fwd.c b/fwd.c index 7152169..4ba0af3 100644 --- a/fwd.c +++ b/fwd.c @@ -1090,7 +1090,11 @@ uint8_t fwd_nat_from_host(const struct ctx *c, return PIF_NONE; tgt->oaddr = inany_from_v4(c->ip4.our_tap_addr); } else { - tgt->oaddr.a6 = c->ip6.our_tap_ll; + if (inany_is_linklocal6(&tgt->eaddr) ||

Just to make sure you're aware: this will only trigger if tgt->eaddr has been set at this point, which is not always the case. In fact it will usually only be the case when the rule specifies a target address. In other cases we pick tgt->oaddr first then pick tgt->eaddr's scope to try to match it. I think the fact that the order in which we pick eaddr and oaddr varies is pretty confusing, but I haven't so far seen a way to avoid it without breaking something worse. I still think this change is correct: not previously having ip6.our_tap_addr was only possible because we did this odd dance to pick eaddr based on oaddr's scope rather than the other way around.

+ IN6_IS_ADDR_UNSPECIFIED(&c->ip6.our_tap_addr)) + tgt->oaddr.a6 = c->ip6.our_tap_ll; + else + tgt->oaddr.a6 = c->ip6.our_tap_addr; } } tgt->oport = ini->eport; diff --git a/passt.h b/passt.h index a61baca..51ccd4f 100644 --- a/passt.h +++ b/passt.h @@ -121,6 +121,7 @@ struct ip4_ctx { * @dns: DNS addresses for DHCPv6 and NDP * @dns_match: Forward DNS query if sent to this address * @our_tap_ll: Link-local IPv6 address for passt's use on tap + * @our_tap_addr: Non-LL IPv6 address for passt's use on tap (if any) * @dns_host: Use this DNS on the host for forwarding * @addr_out: Optional source address for outbound traffic * @ifname_out: Optional interface name to bind outbound sockets to @@ -140,6 +141,7 @@ struct ip6_ctx { struct in6_addr dns[MAXNS]; struct in6_addr dns_match; struct in6_addr our_tap_ll; + struct in6_addr our_tap_addr;

/* PIF_HOST addresses */ struct in6_addr dns_host; -- 2.43.0

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