Teams RTC und VPN

Wussten Sie schon, dass sich Teams nicht an ein Tunnel.VPN hält?. Das kann gut sein, muss es aber nicht.

Audio/Video mit WebRTC

Ich möchte hier nicht allzu tief auf den Handshake bei Audio/Video-Verbindungen eingehen sondern verweise hier auf die Seite ICE, Kandidaten, STUN und TURN u.a. Aber soviel sei gesagt: Microsoft Teams nutzt natürlich auch den Handshake per ICE um einen Kommunikationskanal zum anderen Gesprächspartner aufzubauen. Teams ermittelt seine direkten Kandidaten, die externe IP-Adresse des NAT-Routers und leiht sich vom TURN-Server einen Kandidaten. Dieses "Angebot sendet er an die Gegenseite.

Umgebung

Mit einem Tunnel-VPN wäre ja nun zu erwarten, dass der Teams Client alle Pakete durch den Tunnel in die Firma sendet und quasi aussieht, als wenn er ein "Firmenanwender" ist. Ich habe daher eine kleine Testumgebung konfiguriert:

  • Firma mit VPN-Server
    Rechts sehen Sie das Firmennetzwerk, welches mit einer Firewall natürlich ans Internet angebunden ist. Der VPN-Server hat eine private Adresse und ist per IPv4 erreichbar. Die Firewall erlaubt aber auch ausgehends NAT für die Client über UDP, so dass die Firmenclients wie PC3 zum Teams TURN-Server in der Cloud nicht durch einen HTTP-Proxy müssen
  • PC1 ist mein Desktop im Homeoffice, weicher eine VPN-Verbindung zur Firma aktiv hat. Es ist das klassische "Windows DialUp-VPN" mit Tunnelkonfiguration
  • PC2 ist ein zweiter Desktop im Homeoffice ohne VPN, auf dem ein anderer Teams-Benutzer angemeldet ist.
  • PC3 ist ein Firmenrechner ohne VPN

Genau genommen könnte ich das Testfeld noch um einen Session Border Controller in der Firma erweitern und einen Client an einem anderen Internet-Standort ohne VPN. Vielleicht erweitere ich das Testfeld später noch einmal

Konfiguration PC1 mit Tunnel-VPN

Entsprechend der Beschreibung habe ich meine Konfiguration auf dem PC geprüft. Das VPN wurde verbunden.

C:\> rasdial
FirmenVPN
Der Befehl wurde erfolgreich ausgeführt.

Analog hat Windows auch die Leitwege konfiguriert. mein "Default Gateway" geht über den VPN-Server.

C:\> route print
===========================================================================
Schnittstellenliste
116...........................FirmenVPN
 44...8c 16 45 70 a0 ef ......Intel(R) Ethernet Connection (4) I219-V
 39...66 ff c3 6f 37 60 ......Intel(R) Dual Band Wireless-AC 8265
  1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.178.1   192.168.178.91     25
      80.66.20.28  255.255.255.255    192.168.178.1   192.168.178.91     26
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      169.254.0.0      255.255.0.0   Auf Verbindung    169.254.155.68    271
....

Der Boden ist bereinigt. Aber die Prüfung meiner "öffentlichen IP" zeigt, dass hier was nicht passt.

Ich hätte erwartet, dass mein Client nun durch das VPN in die Firma geht und dort per NAT dann nach auf die Server im Internet zugreift und daher die öffentliche IP-Adresse der Firma erscheint. Hier erscheint aber mein ISP. Ich habe also erst noch einmal der VPN-Verbindung genauer auf die Finger geschaut.

PS C:\> Get-VpnConnection firmenVPN

Name                  : FirmenVPN
ServerAddress         : vpn.msxfaq.de
AllUserConnection     : False
Guid                  : {41DB17EB-AE0A-4493-9065-AF8CE5B72078}
TunnelType            : Sstp
AuthenticationMethod  : {MsChapv2}
EncryptionLevel       : Required
L2tpIPsecAuth         :
UseWinlogonCredential : True
EapConfigXmlStream    :
ConnectionStatus      : Connected
RememberCredential    : False
SplitTunneling        : True
DnsSuffix             : msxfaq.de
IdleDisconnectSeconds : 0

Hier sehen Sie gut, dass SplitTunneling auf True gesetzt ist. Und auch in der GUI findet sich in den Tiefen die entsprechende Checkbox.

Also habe ich diese Checkbox gesetzt und den Test wiederholt. Damit sieht das dann wie erwartet aus.

Nun kann ich mit Teams und WireShark auf dem Kabel nachschauen.

Achtung:
Die Betrachtung der Verbindung erfolgt auf dem LAN-Adapter aber verrät nicht, ob das Paket nun durch das VPN oder dran vorbei gelaufen ist. Aber das VPN nutzte IPHTTPS, was im WireShark sehr einfach zu erkennen ist.

