Windows 10 VPN

Auch wenn immer mehr Dienste per HTTPS kommunizieren oder sogar direkt in der Cloud liegen, ist ein VPN ins Firmennetzwerk immer noch ein übliches Szenario, um Daten auf internen Systemen zu erreichen. Nicht alle Dienste könnten per HTTPS veröffentlicht werden und nicht alles Dienste sollen auch so von überall erreichbar gemacht werden. Ein VPN kann z.B. über Zertifikate abgesichert und so auf bestimmte Firmen-Clients eingeschränkt werden. Mit dem Wechsel des Notebooks Ende Oktober 2018 habe ich auch wieder ein VPN zu Net at Work eingerichtet aber es wollte einfach nicht funktionieren. So entstand diese Seite. VPNs sind nach Direct Access in Form von AutoVPN wieder aktuell.

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

VPN einrichten und testen

Ein VPN ist schnell eingerichtet. Sie suchen in Windows 10 einfach nach VPN und finden direkt den Weg:

Die erforderlichen Daten erhalten Sie in der Regeln von ihrem Administrator, wenn die VPN-Verbindung nicht schon vorab eingerichtet ist:

Am Ende gibt es hier einen Eintrag, den Sie mit "Verbinden" aktivieren können.

Die Verbindung kann ich über die GUI auslösen oder auch per Kommandozeile. Ich nutze dazu oft noch die "alte" Technik per Kommandozeile. Mit "RASDIAL kann ich die Verbindung aufbauen und IPCONFIG /ALL zeigt mir die Daten der Verbindung an.

Allerdings konnte ich mich immer noch nicht mit den Systemen in der Firma verbinden, obwohl ich eine IP-Adresse aus dem LAN bekommen habe. Lag es an dem fehlenden Default Gateway? Und warum konnte ich mit Get-VPNConnection die frisch eingerichtete Konfiguration nicht sehen?

VPN per PowerShell anlegen

Also habe ich erst einmal ein weiteres VPN (Name VPN2) über die PowerShell angelegt.

PS C:\> Add-VpnConnection -Name VPN2 -ServerAddress vpn.msxfaq.de
PS C:\> Get-VpnConnection

Name                  : VPN2
ServerAddress         : vpn.msxfaq.de
AllUserConnection     : False
Guid                  : {41DB17EB-AE0A-4493-9065-AF8CE5B72078}
TunnelType            : Automatic
AuthenticationMethod  : {MsChapv2}
EncryptionLevel       : Optional
L2tpIPsecAuth         : Certificate
UseWinlogonCredential : False
EapConfigXmlStream    :
ConnectionStatus      : Disconnected
RememberCredential    : False
SplitTunneling        : False
DnsSuffix             :
IdleDisconnectSeconds : 0

Unter Windows 10 habe ich nun auch beide VPNs sowohl in der einfachen Ansicht als auch bei den Netzwerkeinstellungen gesehen:

Ein Get-VPN-Connection zeigte mir aber nur den neuen Eintrag an:

PS C:\> Get-VpnConnection | ft

Name            ServerAddress        ProfileType     ConnectionStatus     IsAutoTriggerEnabled
----            -------------        -----------     ----------------     --------------------
VPN2            vpn.msxfaq.de        Inbox           Disconnected         False

Aber bei der Recherche bin ich noch auf den Parameter "-AllUserConnection" gestoßen.

PS C:\> Get-VpnConnection -AllUserConnection | ft

Name            ServerAddress        ProfileType     ConnectionStatus     IsAutoTriggerEnabled
----            -------------        -----------     ----------------     --------------------
VPN             vpn.msxfaq.de        Inbox           Disconnected         False

Windows hat also mindestens zwei Speicher für VPN-Verbindungen. So hat jeder Benutzer einen eigenen Store aber es gibt noch einen Computer-Speicher. Fragen Sie mich nun bitte nicht, wann welche GUI einen Eintrag wo hinein schreibt. Ich werde wohl VPN-Einträge zukünftig besser auch per PowerShell verwalten, da so die Einträge beim Benutzer landen, es sei denn ich gebe hier den Parameter "Add-VpnConnection -AllUserConnection" mit an.

