​@Cuijkentje 

Kun je bij jouw verbinding IPv6 uitzetten en alleen IPv4 gebruiken ? Werkt het dan wel ?

Hi ​@Cuijkentje en welkom bij de KPN Community. Fijn dat je al reactie hebt gekregen! Ik ben ook benieuwd naar het antwoord op dit:

Je linkt ook naar een post op de Microsoft Developer community, is daar verder nog reactie op gekomen of een oplossing uitgerold? 

Het antwoord staat in de link

IPv6 - ~35% failure rate

IPv4 - 0% failure rate

Dit lijkt op een probleem dat hier een hele tijd geleden gemeld is bij een verbinding met o.a. Debian Linux.

Betreft het een DSL verbinding of glasfiber?  Welke MTU wordt vermeld onder de kop “Internet verbinding” → “Informatie”, aannemende dat de KPN firmware op de router/modem staat.

Als het een glasfiber verbinding is mag MTU geen probleem zijn, die is 1500, en kun je deze post negeren.

MTU is 1500, en betreft glasvezel.

Correct.

Dat klopt. Als ik IPv6 uit zet, dan werkt IPv6 inderdaad helemaal niet meer.

Van Micosoft kreeg ik zeer snel (binnen 24h) reactie.
Ik heb nog extra info met hen gedeeld. Ze zijn nog aan het onderzoeken.
Zie: https://developercommunity.visualstudio.com/t/Title:--Azure-DevOps-IPv6-TLS-handshakes/11062954

Fijn, hopelijk geeft het onderzoek duidelijkheid. 🙂 Mocht er een oplossing komen, wil je hier dan ook delen wat het was? 
Ik ben benieuwd en hoop dat het snel opgelost is.

Zie https://developercommunity.visualstudio.com/t/Title:--Azure-DevOps-IPv6-TLS-handshakes/11062954#T-ND11065339
This suggests the resets may be ISP/peering specific (e.g., KPN/AMS-IX) rather than universally reproducible from Microsoft/Azure egress.

Belangrijkste bevindingen:

• Het probleem is prefix-specifiek: bepaalde Microsoft IPv6-prefixen falen, terwijl andere prefixen op hetzelfde netwerk en op hetzelfde moment wél correct werken
• Noch TLS 1.2 noch TLS 1.3 slaagt wanneer deze geforceerd wordt (0/20 elk)
• Een Microsoft engineer heeft vanuit hun eigen netwerk getest en kon het probleem niet reproduceren, wat de serverzijde uitsluit
• Het foutpatroon (TCP RST tijdens TLS-handshake) en het feit dat alleen bepaalde bestemmingsprefixen getroffen zijn, wijst op een routing- of middlebox-probleem op het peeringpad tussen KPN en Microsoft via BNIX

Verzoek: Zou u het IPv6-peeringpad van KPN naar Microsoft's prefixen 2603:1061:10::/44 en 2603:1030:a0b::/48 via BNIX (2001:7f8:13::/48) kunnen onderzoeken? De intermitterende TCP-resets tijdens de TLS-handshake suggereren mogelijke packetcorruptie, MTU-problemen of een verkeerd geconfigureerde middlebox op dit specifieke pad.

Hmmm, ik ga een collega aan de mouw trekken die ons vaker heeft geholpen met peering kwesties. Als ik daar terugkoppeling van heb gekregen laat ik het hier weten! 

Bedankt voor je geduld ​@Cuijkentje! Ik heb reactie van mijn collega. 😄

Op het Microsoft forum geef je het volgende aan: 

TCP connects succeed 100% over IPv6 — only the TLS handshake is reset.

Als TCP connects 100% succesvol zijn, dan is er vrijwel zeker geen issue in het peering domein. Als daar iets zou zitten dan zouden ook de connects niet helemaal goed lopen.

Daarnaast peert KPN niet via AMS-IX of via BNIX. Wij hebben directe sessies met Microsoft.

Ook dit stuk:

• Conclusion: The Azure Front Door cluster serving Azure DevOps-related IPv6 prefixes (2603:1061:10::/47, 2603:1030:a0b::/48) intermittently resets IPv6 TLS handshakes. Other Microsoft services routed through the same peering path work fine, isolating the issue to these specific Front Door clusters.

Deze conclusie icm bovenstaande, geeft eigenlijk al vrij duidelijk aan dat het niet aan de KPN-Microsoft peering ligt, anders zou het bij alle clusters voorkomen. Het lijkt me meer in het netwerk domein van Microsoft te liggen. 

Aldus mijn collega. Niet iets waar wij wat in kunnen regelen dus, ik hoop dat je via de Microsoft/Azure ondersteuning verder komt!

Ai. Microsoft geeft een gelijksoortig antwoord. Daardoor komt deze tussen wal en schip.

Is het probleem er nog steeds? 

Ik heb het script ook geprobeerd vanaf een Win10 PC, maar geen probleem gezien. 

Ik weet niet of de Linux variant “openssl s_client” exact hetzelfde doet, maar ik zie de certificaten voorbij komen en het commando wacht op HTTP invoer. 

De server wil wel MSS=1400 hebben, met mijn oude Wifi dongle gaat de client hello er ook netjes met 1474 i.p.v. 1514 bytes opgesplitst uit. Werkt het wel correct met MTU=1460?     

Dit is juist het probleem, dat hij het probleem alleen vanuit zijn IP-adres heeft. Ik heb ook geen probleem dev.azure.com via IPv6 met dit script. Heel moeilijk om de oorzaak te achterhalen, waar (in de routing) geblokkeerd is.

Fijn om te weten dat het bij jullie wel goed gaat ​@hmmsjan_2 en ​@TDN, dank voor het reageren! Waardevolle informatie. 

Mijn collega neemt het in elk geval mee naar een volgend overleg om dit te signaleren, misschien dat er vanuit daar nog wat te achterhalen valt. Mocht ik daar terugkoppeling op krijgen dan laat ik het je weten, maar voor nu hebben we helaas geen oplossing voor handen. 
Mocht jij in de tussentijd nog een oplossing vinden, laat je het dan ook weten? Je kunt mijn eerdere reactie hier nog doorgeven aan Azure/Microsoft, misschien dat ze daardoor toch verder kunnen testen om de oorzaak te achterhalen. Ik weet niet of zij verder nog mogelijkheden hebben maar het is ook niet de bedoeling dat dit tussen wal en schip belandt.