Es geht nicht darum, einen MTU-Wert zu erhöhen ... der wird durch die maximale Größe der auf dem Transportweg zu übertragenden Daten (die physikalische Größe, die max. möglich ist) abzüglich des Overheads durch ALLE zur Kapselung von (Nutz-)Daten verwendeten Protokolle VORGEGEBEN.
Es geht also eher darum, die MTU-Size (beim Zerlegen der zu sendenden Daten durch den WG-Treiber auf der Sender-Seite) so zu VERRINGERN, daß die in einem Paket versendeten (Nutz-)Daten auf allen Zwischenstationen des Wegs zum Empfänger (das geht beim lokalen "Verpacken" los und endet erst wieder beim "Entpacken" "Auspacken" auf der Gegenseite) KOMPLETT übertragen werden können, damit auf der Empfängerseite auch immer komplette (WireGuard-)Pakete ankommen, aus denen der WG-Treiber dann - nach Authentizitätsprüfung, daß da niemand "an den Daten herumgefummelt" hat (tamper with sth.) - die zu übertragenden Daten wieder rekonstruieren kann.
Ich habe auch keine Ahnung, wie sich AVM das vorstellt bei der finalen Version ... üblicherweise gibt es für die Feststellung des max. möglichen Wertes (das nennt sich dann "Path MTU Discovery") einen Standard - nur ist der darauf angewiesen, daß auf allen Zwischenstationen auch die üblichen Signalisierungen funktionieren, mit denen dem Absender dann mitgeteilt werden kann, an welchem "hop" auf dem Weg eines Pakets ein Problem aufgetreten ist (und welches das war). Das funktioniert dann bei VPN-Verbindungen (davon ist ja auch nicht nur WireGuard betroffen) gerne mal nicht und deshalb gibt es bei solchen Lösungen üblicherweise immer eine Möglichkeit, einen passenden Wert manuell einzustellen.
Bei der IPv6-Konfiguration (für das WAN-Interface bzw. dev dsl) kann man im FRITZ!OS ja einen abweichenden MTU-Wert festlegen, wobei die von AVM als Standard vorgeschlagenen 1280 Bytes eigentlich dazu führen sollten, daß man bei (fast) allen Unwägbarkeiten des IPv6-Protokolls (z.B. ist dort die Größe der (IPv6-)Header nicht "fix" festgelegt und kann variieren) zurecht kommen kann.
Ob und wie genau sich eine dort vorgenommene Änderung (die ja bei AVM per se erst mal nur im kdsldmod Auswirkungen hat, wie man sich (bei Shell-Zugriff) mit showdsldstat ansehen kann ... ansonsten findet man das auch in den Supportdaten) jetzt auch automatisch (nach zusätzlicher "Berechnung") auf das konfigurierte WireGuard-Interface auswirkt (auch das sollte sich als wgX in den Supportdaten finden lassen), weiß ich auch nicht (bzw. habe ich noch nie versucht zu ergründen, solange AVM WG noch nicht "offiziell" freigegeben hat) - aber vielleicht ist auch das noch einen Versuch wert und wenn man die IPv6-MTU mit dem vorgegebenen Wert "überschreibt" (dazu muß man nur die Checkbox aktivieren, dann bleibt es bei den 1280 Bytes), dann KÖNNTE es auch sein, daß die MTU auch für WG (und natürlich ebenso für ALLEN anderen Traffic, daher ist das schon mit einem (eher geringen) Verlust an Transfer-Kapazität verbunden) entsprechend verringert wird.
Bei aktivierter WG-Verbindung sollte man auch dazu etwas in den Supportdaten finden können - vorausgesetzt AVM gibt dort auch immer noch die Übersicht der Interfaces (das Ergebnis von ip addr show) aus (was ich jetzt nicht recherchieren oder testen will/werde).
Sollte es dann mit reduzierter MTU-Size doch irgendwann mal (alles) funktionieren, kann man sich - wenn man nicht generell mit der 10% niedrigeren Paketgröße leben kann/will, wobei der Effekt von den meisten stark überschätzt wird - auch wieder an größere Werte "herantasten", bis man den max. möglichen Wert gefunden hat (das hängt eben immer davon ab, was ZWISCHEN den beiden Anschlüssen alles passiert und das KANN sogar wechseln - z.B. beim Mobilfunk-Backup für eine unterbrochene DSL-Verbindung).
