From: tlhackque <tlhackque@yahoo.com>
To: Roman Mamedov <rm@romanrm.net>,
Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Source IP incorrect on multi homed systems
Date: Sun, 19 Feb 2023 16:39:53 -0500 [thread overview]
Message-ID: <7d5c1dd6-fded-37bb-2ac1-d8dc541a822e@yahoo.com> (raw)
In-Reply-To: <20230220014252.21178988@nvm>
[-- Attachment #1.1: Type: text/plain, Size: 2964 bytes --]
On 19-Feb-23 15:42, Roman Mamedov wrote:
> On Sun, 19 Feb 2023 21:18:34 +0100
> Nico Schottelius<nico.schottelius@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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2023-02-19 21:40 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 20:14 Nico Schottelius
[not found] ` <CAHx9msc1cNV80YU7HRmQ9gsjSEiVZ=pb31aYqfP62hy8DeuGZA@mail.gmail.com>
2023-02-18 22:34 ` Nico Schottelius
2023-02-19 0:45 ` Mike O'Connor
2023-02-19 8:01 ` Nico Schottelius
2023-02-19 9:19 ` Mikma
2023-02-19 12:04 ` Nico Schottelius
2023-02-19 12:10 ` Nico Schottelius
2023-02-19 18:59 ` Peter Linder
[not found] ` <2ed829aaed9fec59ac2a9b32c4ce0a9005b8d8b850be81c81a226791855fe4eb@mu.id>
2023-02-19 12:13 ` Nico Schottelius
2023-02-19 14:39 ` Christoph Loesch
2023-02-19 16:32 ` David Kerr
2023-02-19 16:54 ` Sebastian Hyrvall
2023-02-19 18:04 ` Janne Johansson
2023-02-19 18:08 ` Sebastian Hyrvall
2023-02-19 20:11 ` Nico Schottelius
2023-02-19 17:05 ` tlhackque
[not found] ` <CADGd2DoE6TCtCxxWL7JWyNW5+yy_Pe+9MNzHznbudMWLTXQreA@mail.gmail.com>
2023-02-19 18:30 ` Fwd: " John Lauro
2023-02-19 22:28 ` tlhackque
2023-02-20 0:58 ` Luiz Angelo Daros de Luca
2023-02-19 18:37 ` David Kerr
2023-02-19 18:52 ` tlhackque
2023-02-19 18:42 ` tlhackque
2023-02-19 20:18 ` Nico Schottelius
2023-02-19 20:42 ` Roman Mamedov
2023-02-19 21:19 ` Nico Schottelius
2023-02-19 22:06 ` tlhackque
2023-02-19 22:42 ` Src addr code review (Was: Source IP incorrect on multi homed systems) Daniel Gröber
2023-02-20 0:28 ` 曹煜
2023-02-20 10:40 ` Nico Schottelius
2023-02-20 11:21 ` 曹煜
2023-02-20 9:47 ` Nico Schottelius
2023-02-20 20:43 ` dxld
2023-02-19 21:39 ` tlhackque [this message]
2023-02-19 20:02 ` Source IP incorrect on multi homed systems Nico Schottelius
2023-02-20 11:09 Janne Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d5c1dd6-fded-37bb-2ac1-d8dc541a822e@yahoo.com \
--to=tlhackque@yahoo.com \
--cc=nico.schottelius@ungleich.ch \
--cc=rm@romanrm.net \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).