Split Tunnel VPN

Vor Corona und Office 365 war die Welt einfach. Die Anwender haben mit ihrem PC in de Firma oder auf dem Notebook per VPN gearbeitet. Jeglicher Verkehr ging durch den Firmen-Proxy um Sicherheit und Compliance zu gewährleisten. Dieser Tunnel-Betrieb funktioniert aber mit Office 365, Skype for Business und vielem Home Office Benutzern nicht mehr. Auf der Seite beschreibe ich einige Details zum Betrieb eines "Split Tunnel VPN".

Beachten Sie dazu unbedingt TunnelVPN und IPv6 - Wenn IPv6-nicht durch den Tunnel gehen, haben sie ein IPv4Tunnel/IPv6-SplitVPN.

Nachteile eines Tunnel-VPN

Wenn die Mehrzahl der Dienste eh in der Firma steht, dann ist ein Tunnel-Betrieb oft noch vertretbar, da der extern arbeitende Anwender eh die Daten zur Firma senden muss. Hier hilft ein VPN als sichere, authentifizierte und vor allem auch verschlüsselte Verbindung. Aber schon der "Surftraffic" hat immer mehr zugenommen und stellt Firmen vor die Herausforderung, den Verkehr "günstig" zu leiten. Dazu gibt es mehrere Gründe:

  • Bandbreite in der Firma
    Speziell die Nutzung von Cloud-Diensten und Internet-Traffic über einen Tunnel bedeutet eine doppelte Datenübertragung in der Firma. Die Daten kommen einmal vom Client zum VPN-System und gehen dann oft durch interne Proxy-Server und dann wieder raus ins Internet.
  • Latenzzeit
    Dieser Umweg verlängert den Weg und addiert entsprechend Latenzzeit. Die Applikationen sind einfach nicht so "reaktionsfreudig" und der Durchsatz ist auch geringer.
  • UDP statt TCP
    Zudem gibt es Protokolle, speziell Audio/Video, bei denen sind die Daten "flüchtig" und müssen bei einem Verlust nicht erneut übertragen werden. Es ist sogar kontraproduktiv ein verlorenes Sprachpaket noch mal zu übertragen, da es vom Empfänger als "zu spät" eh verworfen wird. Daher werden Audio/Video-Daten bevorzugt per UDP übertragen. Wenn ihr VPN ein verbindungsorientierter TCP-Tunnel ist, dann werden verlorene Pakete neu übertragen, was die Situation einer schwachen Verbindung noch verschlimmert
  • Doppelte Verschlüsselung
    Protokolle wie HTTPS, POP3S aber auch SRTP sind von sich auch schon verschlüsselt. Da muss ein VPN-Gateway und ein Client nicht doppelt verschlüsseln.

Daher macht es Sinn, gewisse Daten am Tunnel vorbei zu leiten, wenn folgende Bedingungen gelten:

  • Verschlüsselt
    Ein VPN sichert auch die Daten selbst und wenn ein Verkehr das VPN umgehen soll, dann muss es aus meiner Sicht verschlüsselt sein.
  • Erreichbarkeit
    Der angesprochene Dienst muss natürlich über Internet ohne VPN erreichbar sein. Das ist für Exchange, Skype for Business, RDP oder Webseiten in der Regel möglich. Diverse Branchenprogramme und auch SMB-Dateifreigaben nutzen aber immer noch Verbindungen, die nicht über das Internet erreichbar gemacht werden können oder aufgrund von Sicherheitsbedenken nicht möglich sind.
  • externe Ziele
    Generell sind Ziele im Internet oder Cloud schneller zu erreichen, wenn die Pakete nicht erst durch das VPN und dann über den Internetzugang der Firma laufen. DAs gilt umso mehr, je weiter der Anwender von der Firma entfernt ist. Ein Vertriebsmitarbeiter, der z.B. beruflich in Asien unterwegs ist und per VPN nach Deutschland sich über Verkehrsmittel in Asien informiert, kann davon ein Lied singen.
  • Optimierte Protokolle
    Nicht alle Übertragungen erfolgen per TCP oder brauchen eine gegen Paketverluste gesicherte Verbindung.

Ich gehe davon aus, dass "Split Tunnel VPN" in Zukunft eher die Regel werden.

