Ezekiel1989

Muss das deaktiviert sein, damit ich beim FaceTimen in 5G SA geschalten werde? 

@Ezekiel1989 

Nein, FaceTime läuft nicht über PR.

Apple: "iCloud Privat-Relay wurde entwickelt, um deine Privatsphäre zu schützen, indem es sicherstellt, dass beim Surfen mit Safari niemand – nicht einmal Apple – erkennen kann, wer du bist und welche Websites du besuchst."

Hallo @Ezekiel1989,

grundsätzlich ist es so, dass iCloud Private Relay technisch ähnlich wie ein VPN funktioniert und deinen Datenverkehr über externe Server leitet, wodurch deine IP-Adresse für das Mobilfunknetz nicht mehr eindeutig zugeordnet werden kann. Genau das war damals auch der Grund, warum es bei Optionen wie StreamOn zu Problemen kam, weil bestimmte Datenströme nicht mehr korrekt erkannt werden konnten.

Für 5G SA und FaceTime ist die Situation aber etwas anders: Die Einbuchung ins 5G-SA -Netz hängt nicht davon ab, ob du FaceTime nutzt oder nicht, sondern vielmehr von deinem Tarif, deinem Gerät und der Netzverfügbarkeit. FaceTime selbst schaltet dich also nicht aktiv in 5G SA.

Allerdings kann aktiviertes Private Relay indirekt Einfluss haben, weil sich durch das veränderte Routing und die Verschleierung deiner Verbindung die Netzoptimierung anders verhält. Das kann sich zum Beispiel in leicht höherer Latenz oder einer weniger stabilen Verbindung bemerkbar machen, betrifft aber nicht speziell die Aktivierung von 5G SA an sich. Unterm Strich heißt das: Du musst iCloud Private Relay nicht zwingend deaktivieren, um beim FaceTimen im 5G-SA -Netz zu sein. Wenn du aber merkst, dass die Qualität oder Stabilität nicht optimal ist, kann es sinnvoll sein, Private Relay testweise auszuschalten, weil die Verbindung dann oft direkter und stabiler läuft.

Liebe Grüße

Maria

Maria An.

Für 5G SA und FaceTime ist die Situation aber etwas anders: Die Einbuchung ins 5G-SA -Netz hängt nicht davon ab

Die Einbuchung in ein Mobilfunknetz hängt nie von einer Anwendung auf einem Mobile Device ab !

Die Freischaltung der SIM ( IMSI ) steuert die Einbuchung.

@VonderWulf 

Nö, ist nicht normal.

ich hab die Ultra Option auch gebucht (hatte vorher auch die Gaming Option aktiv) und es sieht so aus wie vorher auch.

Haste dein iPhone mal neu gestartet, nachdem du die Mail bekommen hast, dass die Option gebucht wurde und eingerichtet ist?

Optimus Prime

@VonderWulf 

Nö, ist nicht normal.

ich hab die Ultra Option auch gebucht (hatte vorher auch die Gaming Option aktiv) und es sieht so aus wie vorher auch.

Problem ist behoben :) 

Einmal das Gerät neu gestartet und das Problem ist behoben 

Hatte ich vorher auch schon gemacht da hat es wohl aber nicht geholfen

Ich habe die Option nun gebucht und in meinem Setup iPhone 17 Pro und Nighthawk M6 scheint es zu funktionieren - mein Router bekommt auch Netz. 

An die anderen die bereits gebucht haben, was habt ihr für Erfahrungen gemacht und habt ihr auch MultiSIM im Einsatz? 

• ich hatte bisher zwei Neustarts vom iPhone und es hat jeweils sehr lange gedauert bis ich ins Netz eingebucht war.
• Auch im aktiven FaceTime konnte ich bisher noch nicht feststellen, dass ich in 5G SA bin - passiert das nur bei "Überlastung" im NSA Modus oder sollte das allgemein funktionieren? 

Hallo zusammen,

ich möchte mich noch einmal in diesen Thread einklinken. Ich hatte hier damals bereits über mein Galaxy S25 Edge, meine MultiSIM-Konstellation und die FRITZ!Box 6860 5G berichtet.

Damals funktionierten 5G + Ultra, 5G Standalone und VoNR bei mir problemlos. Seit der Rufnummernportierung in der Nacht zum 01.10.2026 hat sich das geändert.

Chronologie

Mein freenet MagentaMobil XL Unlimited im Telekom-Netz war bereits einige Wochen vor der Portierung aktiv. Für diese Übergangszeit hatte ich von freenet zunächst eine temporäre Rufnummer erhalten.

Mit dieser vorläufigen Rufnummer funktionierte 5G SA sowohl auf meinem Galaxy S25 Edge mit MultiSIM als auch auf meiner FRITZ!Box 6860 5G .

