Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>,
	zrm <zrm@trustiosity.com>, StarBrilliant <coder@poorlab.com>,
	Baptiste Jonglez <baptiste@bitsofnetworks.org>,
	Joe Holden <jwh@zorins.us>,
	Nico Schottelius <nico.schottelius@ungleich.ch>,
	Vasili Pupkin <diggest@gmail.com>,
	peter@fiberdirekt.se
Subject: Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
Date: Mon, 7 Jun 2021 16:13:13 +0500	[thread overview]
Message-ID: <20210607161313.764eb5d6@natsu> (raw)
In-Reply-To: <CAHmME9rj9M=5G6oh+ZKQjekxWFp-5sF4MWux2==2V4X2UtYkag@mail.gmail.com>

On Mon, 7 Jun 2021 11:34:21 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> 2) Local egress fragmentation WOULD be affected by this and is the
> most relevant thing in this discussion. In this case, a packet that
> gets encrypted and winds up being larger than the mtu of the interface
> that the encrypted packet will go out of gets fragmented. In this
> case, we could likely respond with an ICMP packet or similar in-path
> error. But keep in mind this whole situation is local: it usually will
> only happen out of misconfiguration. The best fix for the diagram I
> drew would be for the administrator to decrease the MTU of the
> wireguard interface to 1412.

In the L2 tunneling scenario the large VXLAN packets are generated locally, as
it will be common for the same host (aka "the router") to be both a WG peer
and a VXLAN VTEP, so it is going to be affected.

> So, of those concerned about this, which concerns are actually about
> (2) and (3)? Of those, which ones are about (2)? If you have concerns
> specifically about (2) that couldn't be fixed with reasonable system
> administration, I'd like to hear why and what the setup is that leads
> to that situation.

My described case is being able to transparently bridge two Ethernet LANs.

Hopefully the answer isn't "you don't really need to do that" or "apply
reasonable system administration and set up routing instead".

> As an aside, Roman asked about TTL. When tunneling, the outer packet
> header always must take the new TTL of the route to the tunnel
> endpoint, and not do anything with the potentially much smaller inner
> TTL.

As far as I can see the inner TTL is not smaller than usual on WG tunnels (64).
You could inherit it to the outside of the tunnel, like GRE does:
https://serverfault.com/questions/827239/gre-tunnel-ttl-number
But of course that's leaking a tiny bit of information about the encrypted
tunnel, dunno how critical that would be.

-- 
With respect,
Roman

  reply	other threads:[~2021-06-07 11:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06  9:13 Jason A. Donenfeld
2021-06-06  9:32 ` Nico Schottelius
2021-06-06 10:39 ` Vasili Pupkin
2021-06-06 11:14 ` Peter Linder
2021-06-07 11:58   ` Derek Fawcus
2021-06-06 19:03 ` Roman Mamedov
2021-06-06 22:33   ` Joe Holden
2021-06-07  9:34 ` Jason A. Donenfeld
2021-06-07 11:13   ` Roman Mamedov [this message]
2021-06-07 11:27     ` Jason A. Donenfeld
2021-06-07 11:46       ` Roman Mamedov
2021-06-07 11:55         ` Peter Linder
2021-06-07 18:50         ` Roman Mamedov
2021-06-07 11:18   ` Nico Schottelius
2021-06-09 23:26   ` Vasili Pupkin

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=20210607161313.764eb5d6@natsu \
    --to=rm@romanrm.net \
    --cc=Jason@zx2c4.com \
    --cc=baptiste@bitsofnetworks.org \
    --cc=coder@poorlab.com \
    --cc=diggest@gmail.com \
    --cc=jwh@zorins.us \
    --cc=nico.schottelius@ungleich.ch \
    --cc=peter@fiberdirekt.se \
    --cc=wireguard@lists.zx2c4.com \
    --cc=zrm@trustiosity.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).