Risiko Split-Tunnel VPN

Wenn Sie als Firma aber zulassen, dass ein VPN-Client auch das Internet erreicht, dann müssen Sie natürlich den Schutz des Clients deutlich erhöhen, denn es darf nicht passiere dass der Client sowohl über eine Verbindung zu einer Gegenstelle im Internet als Brücke in ihre Firmennetzwerk missbrauch wird. In der Regel ist ein VPN-Client kein Router, so dass dieser Weg eigentlich nur über eine Zusatzsoftware auf dem Client möglich ist. Aber Anwender installieren schon mal gerne eine Fernsteuerungssoftware oder nutzen Konferenzsysteme mit der Möglichkeit zur Bildschirmübertragung und Steuerung. Hier ist dann der Anwender entsprechend zu sensibilisieren.

Ein übrigens tut eine passende Konfiguration des Clients mit:

  • Firewall
    Zumindest die im Betriebssystem enthaltene Firewall sollte eingehende Verbindungen auf den Client blockieren.
  • Virenschutz
    Ein aktueller Virenschutz auf dem Client sollte die meisten Angriffe abwehren können.
  • Software Policies
    Noch besser ist die Durchsetzung von Richtlinien, die ausführbare Programme über eine White-List erlaubt, so dass nicht freigegebene Programme gar nicht erst gestartet werden können. Dazu zähen nicht nur Beschränkungen für Makros sondern z.B. auch AppLocker

Damit das System in der Welt gegen Offline-Attacken geschützt ist, empfiehlt sich natürlich auch Secure-Boot, Bitlocker und anderen Schutzfunktionen zu aktivieren.

Technische Funktion

Für Windows gibt es nicht nur das eingebauten VPN und Direct Access, sondern auch viele Drittprodukte, die ein "besseres" VPN versprechen, z.B. weil sie zusätzliche Funktionen der Endgeräteverwaltung mitbringen. Ich möchte hier jetzt nicht auf die Unterschiede der VPN-Protokolle  (PPTP, L2TP, IPSec u.a.), der Server im Backend (Windows RRAS, OpenVPN, WireGuard) und der Authentifizierungsverfahren (Kennwort, Zertifikat, MFA, NAP/NPS) eingehen. Wir gehen einfach von einem Windows Client aus, der neben der normalen Netzwerk-Verbindung zum Internet noch eine VPN-Verbindung über eine Netzwerkkarte aufgebaut hat.

Bei der Betrachtung eines SplitVPN-Konfiguration sind dabei folgende Komponenten zu berücksichtigen.

  • IP-Routing/Firewall
    Alle Pakete müssen durch den TCP/IP-Stack des Betriebssystem, welches dann anhand der IP-Routingtabelle den nächsten Hop bestimmt. Bei einem "Tunnel-VPN" ist das Default Gateway der VPN-Adapter, der als einziger sich natürlich an dem Gateway der realen Netzwerkkarte orientiert. Der VPN-Adapter ist von den Kosten aber niedriger als die reale Karte, so dass normale Pakete den Weg ins VPN gehen. Bei einer Split-VPN Konfiguration werden über den VPN-Adapter nur die Subnetze geleitet, die auch durch da VPN zur Gegenstelle übertragen werden müssen. Alle anderen Pakete nehmen den "bessere" Weg am VPN-Adapter vorbei.
    Je nach Software müssen Sie natürlich die Routingtabellen auf dem Client passend konfigurieren. Beim Windows-VPN kann dies manuell per PowerShell oder eben über Gruppenrichtlinien erfolgen.
  • DNS/NRPT
    Nur wenige Clients verbinden sich direkt mit einer IP-Adresse sondern nutzen einen DNS-Namen, um das Ziel zu finden. Auch hier gibt es mit Windows zu beachten, dass sowohl der VPN-Adapter als auch der Netzwerkadapter entsprechende DNS-Server haben. Windows nutzt auch hier erst einmal den DNS-Server des VPN, über den dann die DNS-Server in der Firma gefragt werden. Diese sollten dann externe Ziele auch mit den öffentlichen Adressen auflösen. Alternativ können Sie über die NRPT (Name Resolution Policy Table) in Windows steuern, welche Domains über welchen DNS-Server aufgelöst werden. So könnten Sie die in der Firma genutzten Domainnamen über die Firmen-DNS-Server auflösen und alle anderen Adressen über die Netzwerkkarte auflösen lassen.
  • PAC/Proxy
    Speziell für den Zugriff per HTTP/HTTPS gibt es noch die Konfiguration der Proxy-Einstellungen in den Browsern. Das kann statisch oder dynamisch erfolgen. Interessant ist hier die Nutzung von WPAD statt statischer Proxy-Einträge, da so der Client dynamisch arbeiten kann. Die Server in der Firme, die über VPN direkt erreicht werden, brauchen in der Regel ja keinen Proxy und den Firmenproxy wollen Sie bei einer Split-VPN-Konfiguration ja gerade nicht nutzen.

