Enterprise-WiFi, WLAN-Call, Sicherheit, DNS, Hürden, NAT-T und so weiter

Ich hatte zuletzt wieder Kollisionen mit WLAN-Call (Vodafone und O2 vermarkten das Feature mit WiFi-Calling). Die Kollision war eine typische „mal-eben“ Anfrage, was in Corporate und anderen Umfeldern i.d.R. nicht passt. Es wurde – wie so häufig – vom „bei meiner Fritzbox geht das ja auch“ – Szenario ausgegangen. Dennoch will ich das Funktionsprinzip verstehen und den Impact auf mein WiFi-Design kennenlernen. In diesem Fall hat auf Nachfrage die Telekom den Stein zum Rollen gebracht. Meinen Dank dafür an das hervorragende Social Media Team.

tl;dr: Die Anwendung passt nicht in alle Szenarien

Zunächst will ich feststellen, was „WLAN-Call“ überhaupt ist: Die GSMA (Viele-schlaue-Leute-Vereinigung) hat das Feature im „GAN“ (Generic Access Network) definiert, beschrieben u.a. unter diesem Link. Im speziellen macht der Client nichts anderes, als eine IPSEC-Verbindung (rot) zum IP-Mobile-Core aufzubauen und darüber Voice zu machen. Das typische WLAN ist dabei „untrusted“*, deswegen der Tunnel. Ziel der Sache ist, ein zu schwaches Signal durch WiFi als Träger zu ersetzen.

Der Nutzer kann das Feature – z.B. im iPhone – unter //Einstellungen/Mobilfunk/%Provider%/“WLAN-Anrufe“ aktivieren:

Das Telefon baut dann den Tunnel auf, innerhalb dieses Tunnels findet die Voice-Kommunikation statt. „Zuhause funktioniert’s“: In der Regel konfiguriert man wohl ausgehende Ziele in Heimplasten nicht und hat auch nur wenige Geräte. So kann man

500/UDP (IKE-Auth)
4500/UDP (NAT-T, verschlüsselt)

gleich erreichen. Sicher ist, wer Perimetersicherheit betreibt, hat weder Perimeter noch Sicherheit – dennoch rollen sich bei manchen, in so einem Szenario verständlicherweise die Tapeten auf.

Aus gleich mal 3 Gründen, die ich hier erläutern will:

WLAN

Voice und Data beissen sich im WiFi übelst. Wenn eine solche Leistung nicht im Vorfeld adäquat geplant wurde, ist der Störfall default. QoS in der üblichen Form gibt’s nicht, sondern WMM (Link). Diese Briefmarke wird gleich auf eine ganze Zelle gekleistert – jene Du optimalerweise für Voice exklusiv aufmachst. Jeder Hersteller setzt das unterschiedlich um (Link), die Features sind aber überall identisch, die Anwendung definiert dann die Prio. Problem dabei: SIP/RTP ist in IPSec eingepackt, und das wird dann nicht mehr mit der WMM-Briefmarke „AC_VO“ markiert. Wenn Du dann auch kein k/r/v anbietest, wird das Roaming mit WLAN-Call eher zum Glücksspiel. In diesem Fall verhält sich Voice also nicht einmal wie Voice.

Daten in derselben Zelle, zusammen mit Voice passen auch nicht, besonders in VHD-Umgebungen, z.B. Veranstaltungen oder Schulen – Das Endgerät ist typischerweise BYOD. Wir müssen – mit Verlaub – in Company-Netzen oder auch in der Bildung asapst dafür sorgen, dass die Pakete transportiert werden, um die Zelle freizubekommen. Diese Endgeräte machen jetzt alle nicht nur ab und an Hintergrundsynchronisation, sondern tunneln permanent nach draussen.

Rechtlich problematisch kann’s werden, wenn Notrufe eine Rolle spielen. Ferner ist für Voice secondary coverage elementar wichtig (Roaming + Features wie oben), eine ganz andere Planung, adäquate Einmessung (nach Bereitstellung) und eine passende Authentifizierungsmethode (Cisco-Deutsch z.B. EAP-FAST).

Ausserdem sind richtige Schnitte notwendig, so dass ein Handover von WLAN nach VoLTE z.B. beim Verlassen des Gebäudes möglich ist. Da WLAN in meinen Szenarien allerdings primär für „andere Dinge“, also Daten, entworfen wird als Voice, ist das Thema WLAN-Call schon im Anfangsstadium begraben.

Einschub Capacity

Dankeschön an die Telekom: Für die Kommunikation plant man mit 100 kbit/s an Verkehrsdaten bei einem Gespräch, inkludiert dabei schon den ipsec-Overhead. Keepalive ist auch da, wie oben erwähnt störend, aber nur ein Bruchteil. Die Takerate dieses Dienstes ist nicht kalkulierbar, es gibt keine Erfahrungswerte. Je nach Einzugsgebiet haben Schüler entweder die neuesten Geräte oder nicht. Ich sehe als Client im Schnitt bei 75% aktuelle Geräte, welche das Feature unterstützen können. Ich kann allerdings nicht sagen, ob die Nutzer z.B. aktuelle Tarife haben, die das Feature unterstützen.