Call1: Gleiches LAN

Zuerst hat PC1 eine Verbindung zu PC2 aufgebaut, indem ich mit meinem Net at Work Konto ein andere Konto in einem anderen Tenant angerufen habe. Beide Computer waren aber in meinem Heimnetzwerk und haben durch die Fritz!Box eine IP-Adressen in 192.168.178.x bekommen. Am Anfang sehe ich natürlich all die UDP-Paket zu den verschiedenen Endpunkten.

Aber nachdem dann der Anruf angenommen wurde, habe ich genau eine UDP-Verbindung gesehen, die auch recht einfach in den "Conversations" zu finden war.

Sie sehen hier eine direkte Verbindung zwischen meinen PC1 (192.168.178.91) und dem PC2 (192.168.178.89).

Das war so aber auch zu erwarten, dass zwei PCs im gleichen Subnetz immer direkt miteinander kommunizieren, selbst wenn ein PC ein VPN auf hat. Daher kann mein PC1 trotz VPN auch noch einen Drucker im gleichen Subnetz erreichen.

Call2: VPN zu Firma

Der zweite Fall war schon interessanter. Ich habe von PC1 einen Kollegen in der Firma unter PC2 angerufen, der über VPN erreichbar gewesen ist. WireShark zeigt, dass die aktive Sprachübertragung (viele kleine Pakete), über IPHTTPS getunnelt wird:

Damit geht die Verbindung durch das VPN und nicht dran vorbei über den TURN-Server oder STUN und Firewalls.

Hier dann noch mal die Gegenprobe mit "SplitVPN". Das Verhalten hier finde ich dann aber bemerkenswert da mein Client nun mit der externen IP der Firewall spricht und anscheinend "STUN" hier einer direkten Verbindung vorgezogen wird.

Das ist natürlich von Vorteil, weil der Weg von meinem Client zur Firewall statt zum VPN-Server zwar identisch ist, aber der VPN-Overhead nicht anfällt. Der Client sendet hier UDP-Pakete.

Als letzten Test habe ich dann dann VPN komplett beendet und Teams hat dann den Weg über die zweite offizielle IP-Adresse und STUN der Firewall gewählt. Der PC3 konnte ja ausgehend per UDP einen Port öffnen, auf den ich dann auch senden konnte. Auf meinem Client sehe ich natürlich nur den Verkehr mit den IP-Adressen in Homeoffice.

Hätte ich auch auf dem WAN-Interface des NAT-Routers nachgeschaut, wäre hier meine 192.168.178.91 durch meine extern Adresse ersetzt worden. Da ich aktuell über "Glasfaser in Hövelhof angebunden bin und daher FTTH mit IPv6 nutze aber die Gegenstelle gerade kein IPv6 angeboten hat, dürfte auf dem Weg die Adresse noch ein weiteres Mal per Carrier Grade NAT (CGNAT) umgeschrieben worden sein.  Auch in der Konversationen war zu sehen, dass mein Client eine öffentliche IP-Adresse (217.91.247.140) der Firmen-Firewall angesprochen hat.

Der Teams Client hat hier die etablierte VPN-Verbindung ignoriert und stattdessen das STUN-Angebot der anderen Seite angenommen.

Call 3: mit externem Kollegen

Zufällig habe ich dann noch einen Anruf mit einem Kollegen mitschneiden können, der ebenfalls im Homeoffice war. Er hatte auch ein VPN (Direct Access) gestartet, aber das habe ich bei mir erst einmal nicht gesehen. Denn auch hier hat mein Client alle Pakete durch das VPN gesendet

Auch hier habe ich noch mal die Gegenprobe gemacht. Ohne VPN hat man Client die Pakete direkt eine DSL-Adresse der Telekom gesendet.

Das Subnetz 91.58.32.0/22 gehört zum AS3320 der Telekom

Call4: PSTN-Telefonat SBC

Das letzte Szenario galt einem Telefonat mit einer klassischen Telefonnummer. Mein Client muss dazu "irgendwie" den Weg zum SBC in der Firma finden, der die Brücke zum Telefonnetz darstellt. Hier gibt es nun zwei Optionen:

  • Ohne Media Optimization
    Client durch VPN in die Firma und dann in die Cloud um von dort wieder zum SBC zurück zu kommen
  • Mit Media Optimization
    Client durch VPN in die Firma direkt zur Public-IP des SBC

