AW: Warum erfindet der Telekom-Mobilfunk-DNS einen IPv6 (AAAA) DNS-Eintrag, der real nicht existiert?

[#1]

Ü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

[#2]

@nocrgfi  schrieb:

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.

@nocrgfi  schrieb:

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.

@nocrgfi  schrieb:

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.

@nocrgfi  schrieb:

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".

[#3]

@lejupp  schrieb:

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".

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:

IPv6-Ziele erreicht man darüber nativ, 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.

Bei internet.telekom wären IPv6-Ziele genauso nativ erreichbar, für IPv4 muss weiterhin die Client-IP-Adresse umgewandelt werden (von RFC1918-Bereich in global routbare), aber weder muss die Ziel-IPv4-Adresse im Paket übersetzt werden noch muss DNS manipuliert werden.

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?

Aus meiner Sicht ist damit einseitig internet.v6.telekom mit Nachteilen behaftet, die internet.telekom nicht hat. Die Logik versteh ich also dann tatsächlich nicht.

[#4]

@nocrgfi  schrieb:

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.

@nocrgfi  schrieb:

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.

@nocrgfi  schrieb:

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".

@nocrgfi  schrieb:

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.

[#5]

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.

[#6]

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... 

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.

[#7]

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.

[#8]

die Telekom hat das alles dokumentiert:

https://telekomhilft.telekom.de/t5/Telekom-hilft-News/Neuer-IPv6-Zugang-zum-mobilen-Internet-im-Netz...

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.

[#9]

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.

[#10]

@lejupp  schrieb:

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.

[#11]

@nocrgfi  schrieb:

Die Fortigate ist das Zielsystem mit fester IPv4-Adresse.

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.

[#12]

---

@tschaefer1  schrieb:

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.

---

Das ist je nach Ansichtssache blöd / gut, denn das erlaubt es Fortinet, komfortabel den Schwarzen Peter der Deutschen Telekom zuzuschieben. Da scheint etwas "besonders" zu sein ggü. der Implementation in den anderen Ländern.

Alle Beiträge, auch international in Foren, beziehen sich bei dem genannten Problem immer nur auf "German mobile providers" (und ich vermute, ohne es aber zu wissen, da kann man auch durch Singular substituieren und es ist immer das D1-Netz gemeint....)

Dass ausdrücklich in anderen Ländern (gerade dem "Fortinet-Heimatmarkt" T-Mobile USA) dasselbe Problem auftaucht, habe ich noch nie gelesen und das kann auch eigentlich nicht sein, denn dann wäre dessen Lösung / Behebung tatsächlich ein pressierendes Problem für Fortinet. Ich kann ja als Hersteller nicht sagen, dass ich - egal bei welchem Mobilfunkprovider mit IPv6-only - meine VPN-Lösung nicht verwenden kann.

Na mal sehen, ob Fortinet selbst mehr Details hat. Wir haben da seit einigen Tagen schon ein entsprechendes Ticket offen.

[#13]

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.

[#14]

---

@nocrgfi  schrieb:

---

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.

[#15]

@tschaefer1  schrieb:

verpassen dem Fortigate eine richtige IPv6-Adresse, dann tritt das Problem der Hilfsadresse nämlich gar nicht ein

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.

[#16]

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)

[#17]

Guten Abend @nocrgfi ,

ich habe dich nicht vergessen, nur liegt leider noch keine Rückmeldung vor. Deswegen behalte ich mein Postfach im Auge und melde mich sobald es neues gibt wieder. 

Lieben Gruß

Diandra S.

[#18]

Guten Morgen @nocrgfi , 

ich hoffe du liest hier noch mit, auch wenn ich dich weiterhin um Geduld bitten muss. 

Das Ticket wird weiterhin bearbeitet und ich warte auf eine Rückmeldung der Kollegen, die ich an dich weitergeben kann. 

Schauen wir mal, was wird. 😉

Lieben Gruß

Diandra S.

[#19]

@Diandra S.  schrieb:

Guten Morgen @tschaefer1, 

Sollte das vielleicht an den ursprünglichen Fragesteller @nocrgfi gehen...?

[#20]

Hallo @lejupp, danke für den Hinweis, du hast absolut recht, da bin ich durcheinander gekommen. 

Ich korrigiere das einmal fix. 🤗😊

Lieben Gruß

Diandra S.

[#21]

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.

[#22]

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