Verbindingen naar sommige sites lijken te hangen

Hi ​@KeesVQ, een goede vraag.

1500 en 1492 bestaan beide. 1500 wordt over het algemeen gebruikt voor gewoon ethernet netwerken. 1492 is voor PPPoE netwerken. En dat laatste is wat ons modem heeft. Die verbindt via PPPoE met ons netwerk en gaat het internet op. Zo'n verbinding heeft een beetje meer overhead, waardoor er 8 bytes van de MTU afgaan en die dus op 1492 uitkomt. Dus ja, dit is een correcte waarde voor onze modems. Maar voor jouw PC kan het natuurlijk wel 1500 zijn voor het interne netwerk.

Maar je stelt deze vraag natuurlijk niet zomaar. Je geeft aan dat de verbinding naar sommige websites lijkt te hangen. Wat bedoel je hiermee precies?

In de browser krijg je een time out error, bijvoorbeeld bij https://www.debian.org/ maar ook bij sites als DigiD. Andere sites werken gewoon normaal.

Heb je een screenshot van de error die je krijgt? Dat geeft ons meer informatie.

Zonder IPv6 werkt het een stuk beter.. thx!

Fijn dat het zonder IPv6 wel weer werkt!

Eh, ja, maar het is de bedoeling dat het met IPv6 ook werkt toch?

Het ligt eraan. Sommige apparaten kunnen niet overweg met IPv6. En normaal zou het zo moeten zijn dat er dan automatisch geschakeld wordt naar IPv4, maar dat gebeurt niet altijd. Dus dan is de oplossing om IPv6 uit te zetten.

Eenzelfde melding kun je krijgen als jij een apparaat gebruikt dat geen IPv6 kan, maar wel een website bezoekt die alleen IPv6 gebruikt. Dan is de oplossing om een ander, nieuwer apparaat te gebruiken.

Maar in jouw geval lijkt het eerste van toepassing te zijn, aangezien het wel goed als je IPv6 uitzet.

Windows 10 zou prima overweg moeten kunnen met IPv6.. 

Ik verdenk nog steeds de MTU van 1492.

Een raar probleem, zeker als het maar een paar sites betreft. Je screenshot toont een SYNC en een SYNC/ACK met in beide richtingen een MSS=1440.

MTU=MSS+60 by IPv6, dus de verbinding is aangemaakt voor MTU=1500. Daarna gaat er een Client hello uit naar Debian met grootte 1798, en dat is uiteraard aan de grote kant. Firefox/Linux heeft genoeg aan 547 bytes, maar TLSv1.3 i.p.v TLSv1.2.  Die grote pakketten zie je wel vaker in Wireshark, ik weet niet of die dan in de ethernet hardware  gesplitst worden. Maar er komt in ieder geval een “te groot” melding terug. Dat schijnt vaker voor te komen bij SSL maar ik heb geen eenduidige verklaring gezien.

Op een Linux gebaseerd systeem kun je de echte MTU te weten komen met:

ping -6 -s 1452 google.com

1452 is de datagrootte, in Wireshark wordt grootte 1514 getoond, minus 14 byte ethernet header kom je dan op 1500 uit. Ik heb fiber, ook via PPPoE, als DSL inderdaad 1492 heeft zal het ping commando hangen en moet je van de “-s” 8 aftrekken. 

Check in ieder geval even of je geen IPv6 adressen hebt met :1: als vierde element, dat kan IPv6 negatief beinvloeden.  

Het ‘apparaat’ werkt met Ziggo wel gewoon met IPV6..

Win10 moet gewoon met IPv6 overweg kunnen.

Ik heb het nog eens nagekeken. Overmaatse pakketten in Wireshark zijn geen probleem. Maar het is wel de bedoeling dat de data in hapklare brokken van max 1514 bytes naar buiten gaan. Dat moet dan  de hardware van de netwerk interface verzorgen. Bij IPv6 mag geen enkele router zich met de pakket grootte bemoeien, alleen de zender en de ontvanger. Dus het moet meteen goed gaan, anders komt zo’n ICMP boodschap terug die dan ook nog nergens geblokkeerd mag worden. anders loopt de boel vast.  

Dus: waarom ineens zo’n groot SSL verzoek naar Debian? Stuurt Windows een hele verzameling beschikbare algoritmes naar de andere kant? Nou ja, het is niet verboden…. 

Waarom wordt de TCP verbinding onderhandeld met  MSS=1440 in beide richtingen en maakt KPN daar niet onderweg 1432 van? Of is toch ook bij DSL gewoon MTU=1500, net zoals bij glas dat ook PPPoE gebruikt.

Het zou dus een driver/netwerkkaart firmware probleem kunnen zijn, dat een te groot pakket naarr buiten gaat. De ICMP boodschap komt van je eigen subnet, dus waarschijnlijk het LAN adres van de KPN box. Waarom nu toch 1492??? 

Hoe zit het met andere systemen, indien beschikbaar? Zelfde probleem?  