In beiden Fällen geht der Client natürlich "durch" das VPN und daher sehe ich in WireShark nicht wirklich den zweiten Teil der Verbindung. Um hier Klarheit zu bekommen, muss ich entweder auf dem VPN-Server oder dem SBC schauen, von welcher Source-IP die Pakete ankommen oder ich schaue mir die SIP-Meldungen des SBC an, welche Kandidaten letztlich bestimmt wurden.

INVITE sip:+49525793xxxx@sbc.msxfaq.de:5061;user=phone;transport=tls SIP/2.0 
FROM: "TestUser"<sip:+495251304xxx@sip.pstnhub.microsoft.com:5061;user=phone>;tag=xxx 
TO: <sip:+49525793xxxx@sbc.msxfaq.de:5061;user=phone> 
CSEQ: 1 INVITE 
CALL-ID: xxx 
MAX-FORWARDS: 70 
VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bKe3b14855 
RECORD-ROUTE: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr> 
CONTACT: <sip:api-du-c-euwe.pstnhub.microsoft.com:443;x-i=cff7f976-adca-42ab-a053-2e268dcb6a09;x-c=xxx> 
CONTENT-LENGTH: 1093 
MIN-SE: 300 
SUPPORTED: timer 
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.8.9.1 i.EUWE.5 
CONTENT-TYPE: application/sdp 
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY 
P-ASSERTED-IDENTITY: <tel:+495251304xxx>,<sip:testuser@msxfaq.de> 
PRIVACY: id 
SESSION-EXPIRES: 3600 
 
v=0 
o=- 5102 0 IN IP4 127.0.0.1 
s=session 
c=IN IP4 52.113.9.32 
b=CT:10000000 
t=0 0 
m=audio 51840 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118 
c=IN IP4 52.113.9.32 
a=rtcp:51841 
a=ice-ufrag:sO8V 
a=ice-pwd:OfIVXVH4dB0GiftQgIHAsUok 
a=rtcp-mux 
a=candidate:1 1 UDP 2130706431 52.113.9.32 51840 typ srflx raddr 10.0.136.242 rport 51840 
a=candidate:1 2 UDP 2130705918 52.113.9.32 51841 typ srflx raddr 10.0.136.242 rport 51841 
a=candidate:2 1 tcp-act 2121006078 52.113.9.32 49152 typ srflx raddr 10.0.136.242 rport 49152 
a=candidate:2 2 tcp-act 2121006078 52.113.9.32 49152 typ srflx raddr 10.0.136.242 rport 49152 
a=label:main-audio 
...

Sie sehen hier gut, dass der SBC nur Kandidaten von Microsoft bekommt. Direct Media Optimization fand in dieser Konstellation hier nicht statt. Das ist natürlich sehr ineffektiv hier, weil mein Client dann einen langen Weg nutzte:

Client -> (Internet-VPN) -> Firma -> (Internet) -> Teams TURN-Server+Media Relay -> (Internet SIP/TLS) -> SBC -> (Internet SIP) -> PSTN

Meine AudioDaten sind quasi viermal! durch die Internetanbindung der Firma gelaufen. Hier kann und sollte die Konfiguration natürlich optimiert werden. Dazu gibt es zwei Optionen:

  1. VPN Bypass
    Der Client könnte am VPN vorbei direkt zum Office 365-TURN-Server kommunizieren und damit zwei Übertragungen über den Firmenanschluss schon wegoptimieren. Wenn dann noch der SBC z.B. in Azure steht, ist der Weg sehr kurz
  2. VPN als Site eintragen
    Damit der VPN-Client direkt mit dem SBC spricht, muss das Media Relay in der Cloud natürlich auch die "Host-Kandidaten" des Clients durchreichen und nicht nur seine Adresse publizieren. Dann kann der Client durch das VPN direkt mit dem SBC sprechen.

Mein Favorit ist natürlich die erste Variante. Die weiteren Details finden sie auf weiteren Seiten:

Wenn ich das VPN abbaue oder ein SplitVPN konfiguriere, dann nutzt mein Client die zweite Option und spricht direkt mit dem Mediarelay in der Cloud, was per WireShark wieder gut zu erkennen ist.

VPN Trennen/Reconnect

Mit der Testserie habe ich nun häufiger eine VPN-Verbindung aufgebaut und wieder getrennt. Dabei habe ich aber nicht jedes mal den Teams-Anruf neu aufgebaut. So habe ich indirekt auch ermittelt, wie robust Teams auf solche "Veränderungen" in der Netzwerktopologie ist. Es war gut zu sehen, dass Teams diese Wechsel mit minimalen Unterbrechungen gemeistert hat. Anders als Skype for Business bricht bei Teams so ein Call dann nicht komplett ab, sondern Teams versucht über einen neuen INVITE im Hintergrund den dann möglichen RTP-Weg zu ermitteln. Dabei leuchtete bei mir folgendes Bild auf:

