Arbeitet man via VPN und darüber findet zudem eine Namensauflösung via DNS statt, kann dies gut als auch schlecht sein.

Im Idealfall und das gilt für nahezu alle unseren Kunden gibt es keinerlei Schwierigkeiten. Ganz gleich ob aus dem Homeoffice oder von unterwegs aus kann eine VPN-Verbindung hergestellt werden und man kann wie gewohnt mit z.B. “\\srv01” oder im Browser mit “https:\\intranet.local” die Unternehmensressourcen aufrufen.

Auf meiner Seite sieht das allerdings etwas anders aus: Bin ich per VPN mit dem Kunden verbunden, so findet die Namensauflösung über den Kunden-eigenen DNS-Server statt. Dies führt wiederum dazu, das ein Teil meiner eigenen Ressourcen nicht mehr erreichbar ist.

Um das Ganze besser zu verdeutlichen ein Beispiel:

LAN:

hostname.domain.tld - <Lokale IP-Adresse im LAN>

Internet:

hostname.domain.tld - <Öffentliche IP-Adresse>

Kurzum: Split DNS. An und für sich ein guter Weg, in der Kombi mit dem Kunden-VPN und dessen DNS allerdings problematisch.

Ohne die VPN-Verbindung wird der FQDN zur lokalen IP-Adresse aufgelöst und alles ist gut. Mit der VPN-Verbindung wird der FQDN dann allerdings zur öffentlichen IP-Adresse aufgelöst und das führt dann dazu, das die Anfragen von meinem PC über unser Gateway raus ins Internet gehen und dann an der WAN-Schnittstelle ankommen. Die Firewall verwirft dann diese Datenpakete.

Macht ja auch irgendwie keinen Sinn aus dem LAN ins Internet und dann auf die öffentliche IP zu wollen, soweit also durchaus nachvollziehbar. Wie aber kann man dieses Dilemma nun lösen? Es gibt mehrere mögliche Ansätze:

  • Nicht nur DNS sondern auch das Gateway via VPN umleiten.
  • Die private IP-Adresse als Host A-Eintrag im öffentlichen DNS zusätzlich zum Host A-Eintrag mit der öffentlichen IP-Adresse hinzufügen.
  • Sofern es die Firewall hergibt “NAT Reflection” aktivieren. pfSense kann dies wie hier beschrieben: Accessing Port Forwards from Local Networks
  • Die DNS-Server-Abfrage-Reihenfolge am Computer ändern.

Letzteres gelingt über das Ändern der Schnittstellen-Metrik der Netzwerk-Interfaces. Einen sehr schönen Beitrag dazu findet man hier:

Windows OS Hub – DNS Resolution via VPN Not Working on Windows 10

Via Powershell mittels

Get-NetIPInterface | Sort-Object Interfacemetric

sieht die Ausgangslage so aus:

ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
60 LAN-Verbindung IPv4 1500 5 Disabled Disconnected ActiveStore
4 OpenVPN Wintun IPv4 1500 5 Disabled Disconnected ActiveStore

Wie man sieht haben die LAN-Schnittstelle und das virtuelle VPN-Interface die gleiche Metrik (5). Bei aktiver VPN-Verbindung wird allerdings direkt der DNS-Server des Kunden angesprochen.

Die Änderung der Metrik kann über die grafische Oberfläche in den Eigenschaften von IPv4 bzw. IPv6 erfolgen. Hier zeigt sich zumindest Windows 10 etwas zickig. Via Powershell werden andere Metriken dargestellt als via “ncpa.cpl” (Netzwerkverbindungen aus der Systemsteuerung). Letztlich führte nur das Ändern der Metriken via Powershell zum Ziel, via GUI konnte man machen was man wollte, es wurde nur teilweise übernommen.

In der Powershell wird die Metrik wie folgt geändert:

 Set-NetIPInterface -InterfaceIndex 4 -InterfaceMetric 120

Die Änderung greift sofort, auch bei bestehender Verbindung.