Source IP incorrect on multi homed systems

[tlhackque]

On 19-Feb-23 15:42, Roman Mamedov wrote:
> On Sun, 19 Feb 2023 21:18:34 +0100
> Nico Schottelius<nico.schottelius at ungleich.ch>  wrote:
>
>> If I am not mistaken that would mean in practice:
>>
>>     if orignal_pkg.ip_dst == one_of_my_ips then
>>        return_pkg.ip.src = orignal_pkg.ip_dst
>>        return_pkg.ip.dst = orignal_pkg.ip_src
>>     fi
>>
>> For me that sounds like a sane approach (aside from
>> my very simplified algorithm).
> Except there is no request and response in WG, and as such no original or
> return packet. Another peer contacts you, then some time later you contact the
> other peer. Or the other way round.
>
> WG-wise what will need to be done is to store in the each peer's information
> structure the local IP that we are supposed to use for communication with that
> peer; and updating it when receiving packets from the peer, using the
> destination of those. So you would see a "Local IP" in each "peer" section
> when doing a "wg show".
>
> Also, until there is such IP initially stored, it will have to be some default
> outgoing IP of the system towards that peer. BTW, how would this work in your
> setup, what if not the peer contacts you first, but your machine needs to
> contact the peer?
>
The situation can be (and often is) the same for both peers.

If you're the initiator, you send to the peer address using its 
configured or DNS IP address, and normal routing.  You note the address 
used to send, and use it for future communications to that peer.  The 
first packet sets state in the posited firewall/nat. Subsequent packets 
using the same source address ensures that the firewall sees them as the 
same flow.

When the peer gets around to saying something - which it will at latest 
when the keepalive timer goes off, but probably sooner, it will have 
noted your source address and it's local IP address (the one you used).  
So it will send using the source address that you know about.

This is the same algorithm used by the peer, so they should agree.

When either end detects and address change, the process restarts.

There is a possibility that the initial packets pass in flight, but I 
think that would at most result in a dropped packet, which will be resent.

I don't think there's a deadlock, but in the event of thrashing, a 
tie-breaker of using the lowest candidate IP address generally works..

When there are multiple choices, it doesn't really matter which pair of 
IP addresses are picked, as long as they're stable while the systems 
reside on the same networks.  (E.G. it could be two notebook PCs in 
different hotel rooms, not just two fixed servers or one fixed server 
and one mobile.)  The goal is to establish a flow that stateful packet 
inspection, NAT, routing can recognize and use to keep a pinhole open...

I don't have time at the moment to work out the corner cases, but that's 
the overall approach.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20230219/50ac3a14/attachment.sig>