Gelöst
Warum erfindet der Telekom-Mobilfunk-DNS einen IPv6 (AAAA) DNS-Eintrag, der real nicht existiert?
vor einem Jahr
Über Mobilfunk-Hotspot funktioniert bei uns die VPN -Einwahl per "FortiClient" (FortiGate-Firewalls) nicht.
Ursache:
das VPN -Gateway wird per DNS angesprochen. Für den DNS-Namen gibt es ausschließlich einen publizierten A-Record, sprich Verweis auf eine IPv4-Adresse.
Nur dann, wenn wir das Notebook per T-Mobile online schicken (entweder direkt per Datenkarte oder wenn es mit der Hotspot-Funktions des iPhones die T-Mobile-Verbindung des iPhones mit-verwendet), wird bei einem nslookup auf das VPN -Gateway außer der (richtigen!) IPv4-Adresse zusätzlich ein IPv6-Eintrag (AAAA) zurückgegeben, zum Beispiel 64:ff9b::b921:d804.
Das ist eine Pseudo-IPv6-Adresse, die für NAT64 reserviert ist, und vom Telekom-DNS schlicht erfunden wurde:
https://whois.arin.net/rest/net/NET6-64-FF9B-1
Da heutige Betriebssysteme IPv6 gegenüber IPv4 bevorzugen, geht der FortiClient also gegen die IPv6-Adresse und das VPN -Gateway verweigert die Verbindung, weil dann eine IPv6-Quelle per IPv4 bei ihm ankommt (die Telekom hat ja irgendwo ein NAT64-Übersetzungs-Gateway dazwischen).
Einfache Frage:
1) Soll das so sein? Ich dachte die Telekom wäre schon mit CGNAT ausreichend beschäftigt (private IPv4-Adresse der Mobilfunk-Teilnehmer auf eine global routbare übersetzen), warum wird ohne Not auch noch NAT64 forciert, indem man für IPv4-Ziele im Internet DNS-Einträge dazuerfindet?
2) Wie schaltet man den Unsinn ab?
Mit freundlichen Grüßen,
Patrick Wagner
653
23
Das könnte Ihnen auch weiterhelfen
in
478
0
2
vor 4 Jahren
2376
0
2
3602
1
2
vor einem Jahr
362
0
3
vor 5 Jahren
1059
2
1
vor einem Jahr
Das ist eine Pseudo-IPv6-Adresse, die für NAT64 reserviert ist, und vom Telekom-DNS schlicht erfunden wurde:
Was Du siehst ist NAT64/DNS64 am Werk, exakt so wie im RFC spezifiziert.
Da heutige Betriebssysteme IPv6 gegenüber IPv4 bevorzugen,
Das tun sie, spielt hier aber keine Rolle, deine Geräte nutzen IPv6 weil sie überhaupt keine IPv4-Verbindung herstellen können. Auf dem APN "internet.v6.telekom" gibt es einfach keine IPv4-Adressen für die mobilen Endgeräte.
geht der FortiClient also gegen die IPv6-Adresse und das VPN -Gateway verweigert die Verbindung
Schon ein wenig rückständig, wenn Deine Firewall mit NAT64/DNS64 nicht klar kommt.
2) Wie schaltet man den Unsinn ab?
2) Wie schaltet man den Unsinn ab?
Weiß jetzt nicht warum du glaubst das wäre Unsinn, aber wenn du echtes Dualstack (IPv4 immer noch hinter CGNAT) brauchst, dann ändere einfach den APN im Mobilfunkgerät auf "Internet.telekom".
4
Antwort
von
vor einem Jahr
Aus meiner Sicht ist die Frage, warum als Default- APN (internet.v6.telekom) einer ausgewählt wird, der es aus meiner Sicht falsch rum macht bzw. mit dem man auch nix gewinnt
Deine Sicht ist offensichtlich eine andere als die eines großen Netzbetreibers. Die Telekom hat in Deutschland über 60 Millionen Mobilfunkteilnehmer, die heutzutage alle (mindestens!) eine IPv4-Adresse haben wollen. Das passt nicht in ein 10/8er-Netz, schon garnicht wenn man ja interne Adressbereiche aus denen für die User raushalten muss. Natürlich kannst Du die 10/8er-Adressen mehrfach verwenden, das bedingt aber einen aufwändigen Mechanismus um verschiedene User trotz gleicher IP-Adresse auseinanderzuhalten. Der Aufwand fällt jedesmal an, wenn eine weitere Instanz von 10/8 angebrochen werden muss.
Da ist es besser, nur noch mit IPv6-Adressen zu arbeiten, dann erledigen sich die meisten Probleme ganz von selbst.
während IPv4-Ziele übersetzt werden müssen, indem man sowohl die DNS-Antwort faken muss (AAAA zusätzlich oder anstelle A) und die Client- *und* die Ziel-IPv6-Adresse übersetzen muss in IPv4, damit die IPv4-Gegenstelle etwas damit anfangen kann.
Verglichen mit dem ohnehin notwendigen CGNAT ist das kein großer Zusatzaufwand.
Was macht die Telekom eigentlich, wenn ein Client hinter dem Hotspot DoH / DoT verwendet und damit DNS64 eh nicht klappt? internet.v6.telekom klappt damit nicht, internet.telekom schon?
Wenn das ein kleiner Kunde ist sagt sie "nimm halt den internet.telekom". Wenn es ein großer Kunde ist, dann sagt sie "nimm halt einen privaten APN , dann kannst Du Dich selbst um die IPv4-Adressvergabe kümmern und alles so einrichten wie Du willst".
Aus meiner Sicht ist damit einseitig internet.v6.telekom mit Nachteilen behaftet, die internet.telekom nicht hat.
Für den Absoluten Großteil der mit Smartphones ausgestatteten User ist das kein Problem. Android kann 464XLAT und damit sogar Applikationen anbinden, die garnicht IPv6-fähig sind, Apple hat solche Apps längst aus dem Store geworfen. Wer dann doch Probleme hat stellt halt einfach auf den "internet.telekom" um, so wie Du jetzt.
Antwort
von
vor einem Jahr
Guten Abend @nocrgfi,
ich bedanke mich für deine Zeit am Telefon, auch wenn ich jetzt leider noch gar nichts zum Thema beitragen konnte.
Deswegen habe ich eine E-Mail an meine Kollegen verfasst, die da hoffentlich mehr Durchblick haben.
@lejupp Vielen Dank bis hierhin für deinen Input.
Lieben Gruß
Diandra S.
Antwort
von
vor einem Jahr
Hallo Diandra,
der "Weg vorwärts" ist in dem Sinne klar, wir müssen wohl den APN umstellen (zumindest bei Android wird der aber wohl nicht automatisch / alternativ gepusht, muss man die Einstellungen alle einzeln neu eintragen), damit wir uns verbinden können.
"Blog"-Eintrag von "damals":
https://telekomhilft.telekom.de/t5/Telekom-hilft-News/Neuer-IPv6-Zugang-zum-mobilen-Internet-im-Netz-der-Telekom/ba-p/4254741
Interessant dabei:
Telekom kann sagen "(fast) alles klappt einwandfrei, wenn nur FortiClient- VPN -Einwahl nicht, dann ist es deren Bug", und
Fortinet kann sagen "niemand hat solche Probleme berichtet außer deutschen Mobilfunk-Nutzern, liegt also an der Telekom-Implementierung".
Die Frage ist also:
Ist die Telekom der einzige Provider weltweit (zumindest von gewisser Reichweite), der einen IPv6-only- APN als Default pusht?
Wenn ja, dann kann es sehr gut eine Problematik im FortiClient sein, dass er mit NAT64 nicht zurecht kommt.
Wenn es hingegen andere halbwegs sichtbare Provider gibt, die genauso wie die Telekom ein IPv6-only- APN publizieren, aber dort keinerlei Probleme von FortiClient-Benutzern bekannt sind, dann müsste es ja ein Problem in der Implementierung (oder Software-Bug) der Telekom-NAT64-Gateways sein.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Frag doch mal bei Fortigate nach, was sie an der NAT64/DNS64-Implementierung der Telekom auszusetzen haben.Die Frage ziehe ich mal zurück, manche VPNs gehen halt nicht über NAT64/DNS64.
Allerdings frage ich mich, wie der internet.v6.telekom eigentlich auf die Fortigate kommt. Die Telekom hat ihn jedenfalls nicht drauf gepusht.
2
Antwort
von
vor einem Jahr
Allerdings frage ich mich, wie der internet.v6.telekom eigentlich auf die Fortigate kommt. Die Telekom hat ihn jedenfalls nicht drauf gepusht.
Hm? Die Logik in dem Satz ist falschrum, oder nicht?
Die Fortigate ist das Zielsystem mit fester IPv4-Adresse. Der Clientrechner sitzt an einem Telekom-Mobilfunk-Anschluss, der standardmäßig seit 2020 den IPv6-only- APN gepusht bekommt, und dort muss der APN dann auch umgestellt werden. Die Fortigate selbst hat damit nichts zu tun und weiß auch gar nichts von dem APN .
Antwort
von
vor einem Jahr
Sorry, ich hatte mir vorgestellt dass die Fortigate-Hardware auf der mobilen Seite eingesetzt wird.
Dann wäre also Deine Forderung, dass die Telekom bei für alle Endgeräte aller Kunden bei Dualstack bleibt damit Deine Lösung weiterhin so funktioniert wie gewohnt? Sorry, aber das meinst Du doch nicht ernst...?
Wen Fortigate das VPN -Gateway ist, warum hat es keine IPv6-Adresse? Dann können die User nativ IPv6 nutzen und es muss nichts umgesetzt werden.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
die Telekom hat das alles dokumentiert:
https://telekomhilft.telekom.de/t5/Telekom-hilft-News/Neuer-IPv6-Zugang-zum-mobilen-Internet-im-Netz-der-Telekom/ba-p/4254741
Es vereinfacht die Infrastruktur.
Zu deiner Frage DoT oder DoH. Das funktioniert in der Regel auch, da normalerweise clat aktiv ist. des Weiteren gibt es auch Anbieter, die ebenfalls dns64 anbieten, z.b. dns64.dns.google. oder dns64.Cloudflare-dns.com
Das beste gegen erfundene AAAA records sind übrigens echte!
Wenn der VPN Server richtig konfiguriert wäre, hättest du das Problem überhaupt nicht.
0
vor einem Jahr
Zu der Frage, ob die Telekom das nur tut. Nein, in den USA (T-Mobile) und Indien (jio) , Polen (Orange) und vielen weiteren wird das auch so praktiziert.
4
Antwort
von
vor einem Jahr
Vielen Dank für die Rückmeldung @nocrgfi.
Meine Kollegen haben nun auch ein entsprechendes Ticket erfasst und melden sich bei mir, wenn es eine Rückmeldung dazu gibt. Erfahrungsgemäß nimmt das einige Zeit in Anspruch, deswegen bitte ich an dieser Stelle einmal um deine geschätzte Langmut.
Lieben Gruß
Diandra S.
Antwort
von
vor einem Jahr
Dass ausdrücklich in anderen Ländern (gerade dem "Fortinet-Heimatmarkt" T-Mobile USA) dasselbe Problem auftaucht, habe ich noch nie gelesen Dass ausdrücklich in anderen Ländern (gerade dem "Fortinet-Heimatmarkt" T-Mobile USA) dasselbe Problem auftaucht, habe ich noch nie gelesen Dass ausdrücklich in anderen Ländern (gerade dem "Fortinet-Heimatmarkt" T-Mobile USA) dasselbe Problem auftaucht, habe ich noch nie gelesen
Dass ausdrücklich in anderen Ländern (gerade dem "Fortinet-Heimatmarkt" T-Mobile USA) dasselbe Problem auftaucht, habe ich noch nie gelesen
Vielleicht sind die Informationstechniker in den USA nur besser und verpassen dem Fortigate eine richtige IPv6-Adresse, dann tritt das Problem der Hilfsadresse nämlich gar nicht ein! Auf rgi wirft dieses Ticket meiner Ansicht nach kein gutes Licht. Den RFC 6147 und dessen Anwendung gibt es nicht erst seit gestern.
Schnelle/vorübergehende Abhilfe erreichen Sie übrigens durch Abschalten von IPv6 auf dem Notebook. Das widerspricht zwar den Empfehlungen von Microsoft, könnte in Ihrem Fall ein funktionierender Workaround sein, ohne das Smartphone verstellen zu müssen.
Antwort
von
vor einem Jahr
Das war die naheliegende erste Option, aber da macht einem in der Tat Fortinet einen (undokumentierten!) Strich durch die Rechnung, denn (obwohl das technisch gar nichts miteinander zu tun haben muss) legt die Verwendung der Protokollversion (IPv4 oder IPv6) für das Outer Packet (verschlüsselte SSLVPN-Pakete) auch die Verwendung derselben Protokollversion innerhalb des Tunnels fest.
Spricht man eine Fortigate also per IPv4 als VPN -Gateway an, klappt innerhalb des VPN nur IPv4, spricht man sie per IPv6-Adresse an, dann klappt innerhalb des VPN nur IPv6.
Dass das offensichtlich unsinnig ist, ist mir klar, ich habe allerdings keinen Zugriff auf deren Quelltext, um das ändern zu können. "Erst" FortiOS 7.0 hat einen CLI-Schalter für "dual-stack-mode" innerhalb des Tunnels hinzugefügt, der erfordert dann aber allerdings, dass alle IPv4-Firewall-Policies auch um IPv6-Quellen und -Ziele erweitert werden müssen und anderen Voraussetzungen.
"IPv6 auf dem Netzwerkadapter abschalten" haben wir übrigens erfolgreich bisher als Workaround verwendet, inzwischen hat mich aber interessiert, was / ob die Deutsche Telekom irgendwas anders macht als "alle anderen", da wie gesagt von anderen Mobilfunkprovidern mir kein solches FortiClient-Problem bewusst wäre, weder bei deutschen Mitbewerbern noch im Ausland. Ich habe daher aus diesem Thread gelernt, dass die Telekom ihrerseits behauptet, Standard-NAT64/DNS64 zu fahren und das andererseits andere Provider außerhalb Deutschlands genauso seit Jahren anwenden sollen, wo der FortiClient allerdings 0 Probleme macht.
Zumindest klärt es, dass ich zwischen 2 funktionierenden Workarounds statt vorher einem wählen kann - außer IPv6 deaktivieren funktioniert auch die APN -Änderung einwandfrei und das ist wahrscheinlich die für uns besser skalierende Variante.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Danke für die weiteren Erläuterungen. Die anderen beiden dt. Provider machen das, was die Telekom mit dem älteren APN auch anbietet(Dualstack).
Vielleicht liegt es auch an der eher seltenen Kombination. Ich nutze und teste auch viel VPN und IPv6. (früher Cisco anyconnect, jetzt openvpn(eduvpn + eigener Server), wireguard(eduvpn + AVM) und auch wieder ipsec(AVM), ein "SSL VPN " (irgendwas mit Pulse im Namen)war bisher auch dabei, letzteres mochte vor zwei Jahren auch keine IPv6 only Umgebung)
7
Antwort
von
vor einem Jahr
Guten Abend zusammen!
Es ist nun ein Feedback da, das möchte ich euch nicht vorenthalten:
Ab Mitte März wurde von Apple ein iOS-Release ausgerollt, bei dem der voreingestellte APN ggf. überschrieben worden sein könnte oder die internet NAT64-Logik verändert wurde.. Netzseitig wurde hier nichts geändert. Leider haben wir auch nur max. 7 Tage die Möglichkeit, rückwirkend auf einzelne Endgeräte bzgl. der APN -Nutzung zu schauen, um die Theorie des Apple-Updates bzgl. APN -Umstellung konkret prüfen/belegen zu können.
Grundsätzlich setzen wir im Rahmen des APNs internet.v6.telekom auf NAT64 ( 464XLAT ), so dass für die Kommunikation mit einer IPv4-Adresse aus dem Internet eine standardisierte IPv6-Adresse (standardisiertes Prefix 64:FF9B::/64) im eingenen Netz bis zum Endgerät genutzt wird. Im Endgerät erfolgt dann wieder die Umsetzung auf IPv4 via CLAT. Am Übergang zum Internet wird dann aus dieser standardisierten IPv6-Adresse wieder die eigentliche IPv4-Adresse. Unser DNS setzt diese IPv4-Adresse aus dem Internet bereits in die standardisierte IPv6-Adresse im Rahmen des AAAA-Requests um und gibt diese an den Client weiter.
Es wurden in der Vergangenheit bereits Kundenfälle in Bezug auf FortiClient und IPv6 untersucht und das Problem ist hierbei nicht unser Netz gewesen.
Falls das Problem bei einem von euch weiterhin auftritt, sagt bitte noch einmal direkt Bescheid, damit wir eure Beispiele mit Rufnummer und Zeitstempel zeitnah zur Analyse weitergeben können.
Lieben Gruß
Diandra S.
Antwort
von
vor einem Jahr
Danke @Diandra S.
sicher lese ich noch mit. Interessant, dass auch Apple-Probleme mit NAT64 seit März bekannt sind. Es könnte bei uns aber schon länger sein, aber ich werde trotzdem nochmal schauen, dass ich bei Betroffenen das noch mal nachstellen lasse. Dann könnte ich auch auch einen Timestamp liefern zum Account.
Fortigate selbst hat noch keine Lösung angeboten, vermuten aktuell was wegen MTU (weil ihr Client nicht mitkriegt / nicht damit rechnet, nochmal eingepackt zu werden - aber das müsste der Telekom-Server ja antizipieren und mit im Telekom-Backbone mit entsprechend großen Frames hantieren können, ohne dass die Endstellen der Kommunikation was ändern müssen)
Danke,
Patrick
Antwort
von
vor 10 Monaten
Es wurden in der Vergangenheit bereits Kundenfälle in Bezug auf FortiClient und IPv6 untersucht und das Problem ist hierbei nicht unser Netz gewesen.
So, nach noch einmal ein bisschen Zeit, verschiedenem Debugging, ergibt sich:
- Fortinet hat einen offenen Bugreport zu dem Thema:
0922941 Connect to SSLVPN with FQDN resolved to both IPv4 and IPv6 as remote gateway, it got stuck at %98 percent
- für uns selbst haben wir den "Workaround" implementiert, auf Fortigate- und FortiClient-Seite den Dual-Stack-Modus für SSLVPN-Einwahlen zu aktivieren.
VPN " href="https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/766455" target="_blank" rel="noopener nofollow noreferrer">https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/766455
Damit schert sich der FortiClient nicht mehr um den Mismatch, dass er selbst denkt zu einer simulierten IPv6-Adresse zu verbinden, während die FortiGate aber nur eine IPv4-Verbindung sieht.
- "Workaround" in Anführungszeichen, dass Umstellung auf sauber durchkonfigurierten Dual-Stack ja für IPv6-Tauglichkeit und Zukunftsfähigkeit ohnehin ratsam ist (wenn auch bis jetzt nicht notwendig). Unabhängig von den Ergebnissen der Fortinet-Entwickler zu dem oben genannten Bug ist das Thema für uns erfolgreich gelöst, da der "Workaround" gleichzeitig den Soll-Zustand abbildet. (Das hat man auch nicht oft...)
Damit habe ich nun hoffentlich den aktuellen Sachstand zum Thema zusammengefasst. Ein Telekom-/T-Mobile-Problem an sich scheint es nicht zu sein, wenn es aber doch in jedem Fall seltsam ist, dass Meldungen zu dem Thema immer nur mit der DTAG -Implementation gemeldet wurden. Aber auch das braucht nicht mehr weiter beleuchtet zu werden.
Danke in die Runde,
Patrick
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 10 Monaten
Es wurden in der Vergangenheit bereits Kundenfälle in Bezug auf FortiClient und IPv6 untersucht und das Problem ist hierbei nicht unser Netz gewesen.
So, nach noch einmal ein bisschen Zeit, verschiedenem Debugging, ergibt sich:
- Fortinet hat einen offenen Bugreport zu dem Thema:
0922941 Connect to SSLVPN with FQDN resolved to both IPv4 and IPv6 as remote gateway, it got stuck at %98 percent
- für uns selbst haben wir den "Workaround" implementiert, auf Fortigate- und FortiClient-Seite den Dual-Stack-Modus für SSLVPN-Einwahlen zu aktivieren.
VPN " href="https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/766455" target="_blank" rel="noopener nofollow noreferrer">https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/766455
Damit schert sich der FortiClient nicht mehr um den Mismatch, dass er selbst denkt zu einer simulierten IPv6-Adresse zu verbinden, während die FortiGate aber nur eine IPv4-Verbindung sieht.
- "Workaround" in Anführungszeichen, dass Umstellung auf sauber durchkonfigurierten Dual-Stack ja für IPv6-Tauglichkeit und Zukunftsfähigkeit ohnehin ratsam ist (wenn auch bis jetzt nicht notwendig). Unabhängig von den Ergebnissen der Fortinet-Entwickler zu dem oben genannten Bug ist das Thema für uns erfolgreich gelöst, da der "Workaround" gleichzeitig den Soll-Zustand abbildet. (Das hat man auch nicht oft...)
Damit habe ich nun hoffentlich den aktuellen Sachstand zum Thema zusammengefasst. Ein Telekom-/T-Mobile-Problem an sich scheint es nicht zu sein, wenn es aber doch in jedem Fall seltsam ist, dass Meldungen zu dem Thema immer nur mit der DTAG -Implementation gemeldet wurden. Aber auch das braucht nicht mehr weiter beleuchtet zu werden.
Danke in die Runde,
Patrick
0
Uneingeloggter Nutzer
Frage
von