Source IP incorrect on multi homed systems
Nico Schottelius
nico.schottelius at ungleich.ch
Sun Feb 19 21:19:23 UTC 2023
Hey Roman,
Roman Mamedov <rm at romanrm.net> writes:
> 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".
That is very interesting, thanks for the insight. Reading above
paragraph, I was having a very similar thought that we need to record
the local IP.
> 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?
So far this situation doesn't exist for us, because only servers are
multi homed.
However, having an option to specify something a local address in each peer
section would probably be a good solution to disambiguate it and if not
specified, use the default, as in whatever other processes are using
that don't define it explicitly - i.e. follow the process of least
surprise.
Best regards,
Nico
--
Sustainable and modern Infrastructures by ungleich.ch
More information about the WireGuard
mailing list