From nobody Mon Apr 4 07:27:02 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9DEC81A5B31B for ; Mon, 4 Apr 2022 07:27:11 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from mail.punkt.de (mail.punkt.de [217.29.41.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KX2R25HDYz4fl6 for ; Mon, 4 Apr 2022 07:27:10 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from smtpclient.apple (unknown [IPv6:2a00:b580:a000:0:cd79:4e8e:1493:a91c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.punkt.de (Postfix) with ESMTPSA id C26D224354; Mon, 4 Apr 2022 09:27:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: Wireguard, MTUs, and jumbo packets From: "Patrick M. Hausen" In-Reply-To: <202204040337.VAA10654@mail.lariat.net> Date: Mon, 4 Apr 2022 09:27:02 +0200 Cc: "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202204040337.VAA10654@mail.lariat.net> To: freebsd-net@brettglass.com X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KX2R25HDYz4fl6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.41.227 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[punkt.de]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi all, > Am 04.04.2022 um 05:37 schrieb freebsd-net@brettglass.com: > Would like to use the new Wireguard implementation, but need to know = what it does to MTUs. I'd like a full 1500 byte MTU through the VPN = tunnel, but this means that the packets that are sent between the client = and server have to be BIGGER than 1500 bytes. >=20 > It takes a special feature to allow PPPoE to negotiate a larger MTU = (see RFC 4638), and other PPP-based protocols such as L2TP wont do it at = all. But what happens in Wireguard? I can find no documentation on this = topic, so assistance would be appreciated. as far as I know WireGuard does not care about interface or PMTU nor perform PMTUd. You can set the WG interface MTU in the = configuration, e.g. [Interface] PrivateKey =3D ************** Address =3D [...] DNS =3D [...] MTU =3D 1280 Wether your path will be capable of transporting packets with a tunnel = MTU of 1500 is left for you to take care of - outside of WG. WireGuard overhead is 60 bytes for IPv4 transport and 80 bytes for IPv6. HTH, Patrick --=20 punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Gesch=C3=A4ftsf=C3=BChrer: J=C3=BCrgen Egeling, Daniel Lienert, Fabian = Stein