Fehlendes Connection Tracking/NAT-T

Manch Heimplaste kommt mit 3-6 Geräten noch klar, will aber hier und da schon wieder mit dem Pakete-Würfeln anfangen. Rückläufiges, verschlüsseltes NAT-T (UDP4500) muss dem Client an der Firewall wieder beisortiert werden. Das klappt zwar mit 1-5 Geräten, allerdings wird’s danach (selbst bei mir zuhause) schon knapp. Von 10 Geräten kann ich ohne dynamisches Filtern/“Conntrack-Modul“ nur träumen. Die Versorgung von in meinen Szenarien typischen 1200 Clients ++ – ohne adäquates Equipment – ist da schon eher utopisch.

Lancom scheitert am Beisortieren eines ipsec-Paketes von Vodafone

In meiner kleinen „Testumgebung“ klappt NAT-T bei Telekom und Telefonica. Bei Vodafone scheitere ich mit bislang allen iOS-Endgeräten, mit aktuellem Betriebssystem. Das Verhalten der Carrier ist wohl auch hier nicht einheitlich.

Sicherheit (einzugrenzen)

Ungern will man – ohne Zieldefinition – ipsec ausgehend global aufmachen. Also ist notwendig, zu wissen, welche Ziele gefahrlos erreicht werden sollen. Ich kann – mit Verlaub – wirklich jeden Firewall-Administrator verstehen, der scheut, diese Kommunikation ohne Zieleinschränkung zu erlauben. Auch in diesem Fall springt die Telekom bei und eröffnet mir den Weg zu allen notwendigen Informationen:

Telekom’s Rückmeldung zum Thema

Hier will die Telekom hin:

epdg.epc.mnc001.mcc262.pub.3gppnetwork.org

mcc262 = Deutschland

mnc001 = Telekom
mnc002 = Vodafone
mnc003 = Telefonica/O2, tritt auch mal als Viag-Interkom oder Drillisch auf oder ein anderer Carrier, mangels Fachwissen in der Materie für mich nicht eindeutig.

Das war übrigens auch der springende Punkt, der die restlichen Recherchen für mich vereinfacht hat. Der Rest – inklusive Diagnose – erschloss sich quasi aus dieser einen URI, via Google in hunderten von Blogs, wie diesem hier.

Das Szenario nachbauen

Die komplette Liste aller Carrier hierzulande findest Du im übrigen hier, bei Wikipedia: Link. Ich will dann für Dich kurz meinen Lancom missbrauchen, um einen einfachen Weg zu skizzieren, wenn Du das in kleinen Rahmen einsetzen willst. Dazu verwende ich die Layer-7 Anwendungserkennung und lege in DNS-Ziele wie folgt an:

*.mcc262.pub.3gppnetwork.org

Anschließend definiere ich in einer Firewallregel folgende Ziele für UDP 4500 und 500:

DNS

Damit sollten alle Carrier in Deutschland erwischt sein. Problematisch wird’s aber bei manchen Resolvern. Wenn Du z.B. Google verwendest, wirst Du die Ziele nicht adäquat auflösen können. Helfen kann – sofern der typische Resolver nicht will – eine bedingte Weiterleitung, beispielsweise zum Cloudflare-DNS:

Problematisch können auch einige Kisten mit eingebautem SBC sein, welche für Voice-Priorisierung Pakete zerhackstücken, PMTU Reduzierungen durchführen, usw.. Die Features befinden sich bei Lancom u.a. unter //Voice Call Manger/Erweitert/Quality of Service:

Problematische Defaultkonfiguration für IPSEC

Allerdings gibt’s hier und da auch noch andere Fallstricke, wie z.B. jenes Ding hier (Link) mit Watchguard. Manche Anschlüsse, welche z.B. CGN/Carrier-Grade-NAT bereitstellen, können da wohl auch eher selten mit umgehen. Ich wusste übrigens bis vor kurzem noch nicht einmal, dass wir so etwas am linken Niederrhein schon haben – Danke an meinen Kollegen Peter für die Erklärung. Noch blöder ist die Kiste mit 2 aktiven WLAN-Call-Diensten (Dual-Sim) auf einem Endgerät. Einer verliert immer:

Für die weiteren Szenarien, besonders im Umfeld von Enterprise WiFi, bedarf das einer Detailplanung und adäquater Hardware. Es passt aber eben auch nicht in jedes Szenario. Ich kann mir deshalb auch vorstellen, dass ein guter Dienstleister dieses Szenario ablehnen wird. Vielleicht hilft 6E weiter, weil wir mehr Platz haben, so ganz ist dieses Ding eben auch noch nicht gereift.

Fazit: Mal eben kannst Du vergessen.

Tschüs.
John

Titelbild: Pixabay, Sammy-Williams

*Ich kann mir gut vorstellen, dass das mit „Telekom_SIM“ (EAP-SIM) wohl einfacher läuft – (Trusted WiFi/TWAG), dieser Gedanke ist aber noch nicht fertig recherchiert, da in meinen Szenarien nicht umsetzbar/relevant.