aboutgitcodebugslistschat
path: root/fwd.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2024-08-21 14:20:13 +1000
committerStefano Brivio <sbrivio@redhat.com>2024-08-21 12:00:26 +0200
commit356de97e432e21e8711b94b06a53b1e16dadd913 (patch)
treeebdef8275882e31b7c7059f9f24f08d2a9019d58 /fwd.c
parent4d8dd1fbe789683aea02569e6a00be47693e8913 (diff)
downloadpasst-356de97e432e21e8711b94b06a53b1e16dadd913.tar
passt-356de97e432e21e8711b94b06a53b1e16dadd913.tar.gz
passt-356de97e432e21e8711b94b06a53b1e16dadd913.tar.bz2
passt-356de97e432e21e8711b94b06a53b1e16dadd913.tar.lz
passt-356de97e432e21e8711b94b06a53b1e16dadd913.tar.xz
passt-356de97e432e21e8711b94b06a53b1e16dadd913.tar.zst
passt-356de97e432e21e8711b94b06a53b1e16dadd913.zip
fwd: Split notion of "our tap address" from gateway for IPv4
ip4.gw conflates 3 conceptually different things, which (for now) have the same value: 1. The router/gateway address as seen by the guest 2. An address to NAT to the host with --no-map-gw isn't specified 3. An address to use as source when nothing else makes sense Case 3 occurs in two situations: a) for our DHCP responses - since they come from passt internally there's no naturally meaningful address for them to come from b) for forwarded connections coming from an address that isn't guest accessible (localhost or the guest's own address). (b) occurs even with --no-map-gw, and the expected behaviour of forwarding local connections requires it. For IPv6 role (3) is now taken by ip6.our_tap_ll (which usually has the same value as ip6.gw). For future flexibility we may want to make this "address of last resort" different from the gateway address, so split them logically for IPv4 as well. Specifically, add a new ip4.our_tap_addr field for the address with this role, and initialise it to ip4.gw for now. Unlike IPv6 where we can always get a link-local address, we might not be able to get a (non 0.0.0.0) address here (e.g. if the host is disconnected or only has a point to point link with no gateway address). In that case we have to disable forwarding of inbound connections with guest-inaccessible source addresses. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'fwd.c')
-rw-r--r--fwd.c10
1 files changed, 7 insertions, 3 deletions
diff --git a/fwd.c b/fwd.c
index d6f8a23..664b8ac 100644
--- a/fwd.c
+++ b/fwd.c
@@ -387,10 +387,14 @@ uint8_t fwd_nat_from_host(const struct ctx *c, uint8_t proto,
}
if (!fwd_guest_accessible(c, &ini->eaddr)) {
- if (inany_v4(&ini->eaddr))
- tgt->oaddr = inany_from_v4(c->ip4.gw);
- else
+ if (inany_v4(&ini->eaddr)) {
+ if (IN4_IS_ADDR_UNSPECIFIED(&c->ip4.our_tap_addr))
+ /* No source address we can use */
+ return PIF_NONE;
+ tgt->oaddr = inany_from_v4(c->ip4.our_tap_addr);
+ } else {
tgt->oaddr.a6 = c->ip6.our_tap_ll;
+ }
} else {
tgt->oaddr = ini->eaddr;
}