Geen VPN (forticlient) via hotspot op iPhone 16 pro

1. nogmaals die tests zeggen niks aangezien ze niet over het netwerk van KPN gaan, de interface van het toestel wat ik gebruikt heb heeft helemaal geen grens op 1500. maar is ook vanaf een andere host niet te pingen met een hogere MTU. wie zegt dat die pings niet over een lokaal netwerk zijn gedaan en daarna dit uit is gezet en een screenshot is  gemaakt.
2. als je daadwerkelijk die instelling had had je voor onderzoeksdoeleinden een geraakt toestel geroot.
3. daar denkt de ipv6 standaard echt anders over. de max moet met path mtu discovery vast worden gesteld. dat een limiet op een telefoon van 1500 problemen kan voorkomen is daarbij meer geluk als wijsheid. het is niet conform de standaard en daarom op vele nieuwe toestellen niet meer aanwezig.
4. zodra je roamed in het buitenland werkt het wel. die conclusie hadden we vorrige week al. issue zit dus echt op een interface binnen KPN.

Logisch dat jouw IPv6 vanaf een andere host niet te pingen is met een MTU size groter dan 1500 maar dat zegt niets over een limiet op de interface van de telefoon zelf, die limiet zit ergens in het netwerk tussen die andere host en jouw telefoon. Het is nu juist die Path MTU discovery die vast moet stellen wat de kleinste MTU op het gehele pad is en je kunt er donder op zeggen dat je in vrijwel alle gevallen tot een waarde van 1500 bytes zult komen. Niet omdat de interface van de telefoon dat oplegt maar omdat er ergens in het netwerk een node zit die een MTU van 1500 bytes ingesteld heeft staan.

Die pings uit die checks van ​@TDN en ​@Neville zijn juist met opzet lokaal zodat de MTU size enkel de MTU size van de eigen interface van toepassing is en niet de MTU van een andere node op het 5G netwerk. Als jij vanaf jouw telefoon ook eens jouw eigen IPv6 adres zou pingen met een packet size van 2000 bytes dan zal je zien dat je gewoon response krijgt omdat jouw eigen telefoon geen limiet kent t.a.v. de MTU size. Vergewis jezelf er wel van dat het gebruikte IPv6 adres nog steeds actief is op het moment van pingen. Hij moet dus nog getoond worden als eigen IPv6 adres bij het resultaat van de ping.

Mijn stelling is dat dat ook gebeurt en dat er waarschijnlijk helemaal niets mis is met het mobiele IPv6 netwerk van KPN.

Ik snap ook niet dat jij kan stellen dat KPN de MTU zou moeten vergroten naar 1520. Dat is echt de omgekeerde wereld. Ook als KPN een MTU van 1280 op haar mobiele IPv6 netwerk zou hanteren zou alles gewoon goed moeten functioneren omdat de telefoon dan m.b.v. path MTU discovery tot de conclusie zou zijn gekomen dat de te gebruiken MTU size 1280 is.

Het feit dat de OnePlus Nord CE 5G van ​@TDN keurig op een MTU size van 1500 bytes uitkomt zou in jouw ogen dus betekenen dat ook die telefoon, net als de S21 (?) zelf al een harde limiet van 1500 bytes heeft staan ... toch ​@Francoix? Ik betwijfel dat ten sterkste.

Vraag is of je daar ook een IPv6 netwerk had.

in het kpn netwerk zit er ergens op interface niveau een limitering van 1500 wat te weinig is voor ipv6

je zou moeten weten dat je tegenwoordig in het buitenland gewoon over de apn van KPN gerouteerd wordt en je ip reeks daadwerkelijk die van KPN zelf zijn.

Antwoord is dus: Ja ik had daar gewoon een nederlands ipv4 en een Ipv6 uit de KPN reeks

lokaal is niet relevant aangezien het niet over de MTU van de interface van de modem gaat.

Het enige wat je hier mee aan toont is dat wat ik aan geef over het missen van een harde MTU correrct en juist is.

Dat is helemaal niet te weinig voor IPv6, vrijwel elk netwerk hanteert een MTU van 1500. De minimale MTU size voor IPv6 is 1280, alles daarboven is prima en dus ook 1500.

En waarom zou een MTU van 1500 voor IPv6 op een mobiel netwerk te weinig zijn terwijl een MTU size van 1500 voor IPv6 op het vaste netwerk prima is.

Daarnaast heeft ​@iPhone12Dns geen enkel probleem via IPv6 op zijn Android en ook daar is de MTU 1500.

​@wjb je hebt echt niet door waar het issue zit… het issue is dat er op een interface IN het kon netwerk een hard MTU is ingesteld en toestellen ZONDER ingesteld MTU geven problemen sinds  eind mei dit jaar, sinds de activatie van de nieuw toegewezen 5g frequenties.

hiervoor hadden deze toestellen geen enkel probleem.

er is dus iets gewijzigd in de configuratie van de interface van de masten.

testen op toestellen met deze tools hebben GEEN ENKELE ZIN

je toont er niks mee aan.

je uitspraken hebben niets met deze problematiek te maken.

Probeer maar eens een TLS handshake te doen met bijvoorbeeld cloudflare-dns.com (DNS over TLS)
Dit werkt prima op IPv4
Maar voor IPv6 werkt dit alleen wanneer je  je interface begrenst op 1500.

Daarbij is de packet size zonder headers waar het gaat falen 1472. 

KPN moet op de interfaces naar een MTU hoger dan 1500 om de grotere pakketgrootte van IPv6 te compenseren. 

Ergens in die laatste update van mei is ergens een harde MTU op een interface van die geüpdatete masten terecht gekomen

Dus die OnePlus Nord CE 5G van ​@TDN heeft ook hard een MTU size van 1500 bytes staan?

