VPN-split tunneling for Microsoft Teams: føre medietrafikk utenom tunnelen

En Teams-samtale over en VPN-forbindelse høres ofte dårligere ut enn uten: Stemmen faller ut, video hakker, og skjermdeling bygges opp med forsinkelse. Årsaken er som regel omveien sanntidstrafikken tar gjennom VPN-tunnelen, ikke Teams selv. Microsoft har derfor i mange år anbefalt å føre Teams-medietrafikk direkte til internett utenom VPN-et ved hjelp av split tunneling. Denne tilnærmingen fungerer med praktisk talt alle VPN-produkter, fra forbrukerklienter til enterprise-gatewayer; konfigurasjonen varierer bare i detaljene.

Hvorfor sanntidstrafikk lider i tunnelen

Teams-lyd og -video bruker SRTP, en UDP-basert protokoll som er avhengig av lav forsinkelse og lite jitter. Microsoft oppgir som målverdier under 100 ms rundturstid til nærmeste Microsoft-nettverksinngang og under 30 ms jitter. En VPN-tunnel forverrer begge verdiene på flere måter.

For det første forlenger tunnelen veien: I stedet for å gå direkte til det geografisk nærmeste Microsoft-tilgangspunktet, går trafikken først til VPN-gatewayen, som kan være plassert i leverandørens eller bedriftens datasenter, og derfra videre til Microsoft. For det andre krever det ekstra krypteringslaget prosesseringstid og øker overheaden per pakke; mediestrømmen er allerede kryptert med SRTP, og VPN-krypteringen kommer i tillegg som et andre lag. For det tredje er VPN-gatewayen en delt flaskehals: I rushtider deler alle brukere båndbredden og pakkebufferne, noe som skaper nettopp det jitteret sanntidstrafikk er mest følsom for. For det fjerde blokkerer enkelte VPN-konfigurasjoner UDP helt eller tvinger frem TCP; Teams faller da tilbake til TCP 443, noe som forringer kvaliteten ytterligere fordi TCP-gjenoverføringer er uegnet for sanntidsmedier.

For den øvrige Teams-trafikken (pålogging, chat, filtilgang) spiller dette knapt noen rolle, fordi den ikke er sanntidssensitiv. Det er derfor tilstrekkelig å unnta medietrafikken målrettet.

De relevante nettverkene og portene

Microsoft publiserer alle Microsoft 365-endepunkter i maskinlesbar form og deler dem inn i kategoriene Optimize, Allow og Default. Kategorien Optimize er relevant for split tunneling: Den omfatter de få forsinkelseskritiske endepunktene med faste IP-nettverk, som til sammen utgjør størstedelen av volumet. For Teams-medier er dette endepunkt-ID-ene 11 og 12 i den offisielle listen:

De fire UDP-portene står for medieklassene lyd (3478), video (3479 og 3480) og skjermdeling (3481); TCP 443 er reserveveien. De som bruker IPv6, bør også unnta IPv6-nettverket, ellers vil en del av forbindelsene likevel gå gjennom tunnelen.

Disse nettverkene er bevisst stabile: Microsoft varsler endringer i Optimize-endepunktene via Endpoint-webtjenesten og holder listen kort, nettopp slik at bedrifter kan legge dem inn i ruting- og brannmurregler. Likevel bør det inngå i driftsrutinene å sammenligne med den offisielle listen med jevne mellomrom.

App-basert eller IP-basert: to tilnærminger med ulike styrker

Mange VPN-klienter tilbyr to typer split tunneling: unntak per applikasjon eller unntak per mål-IP.

App-unntaket virker nærliggende, men har to svakheter for Teams. Nye Teams er en WebView2-applikasjon: Hovedprosessen heter ms-teams.exe, men en del av trafikken går via msedgewebview2.exe. Den som bare unntar hovedprosessen, får ikke med all trafikken; den som også unntar WebView2, fører også trafikk fra andre WebView2-applikasjoner (for eksempel nye Outlook) utenom tunnelen. Og for Teams i nettleseren hjelper ikke app-unntaket i det hele tatt, med mindre hele nettleseren unntas, slik at all nettrafikk omgår VPN-et.

Det IP-baserte unntaket virker derimot på nettverksnivå og er dermed uavhengig av om trafikken kommer fra Teams-appen, WebView2 eller en nettleserfane. Det unntar nøyaktig det som er forsinkelseskritisk, og lar pålogging, chat og resten av nettrafikken bli i tunnelen. For Teams er den IP-baserte tilnærmingen derfor det beste valget; app-unntaket egner seg som et supplement når virkelig all Teams-trafikk skal omgå VPN-et.

Implementering i vanlige VPN-produkter

Prinsippet er det samme overalt: De tre IPv4-nettverkene (og ved behov IPv6-nettverket) unntas fra tunnelen, slik at operativsystemets ruter for disse målene peker mot det fysiske grensesnittet.

Forbruker-VPN-er (Proton VPN, NordVPN, Surfshark og lignende): Windows- og Android-klientene har som regel et menypunkt som «Split Tunneling» med en unntaksliste for IP-adresser eller delnett. Legg inn de tre nettverkene i CIDR-notasjon der, og opprett VPN-forbindelsen på nytt slik at rutene tas i bruk. På macOS og iOS mangler funksjonen hos de fleste leverandører, fordi system-API-ene der ikke tillater applikasjonsstyrt split tunneling i denne formen.

