Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Janne Johansson <icepic.dz@gmail.com>
To: Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: "Daniel Gröber" <dxld@darkboxed.org>,
	"WireGuard mailing list" <wireguard@lists.zx2c4.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: Re: Wireguard address binding - how to fix?
Date: Tue, 21 May 2024 13:11:00 +0200	[thread overview]
Message-ID: <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com> (raw)
In-Reply-To: <87msojhbq0.fsf@ungleich.ch>

Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
<nico.schottelius@ungleich.ch>:
> Hello Jason,
> do you mind applying the patch from Daniel? Or is there anything wrong with it?
>
> Daniel: amazing work, I was not aware that you have already put in the
> hard work, thank you so very much!
>
> The world (*) is suffering because of the lack of IP address binding in wireguard.
>
> (*) With world I refer to every engineer that needs to run wireguard in
> non-trivial situations with multiple IP addresses on one host, which is
> extremely common for anything that routes.

Well, the main reason for wg to NOT do anything special is because
routing generally is done by looking at the destination ip and then
using the routing rules which the kernel uses to tell the packet which
interface is considered "best" in order to reach that ip, which is why
icmp and udp acts like this. I am certain that many engineers
hope/think it would be more logical (or fit their designs better) if
it responded on the same interface as the packet came in or whatever
but the reason for wg to act like it does is because this is how
connection-less packets have been acting since ages. The point that
many engineers design wg endpoints "the wrong way" is probably a fault
of education when it comes to how TCP/IP stacks did and do manage IP
output.

I have zero power to decide anything regarding how wg chooses to
implement a workaround for IP being designed the way it is designed,
but I can at least see why it hasn't immediately been accepted even if
it would make some engineers suffer(*) less, at least in the short
term.

There are a lot of workarounds for the times when you did design the
udp service as if it would act like tcp does in multihomed situations,
which includes firewall tricks, or VRF/namespace/routing-domains to
make sure the inner and outer address-pairs for the wg tunnel see
different views of the network to handle this without changing how wg
sends packets.

-- 
May the most significant bit of your life be positive.

  reply	other threads:[~2024-05-21 11:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-14 10:50 Nico Schottelius
2024-05-14 11:36 ` Daniel Gröber
2024-05-21  7:21   ` Nico Schottelius
2024-05-21 11:11     ` Janne Johansson [this message]
2024-05-21 12:58       ` Nico Schottelius
2024-05-21 14:11         ` Sebastian Hyrvall
2024-05-21 14:34           ` Nico Schottelius
2024-05-26  3:59             ` d tbsky
2024-05-26  8:57               ` Nico Schottelius
2024-06-09 15:39                 ` Nico Schottelius

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=CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com \
    --to=icepic.dz@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=dxld@darkboxed.org \
    --cc=nico.schottelius@ungleich.ch \
    --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).