Zum Inhalt springen

WiFi-Calling, Evolved Packet Data Gateway und Google DNS

Im Rahmen meiner VPN-Aktivitäten musste ich leider feststellen, dass mein iPhone bei aktivem WireGuard VPN kein WiFi-Calling mehr durchführt. Hierbei wird normalerweise ein IPSec-Tunnel zum Provider aufgebaut, über den dann ausschliesslich Telefonie-Dienste laufen und der vor dem Benutzer „verheimlicht“ wird. Auf iOS ist das ganze auf eine simple „ein/aus“-Option reduziert und vermutlich abhängig vom Providerprofil und der SIM-Karte.

Die technische Grundlage dafür ist im 3GPP-Standard festgelegt und wird z.B. hier näher beschrieben. Der Abschnitt „Untrusted 3GPP Wi-Fi access“ beschreibt den Anwendungsfall. Wer es ganz offiziell und ausführlich mag, wird hier fündig.

Interessanterweise sind die VPN-Endpunkte schön via DNS zu ermitteln, einfach den MCC und die MNC für das gewünschte Netz anpassen und abfragen (Link zum GSMA-Standard IR.67). Hier das Beispiel Vodafone (002) Deutschland (262):

➜  ~ dig epdg.epc.mnc002.mcc262.pub.3gppnetwork.org       
…
;; ANSWER SECTION:
epdg.epc.mnc002.mcc262.pub.3gppnetwork.org. 45 IN CNAME	epdg.epc.drz1.vodafone-ip.de.
epdg.epc.drz1.vodafone-ip.de. 45 IN	A	139.7.117.161
epdg.epc.drz1.vodafone-ip.de. 45 IN	A	139.7.117.162
…

➜  ~ dig NS drz1.vodafone-ip.de
…
;; ANSWER SECTION:
drz1.vodafone-ip.de.	9600	IN	NS	drns1.vodafone-ip.de.
drz1.vodafone-ip.de.	9600	IN	NS	drns2.vodafone-ip.de.
drz1.vodafone-ip.de.	9600	IN	NS	drns3.vodafone-ip.de.

➜  ~ dig +short drns{1,2,3}.vodafone-ip.de
145.253.3.32
145.253.3.34
145.253.3.36

Nutzt man die Resolver von Google DNS (8.8.8.8 und 8.8.4.4) erhält man bei Vodafone keine Antwort, über Cloudflares 1.1.1.1-Service hingegen schon. Einige Nutzer wollen vom Vodafone-Service die Aussage erhalten haben, dass Wifi-Calling „nur in Deutschland“ möglich sei…

Per tcpdump habe ich also mal meinen eigenen DNS-Server abgehört (tcpdump -nt -i <interface> udp port 53 and inbound) und requests über 1.1.1.1 und 8.8.8.8 gestellt. Erstaunlicherweise kamen die Requests der Cloudflare Resolver immer per IPv6 an, die von Google immer per IPv4. In der RIPE bzw ARIN DB ist für die verwendeten IP-Adressen als Land USA vermerkt, wohingegen ein IPv6-Geolookup bei Maxmind und KeyCDN explizit München als Standort ausgab. Das könnte also erklären, warum WiFi-Calling mit den Cloudflare Resolvern funktioniert und mit Google DNS nicht.

Interessanterweise sind die IPSec-Endpunkte bei Vodafone IPv4-only, der dann darüber aufgebaute Tunnel hingegen ist schon IPv6-only. Mit der iOS App von Hurricane Electric sieht man die Interfaces:

Das IPv6-Netz „2a00::/22“ ist Vodafone zugeteilt.

Über den Tunnel wird dann wohl SIP gefahren.

Letztlich hatte WireGuard damit also nichts zu tun, bis auf die Tatsache, dass ich dort die Google Resolver konfiguriert hatte und hier zuhause im WiFi eben die von Cloudflare…

PS: Ob man mittels DNS MITM eine Fake-IPSec-Gegenstelle simulieren kann, der zum Tunnelaufbau Zertifikate egal sind? Dann könnte man eventuell auch SIP-Register-Requests sniffen?

PPS: War schon jemand schneller… 

An attacker can set up his own IPSec server to impersonate the ePDG server, which would be capable of participating
in the IMSI authentication process. Consequently, the attacker can
acquire users’ IMSI information.


… dem IPsec-Handshake kriegt man wohl nicht hin, aber offensichtlich steht die IMSI auch schon im Schlüssel als Attribut drin. Man kriegt also nicht die Telefonnummer oder gar SIP-Traffic zu sehen.

PPS: Trotz dnsmasq-Umleitung der besagten Zone über einen deutschen Resolver, konnte ich keine Verbindung aufbauen. Lookups funktionieren und auch auf Port 500 UDP erhält man eine Antwort, trotzdem klappt der Wifi-Calling-Tunnel nicht. Bleibt also nur entweder ein Gateway in Deutschland zu betreiben oder schon auf dem iPhone das besagte Vodafone-Subnetz um WireGuard herumrouten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

* Die DSGVO-Checkbox ist ein Pflichtfeld

*

Ich stimme zu