WireGuard: WireGuard har ingen unntaksliste, men bare AllowedIPs-angivelsen, som fastsetter hva som går inn i tunnelen. Unntak oppstår ved å erstatte 0.0.0.0/0 med listen over alle nettverk som ikke inneholder unntaksområdet. Ingen beregner denne komplementærlisten for hånd; nettbaserte kalkulatorer som WireGuard AllowedIPs Calculator bruker 0.0.0.0/0 som grunnlag, de tre Microsoft-nettverkene som «Disallowed IPs» og gir den ferdige linjen for konfigurasjonsfilen.

OpenVPN: Når redirect-gateway er aktivt, vinner mer spesifikke ruter. Tre ekstra linjer i klientkonfigurasjonen fører Microsoft-nettverkene utenom tunnelen:

route 13.107.64.0 255.255.192.0 net_gateway
route 52.112.0.0 255.252.0.0 net_gateway
route 52.122.0.0 255.254.0.0 net_gateway

net_gateway står her for standardgatewayen i det lokale nettverket, ikke VPN-gatewayen.

Enterprise-klienter (Cisco Secure Client/AnyConnect, Palo Alto GlobalProtect, Fortinet FortiClient): Her konfigurerer bedriften unntakene sentralt, hos Cisco som en «Split Exclude»-liste i gruppepolicyen og hos GlobalProtect som «Exclude Access Route». Microsoft dokumenterer uttrykkelig denne fremgangsmåten som den anbefalte modellen for Microsoft 365-trafikk og leverer Optimize-listen via Endpoint-webtjenesten, slik at unntakene kan holdes oppdatert automatisk. Ansatte bak en bedrifts-VPN kan altså ikke sette unntaket selv, men må be nettverksteamet om det; Microsoft-dokumentet om dette er et passende grunnlag for argumentasjonen.

Windows innebygde verktøy: I en VPN-forbindelse satt opp med Windows innebygde verktøy i split-modus (Set-VpnConnection -SplitTunneling $true) havner bare nettverkene som er lagt inn med Add-VpnConnectionRoute i tunnelen. Så lenge Microsoft-nettverkene ikke finnes der, går de automatisk direkte; et eksplisitt unntak er da unødvendig.

Sikkerhetsvurdering: hva som går utenom tunnelen

Split tunneling er en bevisst oppmyking av prinsippet om å føre all trafikk gjennom tunnelen. Før implementering bør du avklare tre punkter.

Din egen offentlige IP-adresse blir synlig for Microsoft, for det er nettopp hensikten: Mediestrømmen skal ta den korteste veien. De som primært bruker VPN for å skjule egen plassering, gir opp denne beskyttelsen for Teams-samtaler. Innholdet påvirkes ikke av dette, fordi SRTP krypterer mediestrømmen ende-til-ende mellom klienten og Microsoft-infrastrukturen.

I bedriftsmiljøer mister den sentrale sikkerhetsgatewayen innsyn i den unntatte trafikken: TLS-inspeksjon, IDS-signaturer og volumanalyse gjelder ikke lenger for disse nettverkene. Siden unntaket er begrenset til noen få, fast Microsoft-tilordnede nettverk med definerte porter, vurderer Microsoft denne restrisikoen som lav; Optimize-endepunktene er kuratert nettopp for dette. Et generelt unntak for hele applikasjoner eller til og med nettleseren har derimot en betydelig større angrepsflate og bør unngås i bedriftsmiljøer.

Til slutt, Kill Switch: Enkelte VPN-klienter bruker split-tunneling-unntak først etter at forbindelsen er opprettet på nytt, eller oppfører seg annerledes når Kill Switch er aktiv. Etter hver endring i unntakslisten bør du derfor gjenopprette forbindelsen og utføre en kontrolltest.

Kontroll: går medietrafikken virkelig direkte?

Om unntaket fungerer, kan kontrolleres på to nivåer. På rutingnivå viser PowerShell hvilket grensesnitt Windows velger for et mål i Microsoft-nettverkene:

Find-NetRoute -RemoteIPAddress 52.112.1.1 |
  Select-Object InterfaceAlias, NextHop

Hvis det fysiske grensesnittet (Ethernet eller WLAN) vises her i stedet for VPN-adapteren, er ruten riktig. På applikasjonsnivå gir Teams selv bekreftelsen: Under en samtale viser samtalekvaliteten (under «Flere handlinger» i samtalevinduet) den forhandlede tilkoblingstypen, rundturstiden og pakketapsraten. En rundturstid som synker betydelig etter omleggingen, og tilkoblingstypen UDP i stedet for TCP, er de to kjennetegnene på et fungerende unntak.

Hvis trafikken fortsatt går gjennom tunnelen til tross for korrekt rute, bør du se på rekkefølgen på nettverksadapterne og klientsæregenheter: Enkelte VPN-klienter tvinger gjennom rutene sine på nytt med lavere metrikk etter hver tilkobling, og en utdatert unntaksliste blir først synlig når Microsoft legger til et nettverk. Sammenligning med den offisielle endepunktlisten bør derfor inngå i samme rytme som andre gjentakende nettverkskontroller.