Nee, het is niet KPN die de MTU size moet verhogen, het is de cliënt die de payload moet verlagen.

Bij IPv4 is de IP header 20 bytes en bij IPv6 is de IP header 40 bytes. De cliënt moet bij IPv6 dus een payload gebruiken die 20 bytes lager ligt.

Bij een MTU van 1500 zou de payload (packet size) bij icmpv6 dus zelfs 1452 moeten zijn. Alles daarboven zou dan moeten falen.

Maar dan nog zou de path MTU discovery hebben moeten "zien" wat die "harde" MTU is en als die MTU size 1280 if hoger is dan zou dat dus geen enkel probleem mogen zijn. Dat is nu precies waar die path MTU discovery voor is, de kleinste MTU vinden op het gehele pad tussen cliënt en server.

https://www.security.nl/posting/723413/Netneutraliteit+en+IPv6 Ga deze link maar eens lezen ​@wjb 

Daar staat voor mij niets nieuws in er er staat ook niets in wat mijn stelling niet staaft.

En nogmaals, volgens jou zou die OnePlus Nord CE 5G van @TDN dus ook hard een MTU van 1500 bytes ingesteld hebben staan. Klopt dat ​@Francoix? 

Ik heb de oneplus nord ce 5g nooit in handen gehad of beschikbaar om mee te testen. maar ja het lijkt er wel op dat deze dat hard ingesteld heeft staan

er staat wel iets in wat je stelling niet staaft, goed lezen, en ook doorklikken naar de links.

 In RFC8200 staat dat 1280 het minimum is en dat voor links met een configureerbare MTU een waarde van 1500 of groter wordt aanbevolen.

die 1500 halen we niet. en zonder limiet op de interface van de telefoon faalt het als de gebruikte dienst wel hoger ondersteunt omdat er geen rekening gehouden is met de header van ipv6 in die 1500

RFC8200 is mij bekend. Die 1500 halen we wel maar zelfs als KPN de MTU op haar nodes op 1280 zou instellen zou het allemaal nog steeds prima moeten lopen.

En dan nogmaals de vraag waar je maar geen antwoord op wil geven.

Heeft de OnePlus Nord CE 5G van ​@TDN ook een limiet van 1500 op z'n interface staan?

Nogmaals geen idee ik heb dat toestel nooit in mn handen gehad en kan er ook niet mee testen

Ik hoop dat er iemand zal zijn die met een andere "nieuwere" Android telefoon, laten we zeggen een 2024 model zoals bijvoorbeeld de OnePlus Nord 4, Samsung S24 of Pixel 9, met de app Ping & Net een Path MTU discovery wil doen naar 2606:4700:4700::1111.

Ik ben benieuwd welke MTU size daaruit komt. Ik vermoed nog steeds 1500 bytes.

Het staat standaard op 1500, maar het is geen limiet. Indien je toegang tot su shell heb, kan je eenvoudig veranderen met ifconfig, in app kan je met setMaxMtu() veranderen.

In source voor oudere versie, b.v. android 3.4 staat ook nergens een maximale limiet voor IPv6

https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-kitkat-mr1/include/linux/ipv6.h

#define IPV6_MIN_MTU 1280

Indien je toegang hebt idd, daarvoor zal je root access moeten hebben. Dit is niet standaard.

Dat doet helemaal niet terzake. Deze app is niet geschikt om het probleem mee te vinden

Waarom niet, je kunt er prima de kleinste MTU size mee vaststellen op het hele pad tussen telefoon en server. En als de interface van de eigen telefoon geen MTU ingesteld heeft staan dan moet die waarde dus wel vanuit het netwerk komen? En aangezien jouw stelling is dat alleen op oudere toestellen hard een MTU ingesteld zou zijn op de interface zou dat dus met een nieuw toestel niet het geval zijn.

Het gaat niet om het kleinste. Het gaat om het pad tussen telefoon en host. Daar zit het probleem. In een interface 

De Path MTU discovery is functionaliteit om de kleinste MTU te vinden die ergens op het pad tussen telefoon en server gebruikt wordt. Dat is immers de MTU die dan gebruikt moet worden voor de communicatie.

Het probleem zit niet in een interface op dat pad zolang die interface maar geen MTU heeft kleiner dan 1280. De rest is prima en moet ook gewoon probleemloos werken.

Nee de meest optimale oftewel de grootste mogelijke. 

Je snapt het niet. Ga een ander vervelen

Klopt, de grootst mogelijke en laat dat nu de kleinste zijn die ergens op het pad ingesteld is.

Bron

En zo'n ICMP error: packet to big kan dus ook meerdere keren voorkomen.

Nee de kleinst mogelijke conform de standaard is 1280. Die hoeven we dus niet te zoeken

Zucht, ik heb het toch helemaal niet over de kleinst mogelijke conform de standaard (1280) maar over de kleinste op het pad tussen client en server. Kijk nog maar eens goed naar die voorbeelden in mijn vorige bericht.

Oftewel de hoogst mogelijk haalbare MTU, en als er een apparaat in het pad is met een lagere MTU die geen path MTU discovery ondersteund of geen icmp berichten stuurt werkt path MTU discovery niet.

Dan zal je letterlijk random pings moeten afvuren met oplopende packet size om die MTU te achterhalen.

Alleen dan moet je wel je interface daar op aan kunnen passen en dat kan niet op Android zonder te rooten

Ben je het met me eens dat die hoogst mogelijk haalbare MTU gelijk is aan de kleinste MTU die ergens op het pad tussen client en server ingesteld staat?

En ik heb nog altijd geen "bewijs" gezien dat dat het geval zou zijn op het mobiele netwerk van KPN.