Je bent blijkbaar geïnteresseerd in Linux, in ieder geal van Fedora of Mint kun je live ISO’s downloaden die je van USB kunt opstarten. mits op speciale manier op de USB stick gezet. Heb je op hetzelfde systeem met een live Linux hetzelfde probleem? Dan wijst het toch naar de firmware in de router.  

Anders kun je in Windows bij de eigenschappen van de netwerkkaart “offloading” uitzetten. Dan moet Windows het zelf opknappen. Of de MTU dan maar op 1492 zetten???? 

Routers werken (meestal) op IP niveau en doen dus niks op TCP niveau.

De router web interfaces laat 1492 bij PPP info zien, dus die 1492 lijkt te kloppen.

Ja, zelfde probleem op een ander W10 systeem.

In een Linux VM leek ik ook hetzelfde probleem te hebben. Daar leek het er op alsof kleine HTTP responses wel werkten maar grote niet, dus mogelijk is ICMP de andere kant op een probleem.

​@Denise van KPN Ben ik de enige met dit probleem?

Ik heb hier “PPP informatie”  MTU 1500, dus dan zou MTU=1492 instellen het systeem gemakkelijker maken.

Het is mij niet helemaal duidelijk of de SYN nu alleen de MTU’s van de eindpunten laten zien of dat routers die onderweg kunnen aanpassen. In Linux en Opnsense kun je wel “clamp-mss-to-pmtu” instellen, zodat blijkbaar SYN response aangepast wordt aan de situatie onderweg. 

Ik heb zojuist in onze Win10 Wireshark geïnstalleerd en krijg gedoe met “Malformed Packets” bij de SSL client hello, die ook te groot is. In de binaire code staat “debian.org” en http. Op een of andere manier komt wel een server hello terug en werkt de site wel.

In de ethernet kaart eigenschappen heb ik “large_send_offload_ipv6” op “off” gezet en nu ziet het er normaal uit, alle packets 1514 bytes. 

Kaart (Linux) : Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet

Het lijkt dus toch een Win10 probleem. Ik heb bij deze interface ook de registry moeten aanpassen omdat het gastnetwerk VLAN en het normale netwerk op een hoop gegooid werden en ik gast netwerk adressen (:1:) bij de normale kreeg. 

Het is een IPv6 issue, ​@KeesVQ. Je bent niet de enige die hier last van heeft, helaas.

​@Denise van KPN OK, weet KPN al wat de oorzaak is? Is er een oplossing?

Als er een oplossing was, had ik je die al gegeven. Op dit moment is er een workaround door IPv6 uit te zetten.

$ sudo ping -6 -s 1444 google.com
PING google.com (2a00:1450:400e:802::200e) 1444 data bytes
1452 bytes from ams15s41-in-x0e.1e100.net (2a00:1450:400e:802::200e): icmp_seq=1 ttl=119 time=38.5 ms

$ sudo ping -6 -s 1446 google.com
PING google.com (2a00:1450:400e:810::200e) 1446 data bytes
From mijnmodem.kpn (2a02:a453:429a:0:b2bb:e5ff:fede:980) icmp_seq=1 Packet too big: mtu=1492

$ sudo ping -6 -s 1445 google.com
PING google.com (2a00:1450:400e:801::200e) 1445 data bytes
From mijnmodem.kpn (2a02:a453:429a:0:b2bb:e5ff:fede:980) icmp_seq=6 Packet too big: mtu=1492

Wordt er aan een oplossing gewerkt?

Er wordt gewerkt aan een oplossing, ja. Maar wanneer die komt, weet ik niet.

From mijnmodem.kpn (2a02:a453:429a:0:b2bb:e5ff:fede:980) icmp_seq=1 Packet too big: mtu=1492

Dat is duidelijk, dus de DSL verbinding heeft een MTU van 1492. Bij IPv6 mogen de zender en de ontvanger fragmenteren, alle apparatuur ertussenin moet ongewijzigd doorlaten.  Als de beide PPPoE eindpunten netjes een ICMP sturen, en die aankomt,  komt het met een extra iteratie wel goed, en wordt het resultaat in een cache gezet zodat alle volgende verbindingen met die server meteen goed gaan.

Er worden hier via het forum diverse problemen opgelost met “IPv6 uitzetten”. Ik weet niet wat precies de IPv6 problemen zijn die KPN heeft, hier werkt alles goed met de V10/fiber. Heb je al geprobeerd om de MTU van de PC op 1492 te zetten? Dan weet de andere kant ook meteen dat je niet meer dan 1492 kunt hanteren en kan de verbinding meteen goed opgezet worden. 

Simulatie Fedora 42 VM → OpnSense firewall VM /PPPoE MTU=1492 → PPPoE/Fedora 42 → KPN box 10/fiber.

IPv6 verkeer met wireshark gemonitord ziet er veel schoner uit als de bron ook op MTU 1492 staat. Iedere TLS verbinding naar een nieuwe server moet via client hello/icmp too big/overdoen opgezet worden. De MTU 1492 bewaart Linux 5 minuten per server, zodat volgende verbindingen naar dezelfde server direct goed gaan, maar het is  nodeloze overhead.