All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Küthe" <m-k-mailling-list@mk16.de>
To: wireguard@lists.zx2c4.com
Cc: luizluca@gmail.com
Subject: Re: IPv6 and PPPoE with MSSFIX
Date: Wed, 23 Aug 2023 16:58:40 +0200	[thread overview]
Message-ID: <20230823165840.7bf3b910@parrot> (raw)
In-Reply-To: <CAJq09z6Dz3idziDgB-3-VOVa=YEWk6ZOrLOwLTBctRb5VkLMLA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Tue, 22 Aug 2023 17:39:23 -0300
Luiz Angelo Daros de Luca <luizluca@gmail.com> wrote:

> Hello,
> 
> We noticed an issue with clients that use PPPoE and connect to WG
> using IPv6. Both sides start to fragment the encrypted packet leading
> to a severe degradation in performance. We reduced the wireguard MTU
> from the default 1420 to 1400 and the issue was solved. However, I
> wonder if it could be fixed with MSSFIX (in my case, nftables
> equivalent).

PPPoE adds 8 bytes of overhead so that an MTU of 1432 can be used. I
also have to do this at home with my DSL line for example.
The MTU should be set on each side (on both peers) for this to work.

> The server does know that the remote address has a smaller MTU as it
> fragments the packet accordingly when any VPN peer sends some traffic.

Presumably the OS on the server does this and not WireGuard itself. I
could imagine that the server first receives an ICMP Too big message
and only then performs the fragmentation.

> The traffic inside the VPN does adjust the TCP MSS to fit into vpn
> interface MTU (1420 by default, now 1400).

Keep in mind that TCP MSSFIX only applies to TCP and other Layer 4
protocols like UDP might still have problems.

> I could dynamically add firewall rules to clamp MSS per authorized_ips
> but, theoretically, the kernel has all the info to do that
> automatically. I wonder if MSSFIX could detect the best MTU for a
> specific address through the wireguard. It should consider the
> peer-to-peer PMTU, the IP protocol wireguard is using and the normal
> wireguard headers.

As far as I know WireGuard does not do PMTU.

-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-08-23 16:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 20:39 IPv6 and PPPoE with MSSFIX Luiz Angelo Daros de Luca
2023-08-23 14:58 ` Marek Küthe [this message]
2023-08-23 17:14   ` Daniel Gröber
2023-08-23 19:01     ` Luiz Angelo Daros de Luca
2023-08-23 20:47       ` Hugo Slabbert
2023-08-28 22:22         ` Luiz Angelo Daros de Luca
2023-08-23 17:07 ` Daniel Gröber
2023-08-23 19:55   ` Luiz Angelo Daros de Luca

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=20230823165840.7bf3b910@parrot \
    --to=m-k-mailling-list@mk16.de \
    --cc=luizluca@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.