FritzBox wireguard MTU = 1392 ipv 1420

[freddie]

Ik was wat aan het pingen naar een andere FritzBox die via WireGuard met mijn FritzBox is verbonden, met de -l (packet size) en -f (don't fragment) flags om te testen welke MTU de FritzBox hanteert. Ik dacht het 1420 zou zijn, maar het blijkt 1392 te zijn. Ik kom namelijk niet verder dan 1364 bytes payload tijdens een ping, + 8 bytes voor de ICMP-header + 20 bytes voor de IPv4-header. Dit komt neer op een MTU van 1392 bytes.

Maar waarom zou de MTU niet 1420 zijn, zoals wikipedia ook aangeeft als de ideale grootte, rekening houdend met de IPv4 en vooral IPv6 header?

Is het mogelijk om dit handmatig aan te passen in de FritzBox?

[Sinna]

Ik vermoed dat ze rekening houden met PPPoE-sessies waar de MTU sowieso al lager is omwille van de overhead van de PPPoE zelf.

[freddie]

Zou idd kunnen maar de PPPoE overhead is toch maar 8 bytes? Waar zijn die extra 20 dan nog voor nodig?

[Sinna]

PPPoE een wilde gok en scheelt inderdaad maar 8 bytes (1492 sounds familiar ). Networks: MTU with DS-Lite and WireGuard (certificaat verlopen maar pagina laadt goed in) lijkt een meer plausibele verklaring te geven:

The new Internet service provider only supports an MTU of 1452 bytes for IPv4 (see "Hint towards the solution" section below) in contrast to 1492 bytes with the previous provider. Such a difference of 40 bytes can either be caused by L2TP used in the provider network or by using DS-Lite between the home router and the Internet service provider. In my case, DS-Lite is in use by the new provider and the smaller MTU only applied to IPv4:

Code: Selecteer alles

Previous provider: 1492 bytes = 1500 bytes (standard Ethernet MTU) - 8 bytes (PPPoE header)
New provider for IPv4: 1452 bytes = 1500 bytes (standard Ethernet MTU) - 8 bytes (PPPoE header) - 40 bytes (IPv6 header for DS-Lite)
New provider for IPv6: 1492 bytes = 1500 bytes (standard Ethernet MTU) - 8 bytes (PPPoE header)

This difference of 40 bytes for IPv4 caused WireGuard packets to become too big with the default MTU (1420 bytes) of the WireGuard interface used for the VPN.

Changing the MTU of the WireGuard interface to 1392 bytes solved the issue. The following calculation explains this value:

Code: Selecteer alles

For IPv4 WireGuard endpoint: WireGuard interface MTU = 1452 bytes (ISP with DS-Lite) - 20 bytes (IPv4 header) - 8 bytes (UDP header) - 32 bytes (WireGuard) = 1392 bytes.
For IPv6 WireGuard endpoint: WireGuard interface MTU = 1492 bytes (ISP using IPv6) - 40 bytes (IPv6 header) - 8 bytes (UDP header) - 32 bytes (WireGuard) = 1412 bytes.

Thus the smaller value (1392 bytes) should be working for both IPv4 and IPv6 WireGuard endpoints.

DS-Lite lijkt dus een (de?) oorzaak te zijn.

[splinterbyte]

Misschien dat de FB deze automatisch goed zet na wat testen te doen?
Ikzelf heb de wireguard client MTU op mijn linux gw op 1384 moeten zetten omdat hoger soms problemen gaf met SMTP, en ik gebruik zelfs geen PPPoE maar gewoon DHCP via Orange coax

[freddie]

Interessant artikel @Sinna. Ik zie ook niet direct een mogelijke andere reden. Ze zullen dan waarschijnlijk rekening houden met mogelijke PPPoE overhead + DS-lite overhead. AVM heeft ook een artikel gepubliceerd over DS-Lite.

Zou eigenlijk manueel moeten in te stellen zijn. Of automatisch worden herkend door d.m.v. Path MTU Discovery.

Ik zal AVM hier misschien eens over contacteren.

Toegevoegd na 5 minuten 35 seconden:

Misschien dat de FB deze automatisch goed zet na wat testen te doen?
Ikzelf heb de wireguard client MTU op mijn linux gw op 1384 moeten zetten omdat hoger soms problemen gaf met SMTP, en ik gebruik zelfs geen PPPoE maar gewoon DHCP via Orange coax

Ik denk het niet. Ik gebruik ook DHCP, via glasvezel. En IPv6 staat hier voorlopig zelfs uit, omdat PXS er nog steeds niet over uit is hoe ze DHCPv6 over shared VLAN gaan toelaten..

Dus moest het automatisch zijn dan zou de MTU op 1440 moeten staan.

[thomasdb]

in de wireguard config zet je de mtu, en de fritz aanvaard deze dan
of bedoelen jullie dat fritz hem ernaweer aanpast
ik heb de mijne verkleind na packet loss en erna was dit gewoon ok?
misschien was het een verkeerde piste gemengd met toeval dan

[freddie]

Ja, maar stel dat je een verbinding opzet tussen 2 fritzboxen dan configureer je ze op de ene en die genereert dan het wg_config bestand voor de andere.

Dus akkoord dat je het voor die laatste kan aanpassen, maar toch niet op degene waar je het eerst configureert?

Zo krijg je ook een asymmetrische opstelling, 1392 bij de ene en bv 1420 bij de andere. Ik weet niet of dit kwaad kan, maar je wilt toch zoveel mogelijk bytes in 1 pakket krijgen om zo min mogelijk bruikbare bandbreedte te verliezen langs beide kanten?

[thomasdb]

bedankt voor de uitleg, ik had over 'thoofd gezien dat het van fritz naar fritz was
ik gebruik deze voornamelijk voor fritz uitgaand naar een vpn provider, (langs vdsl, mobiel, tot voor kort kabel) in die situatie hielp het verkleinen
van fritz naar fritz zelf er nog geen problemen mee gehad
misschien inderdaad omdat ze hem voor de fritz server dan standaard wat kleiner hebben zodat het niet uitmaakt of het over vdsl,mobiel gaat of lan
hoe dit te tweaken aan serverside geen idee, dat er wat snelheid afgaat is voor mij minder erg dan gehaper
als dat al de oorzaak wasvan de packet loss dewelke ik ondervond ik heb er eigenlijk eerlijk geen gedetaileerder kennis van ik experimenteer meestal maar wat
verkeer gaat hier van pc, langs pfsense, naar een fritz met uitgaande wireguard dus welke interface welke mtu moest hebben was wat zoeken
ik ben geeindigd op voor mobiel iets kleiner maar weet eigenlijk niet of het zelf de oorzaak van het probleem was in mijn geval