Die Haupt-eSIM befindet sich dabei auf einem EIOTCLUB-eSIM-Adapter mit eigener eUICC, der im Nano-SIM-Slot der FRITZ!Box steckt. Die FRITZ!Box selbst besitzt keine integrierte eSIM.

In der Nacht zum 01.10.2026 wurde dann meine bisherige Rufnummer von spusu zu freenet portiert und ersetzte die temporäre freenet-Rufnummer.

Bis unmittelbar vor der Portierung funktionierte 5G SA einschließlich mobiler Daten. Seit Abschluss der Portierung funktioniert die normale Datenverbindung im 5G-SA -Betrieb nicht mehr.

Ich möchte damit nicht behaupten, dass die Portierung zwingend die Ursache ist. Der unmittelbare zeitliche Zusammenhang ist aber auffällig.

Technische Eckdaten

Vertrag

• freenet MagentaMobil XL Unlimited
• Telekom-Netz
• 5G + Ultra aktiv
• Haupt-SIM plus MultiSIMs
• APN :

  internet.v6.telekom

FRITZ!Box

• FRITZ!Box 6860 5G
• Quectel RG520N-EU
• Haupt-eSIM über EIOTCLUB-eSIM-Adapter

Smartphone

• Samsung Galaxy S25 Edge
• MultiSIM desselben Vertrags

Fehlerbild

An der FRITZ!Box wird 5G SA weiterhin erreicht. In den Supportdaten erscheint ausdrücklich:

rat 5G Standalone

Beim anschließenden Aufbau der Datenverbindung kommt jedoch:

QWDS_START_NETWORK_INTERFACE

bzw.

error(b,8007010e,connecting) = 3;509;QWDS_START_NETWORK_INTERFACE

Danach folgen Drop und Neuinitialisierung des Mobilfunkteils.

Mit deaktiviertem 5G SA funktioniert die Verbindung über LTE + 5G NSA dagegen stabil.

Ein vollständiger Ersatz der Haupt-eSIM bei freenet hat daran nichts geändert.

Inzwischen lässt sich das Problem auch mit der MultiSIM im Galaxy S25 Edge reproduzieren.

Bei NR only zeigt das Gerät:

• Current Network:

  Telekom.de

• Data Network Type:

  NR_SA

• Data Raw Registration State:

  HOME

• Voice Network Type:

  NR_SA

• Voice Raw Registration State:

  HOME

• Data Service:

  Disconnected

Gleichzeitig ist IMS registriert:

IMS Registration: Registered

Und Telefonie funktioniert in diesem Zustand auch ohne WLAN. VoNR scheint also weiterhin zu funktionieren, während die normale mobile Internetverbindung fehlt.

Sobald ich wieder auf NR/ LTE umstelle, funktioniert die Datenverbindung sofort wieder über LTE + 5G NSA.

Meine konkrete Bitte zur technischen Prüfung

Da sich das Endgerät erfolgreich mit

NR_SA

und

HOME

registriert und auch IMS /VoNR funktioniert, würde ich gerne gezielt klären lassen, warum ausschließlich die normale Internet-Datensitzung im 5G-SA -Betrieb nicht aufgebaut wird.

Falls das Telekom-hilft-Team den Vorgang an die zuständige Netztechnik weitergeben kann, wäre insbesondere eine Prüfung folgender Punkte hilfreich:

• Ist für den Anschluss und die betroffenen SIMs die 5G-SA -/5GC-Berechtigung vollständig und konsistent provisioniert?
• Ist der DNN/ APN

  internet.v6.telekom

  im 5G -Core für die normale Default-Datensitzung korrekt freigeschaltet?
• Wird beim Versuch, im SA-Netz die Default-PDU-Session für den Internetzugang aufzubauen, netzseitig ein Reject oder ein Fehlercode erzeugt?
• Falls ja: Welcher 5GSM-/PDU-Session-Cause-Code wird dabei zurückgegeben?
• Ist nach der Rufnummernportierung möglicherweise ein veraltetes oder inkonsistentes Teilnehmer-/Datenprofil bestehen geblieben?
• Sind Haupt-SIM und MultiSIMs im 5G -Core weiterhin korrekt demselben Vertrags- und Datenprofil zugeordnet?
• Kann das Teilnehmerprofil einschließlich der 5G-SA -Datenberechtigung beziehungsweise des PDU-Session-Profils neu provisioniert bzw. vollständig neu synchronisiert werden?

Besonders wichtig wäre mir dabei, dass nicht nur geprüft wird, ob sich die SIM grundsätzlich in 5G SA registrieren darf – das funktioniert offensichtlich –, sondern ausdrücklich der anschließende Aufbau der normalen Internet-PDU-Session untersucht wird.