Auf der anderen Seite konnte ich kurz nicht verstanden werden. Es scheint so, dass bei einer 1:1-Verbindung der Anrufer für den Wiederaufbau zuständig ist. Bei einer Konferenz kümmert sich jeder Teilnehmer dann selbst um den Neuaufbau der Verbindung zur MCU

Manchmal hatte ich das Problem, dass aber z.B. Screen Sharing erst mit einer komplett neuen Verbindung funktioniert hat.

Zusammenfassung

Ich habe noch nicht alle Testfälle durchgespielt aber ich habe den Eindruck, dass sie Teams nicht an die ICE-Standards von VoIP hält. Bei der Aushandlung von Kandidaten gibt es drei Arten von Kandidaten mit unterschiedlicher Gewichtung:

Type Priorität Beschreibung

Host

Hoch

Direkte IP-Adresse des Hosts. Wenn beide Partner in einem gerouteten Netzwerk sind, können Sie sich direkt ohne Umwege über NAT oder Relay erreichen. Auch ein VPN-Benutzer ist ja quasi im "Firmennetzwerk" und damit würde ich erwarte, dass Audio durch das VPN geht, wenn es nicht durch den Administrator geblockt wird

SRFLX

Mittel

Wenn der Client per NAT ins Internet kann, dann ermittelt er vom STUN-Server seine "externe offizielle IP-Adresse" samt Port und bietet diese der Gegenseite an. Mit etwas Glück beim NAT kann die Gegenseite dann direkt diese Kombination beschicken und der NAT-Router setzt es auf den Client um.

RELAY

Niedrig

Wenn gar nicht geht, dann muss der Client das Teams Transport Relay bemühen, d.h. es sendet seine Daten zum Relay, welches diese dann weiter sendet und vor allem auch von der Gegenseite erreichbar ist und die Daten über die bestehende ausgehende Verbindung zurücksendet

In Verbindung mit Office 365 kann man nun überlegen, welcher Weg der Beste ist, wenn z.B. ein Benutzer im Homeoffice sitzt und ein VPN offen hat. Es kann ja nun ein Split-VPN oder ein Tunnel-VPN nutzen. Wenn der Client damit eine IP-Adresse aus dem Firmennetzwerk bekommt und die VPN-Lösung auch RDP zulässt, dann hatte ich erwartet, dass Teams die HOST-Kandidaten der beiden Partner bei 1:1 Verbindungen nutzt.

Das ist aber "ineffektiv", denn im schlimmsten Fall ist die Kette wie folgt:

HomePC -> VPN  -> Provider1 -> peering P1zu P2 -> Provider2 -> VPNServer -> Firmenclient

Sie sehen schon, dass hier das Peering zwischen zwei Providern eine Herausforderung sein kann. Besser wäre hier schon mal eine STUN-Verbindung, da damit der VPN-Overhead entfällt. Der Laufweg der Pakete ist aber gleich. Interessant wäre auch, wenn die Verbindung in dem Fall über das Azure Backend laufen würde:

HomePC -> RTP -> Provider1 -> Peering P1zuMGN ->  TURN -> Peering MGNzuP2 ->  Provider2 -> NAT -> Firmenclient

Hier ein Versuch einer Gegenüberstellung:

TlnA

TlnB

Erwartet

Gemessen (FC mit IPHTTP)

FirmenLAN

FirmenLAN

Direkt

Direkt

VPN (Split)

FirmenLAN

Direkt, wenn das VPN das nicht unterbindet

STUN/TURN  umgeht SplitVPN

VPN (Tunnel)

FirmenLAN

Direkt

Direkt

VPN (Split)

VPN (Split)

STUN/TURN umgeht SplitVPN

<noch zu testen>

VPN (Tunnel)

VPN (Split)

TURN bei Tunnel, STUN bei SplitVPN

<noch zu testen>

VPN (Tunnel)

VPN (Tunnel)

Direkt durch VPN

<noch zu testen>

KeinVPN

Intern

STUN im Homeoffice, TURN in der Firma

STUN/TURN

KeinVPN

VPN (Tunnel)

STUN im Homeoffice, TURN in der Firma

<noch zu testen>

KeinVPN

VPN (Split)

STUN im Homeoffice, Fallback TURN

STUN/TURN

KeinVPN

KeinVPN

STUN im Homeoffice, Fallback TURN

STUN/TURN

Achtung: Es gibt Firmen, die blocken RTP auf den VPN-Verbindungen, so dass die 1:1 Verbindung über die HOST-Kandidaten nicht zustande kommt und die Clients damit auf STUN oder TURN gezwungen werden. Das geht, wenn sie ein SplitVPN und entsprechend konfigurierte lokale Breakouts nutzen.

 

Weitere Links