IP-Leitwege und DNS

Wie schon beschrieben muss jeder Client mit einer VPN-Verbindung erst einmal eine normale Netzwerkverbindung haben, über die eine Verbindung zur VPN-Gegenstelle dann aufgebaut wird. Diese Verbindung erfolgt per Kabel oder Drahtlos, seltener per UMTS/LTE und bekommt meist per DHCP eine IP-Adresse, ein Default Gateway und natürlich einen oder mehrere DNS-Server. Damit ist der Client erst einmal "im Internet". Eventuell ist noch eine Anmeldung an einem Gäste-Portal erforderlich o.ä. Wie nicht anders zu erwarten, kann der Client nun Namen im Internet auflösen und über das Default Gateway gehen Pakete an Adressen außerhalb des eigenen Netzwerks über den Router.

Nun kommt der VPN-Client, der manuell oder automatisch den Tunnel zum VPN-Server startet und nach erfolgter Anmeldung liefert auch das VPN-Gateway eine IP-Adresse aus dem Tunnel, ein Gateway und DNS-Server. Damit kennt der PC nun natürlich zwei Gateways und verschiedene DNS-Server, die leider nicht das gleiche Wissen haben.

Der VPN-Adapter hat bei einer "Tunnel"-Konfiguration natürlich Vorrang und sorgt dafür, dass sowohl die Namensauflösung als auch die Pakete über den VPN-Adapter laufen, die das verschlüsselte Paket dann über das normale Netzwerk zur Gegenstelle leiten. Der VPN-Adapter als "Client" nutzt also die DNS-Einstellungen und Leitwege der normalen Karte. Bedenken Sie, dass ein Computer durchaus noch weitere Netzwerkkarten, z.B. HyperV, Bluetooth etc haben kann. Hier daher nur eine verkürzte Version eines "IPCONFIG /ALL" ohne IPv6 Zeilen.

C:\>ipconfig /ALL

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : FC-T480S
   Primäres DNS-Suffix . . . . . . . : uclabor.de
   Knotentyp . . . . . . . . . . . . : Broadcast
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : uclabor.de
                                       fritz.box