Ich habe natürlich gesucht, ob die Einträge stehen und in der Registrierung habe ich den Namen nur in den Internet Explorer Settings gefunden. Das wird es nicht sein. Aber schon zu Windows NT4-Zeiten gab es das "RAS-Telefonbuch" und da wurde ich auch wieder fündig. Bei mir lag in "$($env:APPDATA)\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk" eine solche Datei. Die globalen Einstellungen liegen dann in n "%AllUsersProfile%\Microsoft\Network\Connections\Pbk\rasphone.pbk". Ein Doppelklick auf die persönliche pbk-Datei zeigte die zweite VPN-Verbindung:

Sobald dieses VPN aktiv ist, konnte ich auch die internen Computer anpingen. IPCONFIG zeigt eine kleine Abweichung zum ersten VPN.

Und auch die Routing-Tabelle mit "Route Print" zeigt nun den Leitweg als "günstiger" an:

Damit ist zwar noch nicht geklärt, warum das andere VPN nicht will, aber ich habe zumindest schon mal eine IP-Connectivity.

Namensauflösung mit VPN

Allerdings scheitert noch die Namensauflösung. Mein Client scheint zwar nun alle Pakete über das VPN zu senden aber die DNS-Auflösung liefert noch Daten aus dem Internet und löst interne Namen nicht auf.

Ein NSLOOKUP hingegen, bei dem ich den DNS-Server im internen LAN angebe, funktioniert. Die Verbindung zum DNS-Server ist theoretisch möglich. Nur der Windows DNSClient nutzt diese nicht. Verschiedene Quellen im Internet haben unterschiedliche Ansätze diskutiert. So scheint Windows 8.1 und höher per Default über IPv4 und IPv6 per DNS zu fragen und könnte so bestimmte Antworten eher bekommen. Das könnte ich dann über Einstellungen in der Registrierung "tunen".

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\
DisableParallelAandAAAA=REG_DWORD:0

Aber ich  halte nicht viel die Standardwerte zu verbiegen. Aber ich kann für die VPN-Verbindung einen DNS-Suffix setzen.

Set-VpnConnection -Name "VPN2" -DnsSuffix msxfaq.de

Damit konnte ich zumindest die Server anhand des kurzen Namens nach intern auflösen, die extern nicht definiert waren. Es scheint so, als ob der Client zuerst meinen DSL-Router fragt. Also forsche ich hier weiter, denn ich würde mir wünschen, dass die VPN-Verbindung exklusiv oder zumindest zuerst gefragt wird. Einen Blick der auf den Netzwerkkarten konfigurierten DNS-Servern erhalte ich mit:

PS C:\> Get-DnsClientServerAddress

InterfaceAlias               Interface Address ServerAddresses
                             Index     Family
