Solved
Warum erfindet der Telekom-Mobilfunk-DNS einen IPv6 (AAAA) DNS-Eintrag, der real nicht existiert?
1 year ago
Ü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
656
23
This could help you too
in
478
0
2
4 years ago
2377
0
2
3602
1
2
362
0
3
5 years ago
1059
2
1
Accepted Solution
accepted by
10 months ago
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