​@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!