--------------               --------- ------- ---------------
Ethernet                            17 IPv4    {192.168.178.1}
Ethernet                            17 IPv6    {}
Ethernet 3                          10 IPv4    {192.168.178.1}
Ethernet 3                          10 IPv6    {}
vpn2                                67 IPv4    {192.168.1.31, 192.168.1.11}
vpn2                                67 IPv6    {}
LAN-Verbindung* 1                   22 IPv4    {}
LAN-Verbindung* 1                   22 IPv6    {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
LAN-Verbindung* 3                    7 IPv4    {}
LAN-Verbindung* 3                    7 IPv6    {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
WLAN                                12 IPv4    {192.168.178.1}
WLAN                                12 IPv6    {}
Bluetooth-Netzwerkverbindung        15 IPv4    {}
Bluetooth-Netzwerkverbindung        15 IPv6    {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
Loopback Pseudo-Interface 1          1 IPv4    {}
Loopback Pseudo-Interface 1          1 IPv6    {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
Mobilfunk                            8 IPv4    {139.7.30.126, 139.7.30.125}
Mobilfunk                            8 IPv6    {}

Neben dem DNS-Server der VPN-Verbindung erscheint aber auch mein LAN und WLAN-Adapter mit dem DSL-Router und sogar die Mobilfunk-Verbindung, die aktuell aber gar nicht verbunden ist. Auch im folgenden Befehl ist der DNS-Eintrag sichtbar:

PS C:\> Get-DnsClient

InterfaceAlias               Interface ConnectionSpecificSuffix ConnectionSpecificSuffix RegisterThisConn UseSuffixWhen
                             Index                              SearchList               ectionsAddress   Registering
--------------               --------- ------------------------ ------------------------ ---------------- -------------
Ethernet                            17 fritz.box                {}                       True             False
Ethernet 3                          10 fritz.box                {}                       True             False
vpn2                                67 msxfaq.de                {}                       False            False
LAN-Verbindung* 1                   22                          {}                       True             False
LAN-Verbindung* 3                    7                          {}                       True             False
WLAN                                12 fritz.box                {}                       True             False
Bluetooth-Netzwerkverbindung        15                          {}                       True             False
Loopback Pseudo-Interface 1          1                          {}                       True             False
Mobilfunk                            8                          {}                       True             False

Allerdings registriert sich der Client mit dieser Adresse nicht im DNS-Server. Das ist soweit aber erst mal in Ordnung und entspricht meiner Einstellung. Auch andere Einstellungen passen soweit:

Get-DnsClientGlobalSetting

UseSuffixSearchList : True
SuffixSearchList    : {msxfaq.de, fritz.box}
UseDevolution       : True
DevolutionLevel     : 0

Das DNS-Suffix ist nur bei aktiver DNS-Verbindung dabei, wenn ich beim der DNS-Verbindung das DNS-Suffix gepflegt habe. Das sollte ich aber tun, da ich auch in die Firma aus Bequemlichkeit gerne kurze Namen verwenden möchte. Aus den Zeiten von Direct Access kenne ich noch die Direct Access Namensauflösung - NRPT. So sieht es aktuell auf meinem Client ohne DirectAccess aus:

Get-DnsClientNrptGlobal

EnableDAForAllNetworks QueryPolicy SecureNameQueryFallback
---------------------- ----------- -----------------------
Disable                Disable     Disable

# Die beiden folgenden Commandlets liefern keine Daten
Get-DnsClientNrptPolicy
Get-DnsClientNrptRule

Das erste Commandlet zeigt die fehlende DA-Konfiguration und die beiden weiteren Commandlets liefern gar nichts. Ich könnten nun per NRPT natürlich eine Regel bauen, die den VPN-Server ausschließt und alle anderen Anfragen an die internen Domains durch das VPN zwingt. Aber eigentlich kann mein Client beim VPN doch alle DNS-Anfragen in die Firma senden. Die Zentrale kann dann dem Client schon die interne oder auch die Adresse aus dem Internet liefern. DNS-Anfragen sind keine große Last und die Firma hat weiterhin die Hoheit über die Namensauflösung. Die Routingtabelle meines Clients hat dazu auch die richtige Reihenfolge:

Get-NetRoute -DestinationPrefix 0.0.0.0/0 | ft -AutoSize

ifIndex DestinationPrefix NextHop       RouteMetric ifMetric PolicyStore
------- ----------------- -------       ----------- -------- -----------
67      0.0.0.0/0         0.0.0.0                 1 25       ActiveStore
10      0.0.0.0/0         192.168.178.1           0 4250     ActiveStore

Hier stellt sich nun die Frage wie die "RouteMetric" berechnet wird und warum die Route höher ist, als der Netzwerkadapter. Die Konfiguration "Split-Tunneling" ist nämlich noch abgeschaltet. Allerdings mach die "1" logisch schon Sinn, da der VPN-Server ja einen Hop entfernt ist während mein DSL-Router direkt im LAN ist. Die "ifMetric" ist hingegen die Bewertung des Interface und hier ist bekannt, dass die kleinere Nummer eine höhere Priorität hat. Insofern ist das Setup hier eigentlich richtig, dass der VPN-Adapter die niedrigere Priorität hat. Das lässt sich per TraceRoute auch schnell verifizieren. Da reichen schon die ersten Hops um zu sehen, dass die Anfragen nicht über die lokale Fritz!Box gehen:

C:\>tracert -d 8.8.8.8

Routenverfolgung zu 8.8.8.8 über maximal 30 Hops

  1    30 ms    30 ms    30 ms  192.168.1.109
  2    30 ms    30 ms    32 ms  192.168.1.5
  3    32 ms    32 ms    30 ms  80.66.20.17
  4    39 ms    35 ms    36 ms  80.228.21.26
  5    38 ms    37 ms    37 ms  212.6.110.247
  6    37 ms    39 ms    39 ms  212.6.114.77

Hinsichtlich des IP-Routing ist also alles erst mal in Ordnung.

DNS und SmartNameResolution

Durch die Recherche bin ich aber noch auf ein anderes Verhalten gestoßen, was mich umso mehr irritiert hat: Windows scheint mittlerweile DNS-Abfragen parallel an mehrere DNS-Server zu senden um so die schnellste Antwort zu erhalten. Mein Client kennt bei aktivem VPN ja nicht nur meine DNS-Server in der Firma sondern auch weiterhin meine Fritz!Box als DNS-Proxy. Zwar sollte der Client die Fritz!Box bei aktivem VPN gar nicht fragen, aber er tut es dennoch.

Ich sehe aber keine Anfragen an andere DNS-Server außerhalb meines lokalen Netzwerks. Insofern scheint das inaktive Split-Tunnelung durchaus zu greifen. Es reicht aber, um DNS-Namen über das Internet aufzulösen, wenn diese dank Split-DNS von intern und extern auflösbar sind. Die schnellere DNS-Antwort gewinnt. Ddieses Feature heißt "SmartNameResolution". Es wird auf vielen Seiten als "Risiko" bewertet, da damit der Internet-Provider und damit auch Überwachungsdienste auch DNS-Anfragen nach Systemen sehen, die eigentlich "intern" sind und dank VPN auch gar nicht sichtbar sein sollten. Es kommt sogar noch schlimmer. Wenn Sie ein VPN aufbauen, um "sicher" zu sein, dass niemand etwas von ihrem Verkehr sehen soll, dann möchten Sie auch nicht verraten, welche DNS-Namens sie ansprechen. Genau das passiert aber.

Das Verhalten ist aber nicht ganz neu und schon in Windows 2000 gab es ein "Failover", bei dem der DNSClient zuerst den primären DNS-Server fragt aber bei einem Timeout dann auch die DNS-Server der anderen Netzwerkkarten verwenden. Hier der passende Auszug aus der Windows 2000 Dokumentation

1. The resolver sends the query to the first server on the preferred adapter's list of DNS servers and waits for one second for a response
2. If the resolver does not receive a response from the first server within one second, it sends the query to the first DNS servers on all adapters that are still under consideration and waits two seconds for a response.
3. If the resolver does not receive a response from any server within two seconds, the resolver sends the query to all DNS servers on all adapters that are still under consideration and waits another two seconds for a response.

Name Resolution  https://technet.microsoft.com/en-us/library/cc961411.aspx 

Allerdings hätte ich dann anhand des IP-Routings erwartet, dass der Client auch die Anfragen an die DNS-Server der anderen Netzwerkkarten durch den VPN-Tunnel sendet. Aber selbst wenn diese nicht der Fall wäre, sollte die erste Frage ja immer an den DNS-Server des "Preferred Adapter", also der mit der geringsten "ifMetric" gehen. Ein Report über die IP-Interfaces liefert aber folgende Liste:

PS C:\> Get-NetIPInterface | sort InterfaceMetric

ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
17      Ethernet                        IPv6                  1500               5 Enabled  Disconnected    ActiveStore
22      LAN-Verbindung* 1               IPv6                  1500              25 Disabled Disconnected    ActiveStore
67      vpn2                            IPv4                  1400              25 Disabled Connected       ActiveStore
10      Ethernet 3                      IPv6                  1500              25 Enabled  Connected       ActiveStore
7       LAN-Verbindung* 3               IPv6                  1500              25 Disabled Disconnected    ActiveStore
12      WLAN                            IPv6                  1500              35 Enabled  Disconnected    ActiveStore
15      Bluetooth-Netzwerkverbindung    IPv6                  1500              65 Disabled Disconnected    ActiveStore
1       Loopback Pseudo-Interface 1     IPv6            4294967295              75 Disabled Connected       ActiveStore
8       Mobilfunk                       IPv6                  1500              85 Disabled Disconnected    ActiveStore
17      Ethernet                        IPv4                  1500            4230 Enabled  Disconnected    ActiveStore
10      Ethernet 3                      IPv4                  1500            4250 Enabled  Connected       ActiveStore
22      LAN-Verbindung* 1               IPv4                  1500            4250 Enabled  Disconnected    ActiveStore
7       LAN-Verbindung* 3               IPv4                  1500            4250 Enabled  Disconnected    ActiveStore
12      WLAN                            IPv4                  1500            4260 Enabled  Disconnected    ActiveStore
15      Bluetooth-Netzwerkverbindung    IPv4                  1500            4290 Enabled  Disconnected    ActiveStore
1       Loopback Pseudo-Interface 1     IPv4            4294967295            4300 Disabled Connected       ActiveStore
8       Mobilfunk                       IPv4                  1500            4310 Disabled Disconnected    ActiveStore

Mein PC hat durchaus einige Schnittstellen aber hier ist zu sehen, dass "Ethernet" tatsächlich" an erster Stelle steht. Das kann natürlich dazu führen, dass mein Client den DNS-Server aus meiner Ethernet-Karte "Fritz!Box" nimmt und durch das VPN erreichen will. Das klappt natürlich nicht und nach 1 Sekunde versucht der dann die gleiche Anfrage noch mal an alle Netzwerkkarten zu senden. So kommt er dann auch zu anderen DNS-Servern. Allerdings denke ich nicht, dass mein DNS-Server durch das VPN länger als 1 Sekunde braucht und im Wireshark habe ich ja gesehen, dass auch direkt Anfragen an die Fritz!Box direkt gegangen sind. Also habe ich weiter gesucht und wurde fündig. Es sind die Blogs verschiedener VPN-Hersteller, die dieses unschöne Verhalten thematisiert haben. Versprechen VPNs ja doch, dass dank eines VPN niemand von außen sehen kann, welche Daten übertragen werden. Dazu zählen natürlich auch DNS-Anfragen.

Nun denken Sie mal an Funktionen wie die "Telekom Surfhilfe", bei der die Telekom eine Auflösung auf einen ungültigen Namen mit der IP-Adresse des eigenen Portals beantwortet. Der Anwender sieht dann neben der Werbung eine Empfehlung zu Seiten, die der Anwender vielleicht gemeint habe. Sie wollen aber eigentlich zum internen Server der Firma. Hätte Windows gleich den richtigen DNS-Server über das VPN gefragt, dann gäbe es hier auch kein Problem.

In Windows 8 konnten sie die Einstellungen noch direkt über einen Wert in der Registrierung steuern. Das geht in Windows 10 soll das so nicht mehr gehen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"DisableSmartNameResolution"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"DisableParallelAandAAAA"=dword:00000001

Mit Windows 10 ist eine Einstellung in den Gruppenrichtlinien erforderlich. Das ist für Firmen natürlich der sowieso präferierte Weg.

Computer Configuration > Administrative Templates > Network > DNS Client > Turn off smart multi-homed name resolution.

Wobei hier zumindest in der deutschen Übersetzung (Stand Version 1803) zwei Einträge den gleichen Namen bekommen haben. In der Datei C:\Windows\PolicyDefinitions\de-DE\DnsClient.adml steht nämlich zweimal drin:

<string id="DNS_SmartMultiHomedNameResolution">Multicastnamensauflösung deaktivieren</string>
<string id="DNS_TurnOffMulticast">Multicastnamensauflösung deaktivieren</string>

Über die Hilfe bekommen Sie aber schon den richtigen "grünen" Eintrag:

Der rot umrandete Eintrag hat tatsächlich etwas mit "Multicast" zu tun. Der grüne Eintrag ist also falsch übersetzt. Die Einstellung wirkt interessanterweise auf den gleichen Registrierungsschlüssel:

    <policy name="DNS_SmartMultiHomedNameResolution" 
            class="Machine" displayName="$(string.DNS_SmartMultiHomedNameResolution)" 
            explainText="$(string.DNS_SmartMultiHomedNameResolution_Help)" 
            key="Software\Policies\Microsoft\Windows NT\DNSClient" 
            valueName="DisableSmartNameResolution">
      <parentCategory ref="DNS_Client" />
      <supportedOn ref="windows:SUPPORTED_Windows8" />
      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>

Insofern entzieht es ich meiner Kenntnis, warum ein direktes Setzen per REGEDIT nicht das gleiche Ergebnis liefern sollte. Zumal es durchaus Windows Editionen gibt, die gar keine Gruppenrichtlinien unterstützen.

Wenn ich aber so die parallele Anfrage unterbinde, dann ist das immer noch keine sichere Konfiguration, da die DNS-Abfragen dann eben sequentiell immer noch an DNS-Server gehen, die keine Informationen über per VPN erreichbare Systeme haben und mit Split-DNS sogar die unerwünschten externen IP-Adressen statt der internen Adressen liefern.

Dieses Problem werden Sie nur über Änderungen an der Name Resolution Table (Siehe auch Direct Access Namensauflösung - NRPT) dauerhaft lösen können. Ich habe aber erst einmal einen anderen einfacheren Weg eingeschlagen.

DNS Auflösung über Interface Metric steuern

Mein Ethernet hat eine kleinere Metric (5) als der VPN-Adapter (25). Wenn ich den VPN-Adapter wirklich als "Preferred Netzwerkkarte" nutzen möchte, so dass auch die erste DNS-Anfrage schon über das VPN geht dann kann ich das über eine kleinere Metric für das VPN erreichen. Technische geht das per GUI oder PowerShell:

Per PowerShell ist es ein Einzeiler, wenn Sie den Namen des VPNs kennen.

Get-NetIPInterface vpn2 | Set-NetIPInterface -InterfaceMetric 1

Die Änderung wird erst mit dem nächsten Verbindungsaufbau aktiv.

PS C:\> t-NetIPInterface | sort InterfaceMetric

ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
67      vpn2                            IPv4                  1400               1 Disabled Connected       ActiveStore
17      Ethernet                        IPv6                  1500               5 Enabled  Disconnected    ActiveStore
10      Ethernet 3                      IPv6                  1500              25 Enabled  Connected       ActiveStore
22      LAN-Verbindung* 1               IPv6                  1500              25 Disabled Disconnected    ActiveStore
....

Danach hat das VPN nun endlich wie erwartet funktioniert. Die erste Namensauflösung geht über den VPN-Adapter zur Firma und der dortige DNS-Server beantwortet die Anfragen mit den richtigen internen Adressen. Wenn die Firma auch externe Adressen auflöst, dann entscheidet das IP-Routing und die Proxy-Konfiguration, wie der Client das externe Ziel erreicht. Die Failback-Funktion ist aber nicht ausgeschaltet. Sollte der interne DNS-Server nicht antworten, dann wird der Client natürlich andere DNS-Server versuchen und kann so zumindest externe Adressen auflösen. Bei einer Split-DNS-Konfiguration werden dann aber auch ein Teil der internen Adresse irrtümlich auf die externe Adresse aufgelöst. Das ist unschön und wer dies beseitigen will, sollte sich mit NRPT genauer beschäftigen.

VPN und Split Tunnel

In Verbindung mit Cloud-Diensten ist es natürlich sinnvoll und sofern dies erlaubt ist, solche Daten nicht erst durch das VPN zu routen, sondern direkt zur Cloud zu senden. Dies wird als "Split Tunneling" bezeichnet, bei denen nur Daten zum eigenen Netzwerk durch den Tunnel laufen während alle anderen Pakete den direkten und kürzeren Weg suchen. Vier Dinge sind dabei interessant:

  • IP-Routing
    Sie müssen nun das IP-Routing so optimieren, dass alle Netzwerke in ihrem LAN, die nur per VPN erreichbar sind, durch den Tunnel laufen und alle anderen Pakete dran vorbei gehen. Per Default kennt das VPN natürlich nur das erste Subnetz, aus dem es auch seine IP-Adresse gekommen hat. Wenn ihr Firmennetzwerk aber weitere Subnetze hat, dann müssen Sie diese im VPN-Client mit übergeben. Wenn Sie intern also eh nur private Adressen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), dann können Sie diese per Routing durch das VPN senden und alle anderen Adressen über das normale Gateway laufen lassen
  • Namensauflösung
    Schon weiter oben haben Sie meine Probleme mit DNS mitbekommen. Bei Split-Tunnel müssen Sie auch sicherstellen, dass die internen Domains auch alle durch das VPN zu internen DNS-Servern aufgelöst werden. Wenn Sie intern und extern den gleichen Domainnamen (Split-DNS) nutzen, dann müssen Sie besonders vorsichtig sein, damit ausgewählte Hosts nicht intern aufgelöst werden, z.B. der VPN-Zugang selbst oder Systeme, die sie weiter außen herum betreiben wollen. Diese Konfiguration kennen wir aber auch schon von Direct Access und der Direct Access Namensauflösung - NRPT
  • Proxy
    Denken Sie auch daran, dass Sie z.B. den Zugang zum Internet über einen HTTP-Proxy leiten wollen oder eben nicht. Ein direkter Weg ist für die Anwender natürlich am besten, da dieser schneller und ungefiltert ist. Aber aus Firmenpolicy kann es auch wieder erforderlich sein, bestimmte URLs doch über den internen Proxy z.B. zu einem Partner zu leiten. Oder sie nutzen einen Cloud-Proxy für die Clients, die im Home-Office sind. Solche Konfiguration bekommen Sie eigentlich nur über WPAD hin

Mit all dem Wissen meiner Analyse können Sie nun auch einfach ermessen, was das Bit "Split Tunnel" letztlich noch bewirkt: Es sorgt einfach dafür, dass das Default-Gateway nicht mehr zum VPN umgebogen wird.

# Route mit SplitTunnel aus
Get-NetRoute -DestinationPrefix 0.0.0.0/0

ifIndex DestinationPrefix                              NextHop                                  RouteMetric ifMetric PolicyStore
------- -----------------                              -------                                  ----------- -------- -----------
67      0.0.0.0/0                                      0.0.0.0                                            1 2        ActiveStore
10      0.0.0.0/0                                      192.168.178.1                                      0 4250     ActiveStore

Dann schalte ich den Tunnelmode auf "Split-Tunnel" und bau die Verbindung neu auf

Set-VpnConnection -Name "VPN2" -SplitTunneling $True 
RASDIAL VPN2 /Dis
RASDIAL VPN2

Die Routingtabelle sieht dann wie folgt aus:

PS C:\> Get-NetRoute -DestinationPrefix 0.0.0.0/0

ifIndex DestinationPrefix                              NextHop                                  RouteMetric ifMetric PolicyStore
------- -----------------                              -------                                  ----------- -------- -----------
10      0.0.0.0/0                                      192.168.178.1                                      0 25       ActiveStore

Wenn ich die Leitwege für den VPN-Adapter anzeige, dann sehen Sie hier nur das direkt am VPN-Knoten angebundene Firmenntzwerk

PS C:\> Get-NetRoute -ifIndex 67

ifIndex DestinationPrefix                              NextHop                                  RouteMetric ifMetric PolicyStore
------- -----------------                              -------                                  ----------- -------- -----------
67      255.255.255.255/32                             0.0.0.0                                          256 1        ActiveStore
67      224.0.0.0/4                                    0.0.0.0                                          256 1        ActiveStore
67      192.168.1.107/32                               0.0.0.0                                          256 1        ActiveStore
67      192.168.1.0/24                                 192.168.1.109                                      1 1        ActiveStore

Über "What is my IP-Dienste" können Sie auch schnell erkennen, welchen Ausgang ihr Client nun nutzt. Allerdings sehe ich hier auch, dass das Subnetz hier ein "/24" ist, obwohl ich auf der Firmenseite ein "/22"-Netzwerk habe. Ich kann also bei so einem Firmennetzwerk dann auch nur eine Teilmenge der Clients erreichen. Ich komme nicht umhin weitere Routen zu addieren.

Add-VpnConnectionRoute -ConnectionName "VPN2" -DestinationPrefix 10.0.0.0/16

Diverse kommerzielle VPN-Client unterstützen von Hause aus wohl eine zentrale Konfiguration des Clients, z.B.: wenn das VPN aufgebaut wird, können auch Compliance und Konfigurationseinstellungen auf den Client gesendet werden. Mit dem klassischen Windows VPN wüsste ich nicht, das dies geht. Allerdings können Sie natürlich per Software-Verteilung die Routen an die VPN-Verbindung binden. Solange die Verbindung nicht aktiv ist, wirkt die Route ja niciht.

VPN Trigger und Disconnect

Bei der Betrachtung der PowerShell-Befehle zu "VPNConnection" sind mir drei interessante Befehle aufgefallen

Damit lässt sich sogar ein Automatismus aufbauen, dass ein Client immer dann ein VPN aufbaut, wenn er nicht im Firmennetzwerk ist und z.B. Zugriff auf interne DNS-Namen erfolgen. Auch der Abbau des des VPN lässt sich über den Parameter "IdleDisconnectSeconds" beim Commandlet Set-VPNConnection steuern.

Get-VpnConnection | select name, IdleDisconnectSeconds

name IdleDisconnectSeconds
---- ---------------------
vpn2 0

Set-VPNConnection vpn2 -IdleDisconnectSeconds 60

Zusammenfassung

Ich habe mir zur einfacheren Erinnerung des Inhaltes dieser Seite folgende Sätze gemerkt.

  • Windows 10 fragt auch DNS-Server vor Ort, selbst wenn das VPN aufgebaut ist und SplitTunnel nicht erlaubt ist
  • Windows 10 fragt irgendwann alle auf den verschiedenen Schnittstellen hinterlegte DNS-Server
  • Die DNS-Abfragen umgehen IP-Leitwege, wenn er im gleichen Subnetz steht
    Das dürfte auch der Grund sein, dass mein Client die lokale Fritz!Box fragen kann.
  • Windows VPN ist kein 100% Tunnel
    Anfragen und Zugriffe auf Clients, Server, Drucker u.a. Geräte im lokalen Netzwerk bleiben möglich. Das ist auch verständlich, da hier kein "Routing" stattfindet. Es ist aber aus Sicherheitsaspekten kritisch, wenn ein Anwender das unsichere LAN/WLAN irrtümlich als "Heimnetzwerk" oder "Firmennetzwerk" definieren würde.
  • Split-DNS bei Firmen führt zu Problemen, wenn die internen Namen auch im Internet auflösbar sind
    Der Client bekommt dann in der Regel die "Internetadresse" zuerst und nutzt nicht den etablierten VPN-Tunnel

Es hat einige Stunden gedauert, bis ich die interne Funktion des Windows VPN-Client etwas besser verstanden habe und das alles nur, weil mein Client zwar ein VPN aufgebaut hat aber weder die Namen der internen Systeme auflösen noch per IP die Ziele erreichen konnte. Letztlich habe ich bei mir der VPN-Konfiguration eine niedriger Netzwerk Metric gegeben, damit die DNS-Abfragen zuerst durch das VPN laufen. Zudem habe ich per VPN-Routen auch die Netzwerke im Firmennetzwerk erreichbar gemacht, die hinter einem Router standen. Allerdings verstehe ich immer noch nicht ganz, warum diese Probleme noch nicht häufiger irgendwo eskaliert sind oder werden Windows VPNs wirklich nur bei kleinen Firmen mit einem klassischen Class-C Netzwerk ohne Supernetting eingesetzt? Ganz glauben kann ich es nicht, denn das Windows "AutoVPN", welches wohl Direct Access beerben soll, nutzt ja auch nichts anderes.

Weitere Links