Das Fehlerbild lässt sich sehr klar nachstellen:

NR only → NR_SA / HOME → IMS registriert / VoNR funktioniert → Data Service bleibt „Disconnected“

und unmittelbar danach:

NR/ LTE → LTE + NR_NSA → Data Service „Connected“

Vor der Rufnummernportierung funktionierte auch die SA-Datenverbindung mit demselben Vertrag und demselben APN .

Daher wäre insbesondere interessant, ob sich in den Netzlogs zum Zeitpunkt eines solchen Verbindungsversuchs erkennen lässt, an welcher Stelle der PDU-Session-Aufbau abgelehnt oder abgebrochen wird.

Falls zur Eingrenzung hilfreich, kann ich einen solchen Test zu einem abgesprochenen Zeitpunkt durchführen und zusätzlich FRITZ!Box-Supportdaten, Screenshots sowie Android-/ADB-Logs bereitstellen.

Wireguard5GDeluxe

Falls zur Eingrenzung hilfreich, kann ich einen solchen Test zu einem abgesprochenen Zeitpunkt durchführen und zusätzlich FRITZ!Box-Supportdaten, Screenshots sowie Android-/ADB-Logs bereitstellen.

Warte hier auf ein Teamie  -> @Telekom hilft Team

Bitte das Profil ausfüllen mit Rückrufnummer, wenn nicht schon erledigt.

Vielleicht kann die Fachabteilung dir helfen.

Ansonsten treten immer Probleme mit der FB auf, weil sie kein 464XLAT unterstützt, wenn sie nur eine IPv6-Adresse bekommt.

Das fehlende 464XLAT der FRITZ!Box ist mir bekannt. Dafür habe ich inzwischen allerdings eine andere Lösung im Heimnetz – ohne WireGuard, WARP oder einen sonstigen IPv4-Tunnel.

Mein Telekom- 5G-SA -Anschluss läuft bei mir IPv6-only. Im Heimnetz betreibe ich auf einem Linux-Hauptserver (

192.168.178.20

) einen eigenen DNS64-Resolver auf Basis von dnsmasq.

Als DNS64-Upstream werden IPv6-DNS64-Resolver verwendet. Bei einem Ziel, das selbst nur einen A-Record besitzt, wird dadurch eine synthetische AAAA-Adresse aus dem NAT64-Präfix

64:ff9b::/96

erzeugt.

Vereinfacht läuft das dann so:

Client → DNS64 auf dem Hauptserver → synthetische 64:ff9b::/96-Adresse → native IPv6-Verbindung über die FRITZ!Box → NAT64/PLAT im Telekom-Netz → IPv4-Ziel

Wichtig dabei: Der Hauptserver ist hierbei kein Tunnel-Gateway. Der eigentliche Nutzdatenverkehr läuft nicht über WireGuard oder Cloudflare WARP und wird auch nicht vom Hauptserver auf IPv4 genattet. Er läuft als IPv6-Verkehr direkt über die FRITZ!Box und das Telekom-Netz. Der Hauptserver übernimmt lediglich die DNS64-Auflösung.

Dass DNS64 funktioniert, lässt sich beispielsweise auch an

ipv4only.arpa

erkennen; dabei werden Adressen aus

64:ff9b::/96

erzeugt.

Das ist zwar technisch nicht dasselbe wie ein echtes 464XLAT /CLAT direkt in der FRITZ!Box – insbesondere Anwendungen mit fest eingetragenen IPv4-Literalen können damit weiterhin problematisch sein –, für normale per DNS erreichbare IPv4-only-Ziele funktioniert bei mir aber DNS64/NAT64.

Vor allem erklärt das meines Erachtens das jetzige Problem nicht: Diese Konfiguration bestand bereits, als 5G SA mit der temporären freenet-Rufnummer noch funktionierte.

Aktuell kommt es außerdem schon eine Stufe vorher zum Fehler. Beim Galaxy S25 Edge sehe ich bei

NR only

:

NR_SA / HOME

IMS Registration: Registered

Voice: NR_SA

Data Service: Disconnected

VoNR-Telefonie funktioniert dabei sogar, die normale Internet-Datensitzung aber nicht.

Auch die FRITZ!Box erreicht nachweislich

5G Standalone

, scheitert anschließend jedoch beim Aufbau der Datenverbindung.

Deshalb sehe ich das fehlende 464XLAT der FRITZ!Box hier eher als separates Thema. Das aktuelle Problem scheint bereits beim Aufbau der normalen 5G-SA -PDU-Session zu entstehen – und tritt zusätzlich auch auf dem Galaxy S25 Edge auf, bei dem die FRITZ!Box und deren fehlendes 464XLAT überhaupt keine Rolle spielen.