Gebruikers krijgen geen VPN-toegang via IPv6 met zakelijke verbinding (DNS fout?)

Hallo ​@bry87 

Oplossing voor het echte probleem heb ik niet, dat zal door KPN moeten gebeuren, je hebt de zakelijke klantenservice op 0800-0403 gebeld? Je zou verwachten dat die dat naar de juiste afdeling kunnen doorzetten.

Een workaround: Je zou een vpn.bedrijf.nl kunnen laten aanmaken door de DNS beheerder voor IPv6 met een geconverteerd IPv4 naar IPv6 IP adres: https://dnschecker.org/ipv4-to-ipv6.php

Dan wordt je gewoon doorgeleid naar het juiste IPv4 IP adres.

Ik heb een keer gebeld naar dat nummer en ik heb twee afdelingen gesproken, maar ik voel een kastje-naar-de-muur aankomen nu. Ik kende deze IPv4-naar-IPv6-oplossing nog niet en ik neem hem serieus in overweging. 

Edit: Als het record wel hangt bij KPN dan maakt dit waarschijnlijk geen verschil. We gaan het zien :-)

Het is geen kastje muur, gewoon een vraag of je wel de zakelijke (i.p.v. de gewone) klantenservice had gebeld.

Ik ben overigens geen KPN medewerker, die kun je herkennen aan het gedeelte “van KPN” in hun forumnaam, de overige gebruikers zijn allemaal gewone forumgebruikers.
KPN medewerkers/moderators reageren als ze aan je topic zijn toegekomen, dat kan een aantal dagen duren afhankelijk van hoe druk ze het hebben.

Edit: Ik hoor wel of het gewerkt heeft, zou toch vreemd zijn als KPN dat record zou overrulen.

Wat u waargenomen heeft is verklaarbaar. U gebruikt het mobiele netwerk, en dat gebruikt met de standaard APN uitsluitend IPv6.  Nu is het uiteraard niet de bedoelingen om sites met alleen IPv4 uit te sluiten, dus de KPN DNS geeft  vpn.bedrijf.nl  een IPv6 adres in de range 64:ff9b::/96 met de laatste 32 bits het IPv4 adres hexadecimaal. Deze adressen worden afgevangen bij KPN en als IPv4 naar de betreffende server gestuurd. Een standaard netwerk kan niets met deze adressen, dus een normale DNS server mag ze niet uitgeven. 

Daarnaast geeft het besturingssysteem een enkel IPv4 adres om IPv4 adressen naar de 64:ff9b::/96 IPv6 prefix te vertalen, zodat bijv. “ping 1.1.1.1” werkt. Als alles goed samenspeelt heb je dus “dual stack” terwijl alleen IPv6 door de ether gaat. ( Zie NAT64 en 464XLAT voor details)

Een VPN zonder IPv6 support voegt dan weer een “klassieke” IPv4 verbinding toe. Als alle internet verkeer over de VPN gaat, wat als ik goed begrepen heb standaard is bij IOS, moet de VPN de DNS server dus wel aanpassen naar een eigen server.  

In theorie moet het dus werken, maar ik weet te weinig van mobiel of alle operating system versies die in telefoons gestopt worden dit allemaal netjes doen. In dat geval kunt u een APN proberen die een “echt” IPv4 adres uitgeeft.

Ik vatte het ook niet persoonlijk op ​@bry87 maar het was alleen bedoeld om duidelijk te maken dat er hier nog geen KPN medewerker had gereageerd.
 

Fijn dat het werkt en je dat nog even hebt laten weten.

Eens getest met een (oude) iphone en OpenVPN naar een eigen server. Met hotspot aan maakt IOS een bridge aan, zodat de telefoon en de PC op een enkel netwerk zitten en een geldige IPv6 configuratie verkregen wordt. Plus IPv4.  APN=internet.  

Zonder IPv6 adres krijgt de OpenVPN server een IPv6 in de   64:ff9b:: range en VPN werkt. Communicatie tussen PC en telefoon loopt via IPv6 en het 64:ff9b:: adres. Dit is zoals het zou moeten zijn, webservers met alleen IPv4 lopen ook via die 64:ff9b:: prefix. 

Maar een ::ffff:<ipv4 adres> prefix in DNS werkt het ook, ik heb nooit een toepassing hiervoor gezien. De communicatie tussen PC en telefoon loopt nu via IPv4. Achter de telefoon kan ik niet kijken, maar bij gebrek aan een IPv4 adres zal toch 64:ff9b:: naar buiten moeten gaan.

Dus: IOS + Linux werkt noals het moet. Het zou ook nog kunnen zijn dat Windows of beveiligingssoftware problemen heeft met die 64:ff9b prefix, die als “bogon” op ipinfo.io staat. Wat op ipinfo staat is correct: dit adres hoort niet op internet. Maar het blijft binnen het KPN netwerk, naar buiten gaat IPv4.

Windows ondersteunt CLAT nog niet op Wifi of LAN maar wordt dan ondersteunen in Windows 11

Windows 11 Plans to Expand CLAT Support

OK, dat zou wat kunnen verklaren. Ik zal bij gelegenheid eens op een Win10 systeem kijken, want helemaal begrijp ik het nog niet. Ik krijg in Linux netjes een IPv4 en IPv6 adres, en als je dus simpelweg 64:ff9b:: via de default route naar de telefoon stuurt zou het volgens mij moeten werken. Maar als je via Wifi alleen 2000::/3 accepteert wordt het natuurlijk niets…