Ik kan geen VPN verbinding maken met Forticlient als ik een hotspot maak op mijn iPhone. Als ik een andere APN instel zoals advancedinternet of portalmmm.nl wil mijn laptop überhaupt niet eens verbinden met de hotspot. Of ja, wel verbinden maar er is dan geen internet.
Als ik een zelfde iPhone gebruik met bijvoorbeeld een Odido of Vodafone simkaart werkt het prima.
Oh en ja 1440 is een uitstekende keuze voor de MTU. en ja bij IPV6 worden grotere MTU waardes gewoon gedropt op de interface, en dat stukje ICMP6 logging wordt weer gebruikt voor de MTU Path Discovery
Als er ergens op een interface 1500 hard staat voor ipv6 binnen kpn heb je dit gelazer
Ik zeg ook niet dat er geen MTU Path Discovery gebruikt moet worden maar ik denk dat dat aan de cliënt zijde ook gewoon gebruikt wordt. Met MTU Path Discovery wordt niet de MTU packetsize bepaalt die je op jouw eigen interface kunt zetten, maar de maximale packetsize (incl. headers) die de software mag verzenden. Op de interfaces mag best een grotere MTU ingesteld staan, het is de MTU Path Discovery waarmee vervolgens bepaald kan worden wat de kleinste van al die MTU's is en dus wat de maximale packetsize (incl. headers) is.
Klopt, alleen als er 1 pad vanaf de server zijde tussen zit die een te lage MTU heeft op de interface werkt het simpelweg gewoon niet omdat alles gedropt wordt in de route tussen server en client.
daar zit voor IPv6 het verschil met IPv4.
IPv6 ondersteunt geen fragmentatie zo als ipv4. IPv6 dropt gewoon met een ICMP6 packet-too-big retour naar de host, maar dan moet die host natuurlijk wel snappen dat ie de MTU omlaag moet brengen. en dat is wat MTU Path Discovery doet.
Maar dan moet ie dat wel doorgestuurd krijgen, en daar gaat het ook vaak mis bij CG-NAT implementaties. dat ICMP verkeer gefilterd of geblokkeerd wordt en dat lijdt tot hetzelfde probleem. Pakketten blijven droppen.
Klopt, alleen als er 1 pad vanaf de server zijde tussen zit die een te lage MTU heeft op de interface werkt het simpelweg gewoon niet omdat alles gedropt wordt aan de client zijde. daar zit voor IPv6 het verschil met IPv4. IPv6 ondersteunt geen fragmentatie zo als ipv4. IPv6 dropt gewoon met een ICMP6 packet-too-big retour naar de host, maar dan moet die host natuurlijk wel snappen dat ie de MTU omlaag moet brengen.
Ook bij IPv4 wordt vrijwel nooit meer packet fragmentation toegestaan.
Maar het is niet de ontvanger die de packetsize bepaalt, dat is de verzender. Dus als Fortigate geen MTU Path Discovery doet maar altijd een payload van 1460 hanteert dan heb je bij een MTU packetsize kleiner dan 1500 de poppetjes aan het dansen.
klopt en daarom gaat alles wat boven die 1500 komt ook fout op apn “internet” want dat dropt gewoon.
dit komt uit een NAT-implementatie of firewall die een ICMP message 'packet too big' van een host upstream niet doorlaat. Uiteindelijk is het dit ICMP message die niet terugkomt bij een host dat PMTUD verbreekt.
en daarom is CG-NAT een waardeloze oplossing voor een gebrek aan IPv4 adressen. het is zo goed als de beheerder. Feitelijk moeten we IPv4 skippen en over naar dedicated IPv6, Dan zijn we volledig van NAT implementaties af. maar dat is een utopie
klopt en daarom gaat alles wat boven die 1500 komt ook fout op apn “internet” want dat dropt gewoon.
Terecht voor netwerken waarop geen packet fragmentation toegestaan wordt en er door de verzender toch een groter packet gestuurd wordt. Dan moet je toch echt bij de verzender zijn, niet bij de ontvanger of een partij op de route naar de ontvanger.
dit komt uit een NAT-implementatie of firewall die een ICMP message 'packet too big' van een host upstream niet doorlaat. Uiteindelijk is het dit ICMP message die niet terugkomt bij een host dat PMTUD verbreekt.
Heb jij kunnen constateren dat dat het geval is?
Je gaf zelf aan dat die Fortigate geen MTU Path Discovery ondersteunt. Die zet dus blijkbaar zelf de te gebruiken MTU packetsize en gebruikt geen MTU Packet Discovery. Dan valt er ook weinig te droppen door een CGNAT.
Maar goed, op het IPv6-only netwerk van KPN is helemaal geen sprake van Carrier-Grade natting en op het IPv4 netwerk van Odido (met CGNAT) heeft
Nog steeds kunnen pakketten droppen door verkeerde configuratie van dit IPv6 Only deel
ER VAN UITGAANDE DAT DE VPN OOK DAADWERKELIJK OP IPv6 LOOPT
Maar als er een interface is met een te lage limiet (wat de 1500 MTU als grens verklaart) of ICMP filtering aan staat is het gelazer in de glazen. we lopen nog steeds door een APN heen met settings van KPN er in en door netwerk interfaces en firewalls van KPN. of firmware/software van masten. al deze componenten kunnen de boosdoener zijn
MTU Packet Discovery is ZEER belangrijk voor IPv6 en dit moet gewoon gaan functioneren conform de standaard.
Als hier geen MTU Packet Discovery aan staat, er een interface is met een te lage limiet (wat de 1500 MTU als grens verklaart) of ICMP filtering aan staat is het gelazer in de glazen.
MTU Path Discovery hoeft enkel door de verzender gedaan te worden en door geen enkele andere server op de route. Het is immers de verzender die moet bepalen hoe groot het pakketje mag zijn dat hij wil versturen.
Ik weet dus niet wat je nu wilt zeggen met dat MTU Path Discovery aan moet staan.
En een MTU van 1500 bytes is weer,dwijd de standaard voor de MTU packetsize op Ethernet. Dat is dus niet een te lage limiet maar de standaard limieten daar is dus niets mis mee.
MTU Packet Discovery is ZEER belangrijk voor IPv6 en dit moet gewoon gaan functioneren conform de standaard.
Ik denk ook dat dat het geval zal zijn op de netwerken van KPN, anders zouden die Android telefoons ook geen VPN verbinding op kunnen zetten en dat is dus niet het geval, die werken immers prima via het IPv6-only netwerk van KPN.
Als hier geen MTU Packet Discovery aan staat, er een interface is met een te lage limiet (wat de 1500 MTU als grens verklaart) of ICMP filtering aan staat is het gelazer in de glazen.
MTU Path Discovery hoeft enkel door de verzender gedaan te worden en door geen enkele andere server op de route. Het is immers de verzender die moet bepalen hoe groot het pakketje mag zijn dat hij wil versturen.
Ik weet dus niet wat je nu wilt zeggen met dat MTU Path Discovery aan moet staan.
En een MTU van 1500 bytes is weer,dwijd de standaard voor de MTU packetsize op Ethernet. Dat is dus niet een te lage limiet maar de standaard limieten daar is dus niets mis mee.
MITS de ICMP melding terug komt ja, anders werkt MTU Path Discovery niet
en 1500 MTU is voor ipv4 de standaard. Niet voor IPv6 daar is alleen een MINIMUM van 1280 voor. en 1500 wordt als algemeen aangehouden aan de client kant maar dat is meer legacy. in feite is daar geen waarde nodig aangezien de server leidend is
overigens kan je met een MTU van 1500 nooit over de 7 Gbit heen komen qua snelheid
Als hier geen MTU Packet Discovery aan staat, er een interface is met een te lage limiet (wat de 1500 MTU als grens verklaart) of ICMP filtering aan staat is het gelazer in de glazen.
MTU Path Discovery hoeft enkel door de verzender gedaan te worden en door geen enkele andere server op de route. Het is immers de verzender die moet bepalen hoe groot het pakketje mag zijn dat hij wil versturen.
Ik weet dus niet wat je nu wilt zeggen met dat MTU Path Discovery aan moet staan.
En een MTU van 1500 bytes is weer,dwijd de standaard voor de MTU packetsize op Ethernet. Dat is dus niet een te lage limiet maar de standaard limieten daar is dus niets mis mee.
MITS de ICMP melding terug komt ja, anders werkt MTU Path Discovery niet
Dat zal ook het geval zijn. Nogmaals, met een Android telefoon heeft
nou ja als in de iphone geen max MTU staat en deze vertrouwt op MTU Path Discovery zo als de niet werkende android toestellen en de interfaces van KPN gelimiteerd zijn op 1500 is dat het probleem binnen het netwerk
Overigens is het 100% zeker dat KPN die ICMP6 drops af filtert naar de server toe.
Overigens is het 100% zeker dat KPN die ICMP6 drops af filtert naar de server toe.
Daar geloof ik helemaal niets van.
Ik ben benieuwd hoe je dat met 100% zekerheid hebt kunnen constateren.
jij gelooft nooit ergens wat van.
maar heel simpel als je zowel logt op client als server en die vergelijkt krijg je een heel concreet beeld.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.