PPP-Adapter VPN2:

   Verbindungsspezifisches DNS-Suffix: uclabor.de
   Beschreibung. . . . . . . . . . . : VPN2
   Physische Adresse . . . . . . . . :
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.120.4(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.255
   Standardgateway . . . . . . . . . :
   DNS-Server  . . . . . . . . . . . : 192.168.120.12
                                       192.168.120.11

Ethernet-Adapter FC Dock:
   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : ThinkPad USB-C Dock Ethernet
   Physische Adresse . . . . . . . . : E0-4F-43-5D-79-E1
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.50(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Mittwoch, 1. April 2020 19:58:13
   Lease läuft ab. . . . . . . . . . : Samstag, 11. April 2020 19:58:13
   Standardgateway . . . . . . . . . : 192.168.178.1
   DHCP-Server . . . . . . . . . . . : 192.168.178.1
   DNS-Server  . . . . . . . . . . . : 192.168.178.1

und passend dazu die verkürzten IPv4-Leitwege:

C:\>route print

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.178.1   192.168.178.50     25
      92.61.20.21  255.255.255.255    192.168.178.1   192.168.178.50     26
    192.168.120.0    255.255.255.0  192.168.120.188    192.168.120.4      2
    192.168.120.4  255.255.255.255   Auf Verbindung     192.168.120.4    257
    192.168.178.0    255.255.255.0   Auf Verbindung    192.168.178.50    281
   192.168.178.50  255.255.255.255   Auf Verbindung    192.168.178.50    281
  192.168.178.255  255.255.255.255   Auf Verbindung    192.168.178.50    281
===========================================================================
Ständige Routen:
  Keine

Das ist eine normale Windows 10 (1909) VPN-Verbindung zu einem Routing und RAS-Server, die als "Split VPN" mit einem Subnetz auf der Gegenseite fungiert. Die Zeilen können Sie wie folgt lesen:

  • Zeile 1: Default Gateway geht über die LAN-Schnittstelle 192.168.178.50
  • Zeile 2: Eine explizite Route zur VPN-Gegenstelle über das LAN Interface
  • Zeile 3: Eine Route zum Netzwerk durch den VPN-Tunnel
  • Zeile 4ff: Die Routen für das lokale Netzwerk.

Diese Konfiguration bedeutet aber zugleich

  • Lokales Netz first
    Der PC kann trotz VPN weiterhin die System im Netzwerk 192.168.178.0/24 erreichen. Das ist ja das "lokale" Netzwerk und von Vorteil, wenn Sie z.B. einen lokalen Drucker ansteuern wollen
  • Verbranntes Netz 192.168.178.0
    Das bedeutet aber auch, dass Sie auf der Firmenseite möglichst nicht das Netzwerk 192.168.178.0/24 verwenden sollten, welches auch viele Fritz!Boxen verwenden. Das gilt für andere Netzwerke ähnlich.
  • Fehlende Leitwege zu weiteren Subnetzen der Firma
    Da das Default Gateway nicht zum VPN verweist, kann der Client natürlich auch keine weiteren Subnetze erreichen, die hinter dem Router 192.168.120.188 sind. Ich muss also irgendwie die Routen zu meinen anderen Netzwerken in der VPN-Konfiguration mitgeben
  • Internet "dran vorbei"
    Der Zugriff auf das Internet erfolgt hier ohne weiteren Schutz, d.h. der PC im VPN kann auch eine Verbindung zu einem Service wie z.B. TeamViewer etc. aufbauen und damit fern gesteuert werden

Eine durch Windows 10 Assistenten eingerichtete VPN-Verbindung ist immer eine "Split-Tunnel"-Konfiguration. Sie können aber über die Eigenschaften der Netzwerkkarte dies in der alten Oberfläche der Netzwerkverbindungen anpassen:

Die Funktion des VPN hinsichtlich Routing" sollte so einfach verstanden werden. Feinere Einstellmöglichkeiten können Sie dann über "Configuration Service Provider" (XML-Dateien) per SCCM/Intune oder andere Produkte einspielen.

DNS Besonderheiten

Eine Herausforderung bei VPNs ist immer auch die Namensauflösung. Eigentlich wollen wir immer den internen DNS-Server zuerst fragen. Damit Clients aber auch vom Split-VPN profitieren, müssen Sie auch Internet-Adressen auflösen können. Wir wollen ja gerade nicht, dass der Client den Namen nicht auflösen kann, weil die internen DNS-Server kein Forwarding machen. Viele Firmen nutzen immer noch die Konfiguration, dass interne DNS-Server nur lokale Systeme auflösen und Zugriffe ins Internet über einen Proxy oder Relay laufen müssen. Theoretisch wäre es ja sonst möglich über sehr viele DNS-Anfragen nach extern einen Tunnel aufzubauen.

Nehmen wir folgendes an

  • Der interne Exchange Server heißt "outlook.uclabor.de"
    Der interne DNS-Server löst diesen Namen auf eine private Adresse aus 10.0.0.0/8 auf
  • Der externe Name "outlook.uclabor.de" löst auf den öffentlichen Reverse Proxy auf.
  • Wir möchten, dass Outlook Traffic nicht durch den Tunnel geht, sondern über das Internet bei der Firma ankommt um z.B. doppelte Verschlüsselung zu vermeiden.

Das Outlook-Beispiel ist nicht optimal aber die meisten Leser kennen Exchange. Ein besseres Beispiel ist die Skype for Business AVEdge-Rolle, die aber weniger bekannt ist.

Damit der Client nun beim Zugriff auf "outlook.uclabor.de" auf den externen Zugang am VPN vorbei zugreift, können wir nun die Namensauflösung beeinflussen. Dazu gibt es zwei Optionen.

  • Eigener DNS für RRAS
    Eine Option besteht darin, den VPN-Clients einen eigenen DNS-Server zu geben, der Namen etwas anders auslöst. Das kann ein einfacher Windows DNS auf dem RRAS-Server sein, der alle Anfragen einfach an die internen DNS-Server weiterleitet aber ausgewählte Adressen eben selbst beantwortet oder an andere Server routet. Das ist schon länger möglich.
  • DNS Scoping
    Seit Windows 2016 können sie auf einem DNS-Server z.B. abhängig von der Client IP andere Antworten zurück geben. Dieses DNS-Scoping-Feature ist per PowerShell zu konfigurieren und in der GUI noch nicht sichtbar. Aber für weniger Host ist es ein einfacher Weg für VPN-Clients anhand des Client-Subnetz eine optimale Antwort zu geben
  • Client NRPT
    Die dritte Option nutzt die Funktion der "Name Resolution Policy Table" von Windows Clients. Über Gruppenrichtlinien kann pro Domain oder Host ein anderer DNS-Server hinterlegt werden. Sie könnte damit z.B.: einstellen, dass der Client für alle Namen den normalen "Internet DNS" des Clients nutzt und nur Anfragen an ihre interne Domain "uclabor.de" durch den Tunnel auf die Firmen-DNS-Server laufen. Wenn die interne und externe Domain gleich heißen, dann müssen Sie natürlich zumindest den Namen des VPN-Servers als Ausnahme definieren und alle anderen Hosts, die Sie nicht durch den Tunnel auflösen wollen.

So können Sie den Client beeinflussen, dass er die richtige IP-Adresse erwischt.

Windows Firewall und RTP/Skype

Eine besondere Funktion sollten Sie in dem Zuge mit der Windows Firewall kennen. Das IP-Routing entscheidet auch anhand der Windows Firewall-Regeln, ob ein Paket versendet werden darf und auch wohin es versendet werden darf. Das ist durchaus eine interessant Option, um gewisse Ziele "außen herum" zu leiten. Es könnte Fälle geben, bei denen Split-DNS und andere Dinge einfach nicht wirken und der Client quasi sowohl interne als auch externe Adressen mit einer Namensauflösung bekommt oder der Client gar nicht mit Namen arbeitet sondern IP-Adressen direkt anspricht. Dann fallen Konfigurationen per DNS weg.

Sie können aber die Windows Firewall hier einsetzen, um z.B. Ziele über bestimmte Wege zu unterbinden. Nehmen wir folgendes an:

  • Ihr PC bekommt per VPN eine IP-Adresse aus dem Bereich 10.99.0.0/16
    Diese Bereich verteilt der VPN-Server und die meisten Firmen kommen mit 65533 IP-Adressen für VPN aus
  • Der Leitweg für 10.0.0.0/8 oder sogar das günstigste Default Gateway verweist auf das VPN
    Damit werden alle Pakete an dieses Netzwerk immer durch das VPN gesendet.
  • Eine "teurere" Route für 0.0.0.0/0 verweist auf die normale Netzwerkkarte
    Das ist ja der Regelfall.
  • Sie möchten unter allen Umständen verhindern, dass der Client per VPN eine Audio/Video-Übertragung macht

Vielleicht erinnern sie sich noch an den Artikel ICE, Kandidaten, STUN und TURN. Zwei VoIP-Endpunkte versuchen eine Audio-Verbindung aufzubauen und senden sich über die Signalisierung (SIP) ihre Kandidaten zu. Wenn die private VPN-Adresse des Client aus dem 10.99.0.0/16-netz durch dasn VPN die Gegenstelle im Firmennetzwerk erreichen kann, dann werden die Clients diese "kürzeste" Verbindung nutzen und nicht den "Umweg" über den TURN-Server (Skype for Business Edge Rolle) nutzen.

Also Firma möchte ich aber, dass der Client per UDP mit meinem Edge Server oder bei der Teilnahme bei anderen Meetings mit dem Edge der Gegenstelle spricht. Der Weg durch das VPN ist nicht nur etwas länger sondern bei Verlusten wird ein IPHTTP-VPN aufgrund des TCP-Transports die verlorenen Pakete erneut übertragen. Das ist für Sprache und Video sogar schädlich. Ich möchte also eine Kommunikation der VPN-Clients mit dem internen Skype for Business Servern, d.h. MCU, Mediation, Edge, verhindern.

Ein Weg ist die Konfiguration der Port-Range von Skype for Business, damit ich diese Pakete auf dem VPN-Gateway oder einer Firewall zwischen VPN-Gateway und Skype Systemen blockieren kann. Wenn das aber aufgrund der Umgebung nicht möglich ist, dann kann ich diese Aufgabe auch an den Windows Desktop delegieren. Das ist zwar nicht schön, da die Konfiguration mit Gruppenrichtlinien dann nur Windows Client in der Domäne erwischt aber immer noch besser als nichts.

Der Trick besteht dabei, in der Windows Firewall entsprechende Regeln anzulegen, dass der Prozess "LYNC.EXE" nicht mit einer Source IP-Adresse aus dem VPN-Bereich (im Beispiel 10.99.0.0/16) eine ausgehende Verbindung aufbauen kann. Das kann dann für Skype for Business auf dem Office 16 Paket etwas so aussehen:

Action Prozessname SourceIP: Port RemoteIP Protokoll

Deny

%ProgramFiles%\Microsoft Office\Office 16\Lync.exe

10.99.0.0/16:Any

Any

3478/UDP

Deny

%ProgramFiles%\Microsoft Office\Office 16\Lync.exe

10.99.0.0/16:Any

Any

443/TCP

Deny

%ProgramFiles%\Microsoft Office\Office 16\Lync.exe

10.99.0.0/16:50000-50059

Any

Any:UDP

Wer sich doppelt absichern will, kann natürlich auch noch die internen Pool-Server "unerreichbar" machen, indem z.B. die Verbindung der VPN-IP zum Zielport 5061 geblockt wird.

Ich finde es interessant, dass der IP-Stack bei einer solchen Konstellation eine Verbindung dann nicht blockiert, sondern einen alternativen Weg nutzt. Der Client verbindet sich dann nämlich über die öffentliche IP-Adresse zum Access Edge und Port 443

Mit dieser Funktion könnten Sie vermutlich auch einen Windows Server als "Router" einsetzen und wenn es zwischen zwei Standorten zwei Wege gibt, könnten Sie abhängig von IP-Adressen und Ports entsprechende Pakete über unterschiedliche Wege weiter routen.

So könnte der zeitkritische RDP/Terminal/SAP/Audio-Verkehr über das "teure" aber SLA-abgesicherte MPLS laufen und z.B. Outlook Daten und Video-Ströme über das Internet geroutet werden. Ich habe so eine Konfiguration aber bislang nicht umgesetzt und kann daher keine verlässliche Erfahrungswerte zu Betrieb und Stabilität beisteuern. Viele Firmen werden sich hier vermutlich scheuen, da Windows doch sehr viel häufiger aktualisiert (->Patch-Management) werden muss und in der Zeit das Routing ausfällt. Klassische Hardware-Router haben hier ein höheres SLA. Ich könnte mir aber vorstellen, dass auch einfache Router beim Einsatz von Access-Listen ähnlich funktionieren.

  • TunnelVPN und IPv6
    Wenn IPv6-nicht durch den Tunnel gehen, haben sie ein IPv4Tunnel/IPv6-SplitVPN

Proxy-Einstellungen

Speziell bei der Nutzung von HTTP und HTTPS gibt es noch eine weitere Komponente in Verbindung mit VPNs, die ihre Überlegungen zur Namensauflösung mit DNS und IP-Routing torpedieren können. Sobald ein Client z.B. den WinHTTP-Stack nutzt, kommen auch HTTP-Proxy-Server ins Spiel. Diese können unterschiedlich konfiguriert werden und sobald ein Client für ein Ziel den Proxy-Server nutzt, umgeht es die native Namensauflösung per DNS und Routingentscheidung für diese Ziel, weil diese Pakete zum Proxy-Server gehen.

  • Statisch
    Viele Firmen nutzen leider immer noch die Variante einen Proxy-Server statisch z.B. per Gruppenrichtlinie zu verteilen. Das mag für DesktopSysteme noch funktionieren aber Notebooks mit unterschiedenen Einsatzorten können so nicht mehr sauber konfiguriert werden.
    Eine statisch Proxy-Konfiguration kann aber auch auf eine lokal vorgehaltene PAC-Datei verweisen, in der per JavaScript sehr ausgefuchste Konfigurationen auch anhand des Netzwerkstandorts möglich sind.
  • Dynamisch
    Interessanter finde ich aber die Konfiguration per DNS/DHCP über WPAD und PAC-Dateien. So können Clients sehr dynamisch Proxy-Konfigurationen nutzen, selbst wenn es keine Gruppenrichtlinien gibt, der Client z.B. Firefox heißt oder Linux o.ä. nutzt. Mit einem VPN müssen Sie hier natürlich aufpassen, wenn das lokalen Netzwerk schon eine Proxy-PAC ausliefert und nach dem Aufbau des VPN die PAc-Datei durch das VPN gezogen wird.
  • 3rd Party Proxy/Cloud Proxy
    Es gibt immer mehr 3rd Party Produkte (Firewalls, Antiviren-Produkte oder Cloud-Proxy-Clients), die auf dem Client in die Proxy-Konfiguration eingreifen und sich selbst als Proxy-Server über "localhost" eintragen. Diese Produkte können So dann den Verkehr genauer inspizieren und umleiten.

Bei all diesen Varianten müssen Sie natürlich prüfen, dass dann die Systeme, die nicht durch das VPN erreicht werden sollen, nicht doch wieder durch das VPN laufen, sondern entweder "DIRECT" zurückliefen oder einen Proxy, der z.B. in der Cloud steht und damit den Mitarbeitern einen sicheren Zugang erlaubt. Nicht weiter eingehen möchte ich noch auf die Zusatzprodukte, die sich als Filter-Treiber in den Netzwerk-Stack einbinden um die Pakete zu verändern. Das Thema kann beliebig komplex werden.

Windows Routing und RAS

VPN-Server gibt es von Microsoft als auch von verschiedenen 3rd Party Hersteller. Bei einer "Einwahl" eines Clients muss er nicht nur eine IP-Adresse des entfernten Netzwerks bekommen sondern auch zusätzliche Informationen über DNS-Server, Default-Domains u.a. Das funktioniert mit Windows RRAS-Servern relativ sauber. Der Windows RRAS kann die IP-Adressen selbst an die Clients vergeben oder von einem DHCP-Server beziehen. In dem Beispiel sind die Auswahlboxen grau, weil DirectAccess diese steuert.

Allerdings sollten Sie wissen, dass die RRAS-Clients sich verhalten, als wären sie an der Stelle des RRAS-Servers. Sie bekommen ihre Einstellungen bezüglich DNS und WINS von der Netzwerkkarte des RRAS-Servers und nicht über die vom DHCP-Server gelieferten Daten. Der RRAS-Server sollte also die Systeme in seiner eigenen Konfiguration haben, die auch von den Clients genutzt werden sollen.

Wenn ihr LAN des RRAS-Servers eine vom Standard abweichende Subnetz-Maske hat, dann prüfen Sie nach der Einwahl, ob diese auch bei den Clients als Route angekommen ist. Bei einer "Tunnel"-Konfiguration ist das alles kein Problem, da eh alle Pakete durch den Tunnel zum RRAS-Server gehen.

Wenn Sie aber mit Split-VPN arbeiten oder die LAN-Seite ein "Super-Net" nutzt, dann müssen Sie den Clients die Leitwege zu ihren sonstigen Netzwerken explizit mitteilen. Das geht aber nicht über die normale GUI sondern nur über eine Profil.XML.

PowerShell und SplitPN

Wenn Sie eine VPN-Verbindung per PowerShell anzeigen, dann sehen Sie auch hier das Feld "SplitTunneling".

PS C:\> Get-VpnConnection | fl *

EapConfigXmlStream             :
VpnConfigurationXml            : #document
IPSecCustomPolicy              :
MachineCertificateIssuerFilter :
MachineCertificateEKUFilter    :
ConnectionStatus               : Connected
DnsSuffix                      : uclabor.de
Guid                           : {xxxx}
IdleDisconnectSeconds          : 0
IsAutoTriggerEnabled           : False
Name                           : VPN
ProfileType                    : Inbox
ProvisioningAuthority          :
Proxy                          :
RememberCredential             : False
Routes                         : {MSFT_NetRoute (InstanceID)}
ServerAddress                  : vpn-uclabor.de
ServerList                     : {}
SplitTunneling                 : True
VpnTrigger                     : VpnConnectionTrigger
AllUserConnection              : False
AuthenticationMethod           : {MsChapv2}
EncryptionLevel                : Required
L2tpIPsecAuth                  :
NapState                       : NotNapCapable
TunnelType                     : Sstp
UseWinlogonCredential          : True
PSComputerName                 :
CimClass                       : root/Microsoft/Windows/RemoteAccess/Client:VpnConnection
CimInstanceProperties          : {ConnectionStatus, DnsSuffix, Guid, IdleDisconnectSeconds…}
CimSystemProperties            : Microsoft.Management.Infrastructure.CimSystemProperties

Achtung:
Der Wert "SplitTunneling" bezieht sich auf die IPv4-Einstellungen aber nicht auf die IPv6-Einstellungen.
Wenn Sie den Wert mit "Set-VPNConnection" setzen, dann ändert er die Checkbox bei IPv4 und IPv6.

  • TunnelVPN und IPv6
    Wenn IPv6-nicht durch den Tunnel gehen, haben sie ein IPv4Tunnel/IPv6-SplitVPN

Sie sehen hier aber auch das Property "Routes", welches die Routen dieser VPN-Verbindung anzeigt. Die Details verraten dann auch mehr

PS C:\> (Get-VpnConnection "VPN").routes

DestinationPrefix : 192.168.100.0/22
InterfaceIndex    :
InterfaceAlias    : VPN
AddressFamily     : IPv4
NextHop           : 0.0.0.0
Publish           : 0
RouteMetric       : 1
PolicyStore       :

Diesen Eintrag habe ich manuelle zum VPN mit folgendem Aufruf addiert:

Add-VpnConnectionRoute `
   -ConnectionName "VPN" `
   -DestinationPrefix 192.168.100.0/22

Damit leite ich alle Pakete an das Subnez 192.168.100.0/22 über dieses VPN, wenn es denn aktiv ist.

Über diesen Weg können Sie auch die VPN-XML anzeigen. Eventuell gesetzte Routen einer VPN-Verbindungen finden Sie dann mit

(Get-VpnConnection nawvpn).VpnConfigurationXml.vpnprofile.vpnconfiguration.route

Die Konfigurations-XML können wir vergleichbar bekommen:

PS C:\> (Get-VpnConnection nawvpn).VpnConfigurationXml.innerxml

<VpnProfile><VpnConfiguration>
   <Name>vpn</Name>
   <AllUserConnection>false</AllUserConnection>
   <ServerAddress>vpn.uclabor.de</ServerAddress>
   <TunnelType>Sstp</TunnelType>
   <EncryptionLevel>Required</EncryptionLevel>
   <AutoTriggerEnabled>false</AutoTriggerEnabled>
   <AuthenticationMethod><Method>MsChapv2</Method></AuthenticationMethod>
   <SplitTunneling>true</SplitTunneling>
   <L2tpPsk />
   <RememberCredential>false</RememberCredential>
   <UseWinlogonCredential>true</UseWinlogonCredential>
   <IdleDisconnectSeconds>0</IdleDisconnectSeconds>
   <MachineCertificateIssuerFilter />
   <MachineCertificateEKUFilter />
   <DnsSuffix>uclabor.de</DnsSuffix>
   <ProvisioningAuthority />
   <VpnServerList />
   <Route />
   <CryptographySuite />
   <Trigger>
      <ClassicAppIDList />
      <ModernAppIDList />
      <NrptRuleList />
      <DnsSuffixSearchList />
      <TrustedNetworkList />
   </Trigger>
   <VpnProxy />
   </VpnConfiguration>
   <EapConfiguration />
</VpnProfile>

Einstellungen, die vielleicht nicht per PowerShell erreichbar sein oder wenn Sie eine XML schnell mit vielen Einstellungen importieren wollen, dann können Sie folgenden Befehl nutzen:

Set-VPNConfiguration `
   -name VPNName ' 
   -CustomConfiguration <XML Dokument>

Weitere Links