VPN vom Home Office in die gehostete Domäne

Wie sprinter bereits in seinem Beitrag zum Thema „eine gehostete Windows -Domäne“ beschrieben hat, standen wir vor dem Problem von verschiedenen Standorten Deutschlands auf eine Domäne in einem Rechenzentrum zuzugreifen. Wie uns das gelungen ist mit einem in ein passives Gehäuse gepferchtem Alix Board und der Software pfSense beschreibe ich in diesem Artikel.

Vorgeschichte

Wir haben uns gefragt ob es möglich ist mit Hilfe einer gesicherten Verbindung von mehreren Standorten auf Server zuzugreifen. Die Frage kann man sehr einfach mit „Ja“ beantworten. Hier für benötigt man nur die Rolle „Routing und RAS“ auf einem der Windows Server, einige wenige Einstellungen am Server und am Client und die Verbindung steht. Das Problem ist nun aber, dass man mit Windows-Boardmitteln die Verbindung erst nach dem Start hergestellt werden kann. Unser Szenario sieht allerdings einen Zugriff auf eine Domäne vor, inkl. Anmeldung. Also muss ein Gerät her, das eine VPN Verbindung bereits vor der Anmeldung herstellt und dem Home Office einen Zugang in die entfernte Infrastruktur ermöglicht. Nachdem ich feststellen musste, dass z.B. eine Fritz!Box 7390 das nicht leisten kann (ohne eine andere Firmware zu flashen), begann hier meine Recherche-Reise durch das Internet. Sie führte mich von diversen hochpreisigen Geräten namhafter Hersteller über kleine Server Marke Eigenbau zu einer Open Source Lösung Namens pfSense.

pfSense ist eine Firewall und Router Lösung auf Basis eines FreeBSD  und entsprang 2004 dem Monowall Projekt. Ich habe bei meinen Recherchen viele Foren durchsucht und bin nachher bei Administrator.de fündig geworden. Anders als bei sprinter, sind meine Erfahrungen eher positiv. Sicher gibt es überall schwarze Schafe und Foren die sich auf dem Ruhm längst vergangener Tage ausruhen und nicht mehr zeitgemäß sind, aber bei Administrator.de findet man gute Hilfe. Das aber nur am Rand. Los geht`s!

Die Planung

Bei einem solchen Projekt ist gute Planung unerlässlich. Man muss sich zum Beispiel Gedanken zu IP-Bereichen machen, denn jeder IP-Bereich darf nur ein Mal auf der Strecke Home Office – Domäne vorkommen. In der Abbildung ist ein Beispiel für ein solches Szenario.

 

Wie man sieht, gibt es bei dieser Konstellation mehrere Probleme zu lösen.

  1.  Wie finden die Geräte vom Subnetz 192.100.100.0/24 in den VPN Tunnel der pfSense?
  2. Wie gelangt der Traffic, der nicht für die Domäne bestimmt ist, in das Subnetz 192.200.200.0/24?
  3. Wie kann ein Laptop, der über WLAN an die Fritz!Box im Netz 192.200.200.0/24 angeschlossen ist, mit dem NAS im 192.100.100.0/24 Netz kommunizieren?
  4. Kann der Laptop über die VPN-Verbindung der pfSense mit den Servern in der gehosteten Domäne kommunizieren?
  5. Was ist mit der Namensauflösung?

All diesen Fragen möchte ich auf den Grund gehen, aber vorne weg sei schon mal gesagt, dass alles möglich ist und es geht auch wesentlich einfacher, wenn man auf die Fritz!Box verzichten kann und an deren Stelle die pfSense stellt. Sie kann nämlich sowohl als ADSL als auch als VDSL Modem geschaltet werden. Hinzu kommt, dass man eine pfSense auch mit einem WLAN Modul bekommt. Aber da unsere Kollegen teilweise als ISP Kabel Deutschland haben und wir sonst kein Spaß im Sommerloch hätten, haben wir uns für die schwierige Variante entschieden.

Grundeinstellungen pfSense

Wenn die pfSense zum ersten Mal gestartet wird, dann kann man ganz bequem über das Webinterface die ersten Einstellungen vornehmen, um mich nicht im Detail zu verlieren gehe ich nicht darauf ein, wie die IP des WAN Interfaces und des LAN Interfaces gesetzt wird. Ich setzte voraus, dass das WAN Interface die IP 192.200.200.254 bekommen hat und das LAN Interface die IP 192.100.100.1 hat. Außerdem hat die Fritz!Box die IP 192.200.200.1.

Der VPN Tunnel

Die pfSense ist grundsätzlich dafür ausgelegt, über jeden erdenklichen Weg eine VPN-Verbindung zu einer entsprechenden Gegenstelle aufzubauen. Leider gibt es in der aktuellen Firmware Version (2.0.1) ine Problem. IPsec mit L2TP funktioniert nicht. Da wir aber sowieso am liebsten mit Zertifikaten arbeiten, haben wir uns für OpenVPN entschieden. Hier konfigurierten wir auf unserem Gateway Server einen OpenVPN Server mittels der einfach zu verstehenden Anleitung auf openvpn.net. Die Anleitung hilft einem auch die Client Zertifikate zu erstellen und ein CA (Certificate Authority) Zertifikat zu erstellen. Bewaffnet mit dem CA-Zertifikat, dem Client-Zertifikat und dem Key des Clients geht es zur pfSense.

Hier importiert man zunächst über das Menü „System“->“Cert Manager“ das CA-Zertifiakt und die Client Daten.

CA:

Client – hier sind zwei Zertifikate eingefügt:

Als nächster Schritt steht die Konfiguration des OpenVPN Clients an. Diese findet man im Menü unter „VPN“ -> „OpenVPN“ und dem Reiter Client. Über das kleine „+“ an der Seite kann man eine Konfiguration hinzufügen. Da hier die Einstellungen sehr stark von den Einstellungen des Servers abhängen, zeige ich hier eine Standardkonfiguration.

OpenVPN-Client:

Wenn alles richtig konfiguriert ist, dann steht der Tunnel, nach dem man auf „Save“ geklickt hat. Überprüfen kann man das, in dem man im Menü auf „Status“->“Services“ klickt. Steht hier hinter „openvpn“ der Status „Running“, dann steht der Tunnel.

Service zum Interface machen

Damit wir gleich mit dem Routing und NAT weitermachen können muss aus dem Service ovpnc1 ein Interface werden. So kann man nachher bequem die Regel im NAT für alles einstellen. das Interface wird erstellt unter „Interfaces“ -> „(assign)“. Hier unter dem Reiter „Interfaces assignments“ einfach auf „+“ klicken und ein Interface hinzufügen. Danach über die Dropdown Liste den VPN-Tunnel auswählen. Fertig. Jetzt geht es ans routen.

Firewall und NAT

Damit der Traffic der für die Domäne gedacht auch dort hin geht und der restliche Traffic im internen Netz verbleibt, müssen mit Hilfe das NAT (Network Address Translation)  Regeln für die Datenpakete erstellen. Hier ist die Firewall ziemlich hinderlich, da sie ja den Zweck hat jeglichen unerwünschten Verkehr zu unterbinden. Der Einfachheit halber habe ich eine Regel erstellt, so dass auf allen Interfaces keine Datenpakete mehr geblockt werden. Diese Regel ist deswegen wichtig, da man die Firewall nur mit dem NAT abstellen kann, wir benötigen aber das NAT für die Packet Inspection um die Pakete in die richtige Richtung zu senden und da wir sowieso nur im Heimnetz sind und eine Firewall in Form der Fritz!Box vorgeschaltet ist, sollte das kein Problem darstellen.

Diese Regel erstellt man über  „Firewall“ -> „Rules“. Hier klickt man auf den Reiter „Floating“ und erstellt eine Regel der folgenden Art:

Danach über „Firewall“ ->“NAT“ und dem Reiter „Outbound“ die Regeln wie unten beschreiben hinzufügen (bitte die IP-Adressen den Gegebenheiten anpassen). Ich habe hier die IP-Adresse aus unserem o.g. Beispiel genommen, um die Einstellungen nachvollziehbar zu halten.

Man liest die Einstellung wie folgt:

Alles was an Datenverkehr von „Source“ kommt und für „Destination“ bestimmt ist, geht über „Interface“. Diese Lesart ist etwas gewöhnungsbedürftig, aber nachvollziehbar.

An diesem Punkt haben wir den VPN Tunnel aufgebaut und leiten alle Pakete in die Richtige Richtung. Jetzt ist es auch möglich, dass alle Netzwerkgeräte, die LAN-seitig an der pfSense angeschlossen sind mit den entfernten Servern kommunizieren können.

Was jetzt noch fehlt, ist die Verbindung der Netzwerkgeräte aus der WAN-Seite der pfSense mit den Geräten auf LAN-Seite der pfSense und dem VPN-Tunnel.

Route zurück

Damit die Netzwerkgeräte aus dem Netz 192.200.200.0/24 mit denen im Netz 192.100.100.0/24 „reden“ können müssen statische Routen in der Fritz!Box her. Diese richtet man wie auf der folgenden Abbilung ein.

Menü: „Heimnetz“ -> „Netzwerk“ -> „Netzwerkeinstellungen“ – >“IPv4 Routen“

Letztendlich bedeuten diese Routen, dass alles, was an die Subnetze hinter pfSense (LAN und VPN) gehen soll an die WAN-Schnittstelle der pfSense gesendet wird.

Ab jetzt funktioniert jegliche Kommunikation aller angeschlossenen Geräte, allerdings nur wenn man die IP-Adresse des anzusprechenden Gerätes kennt. Eine Namensauflösung findet noch nicht statt, die ist allerdings notwendig für den Domänenbeitritt.

DNS

Am aktuellen Punkt fehlt uns noch, dass die Fritz!Box ihre Namensanfragenan die pfSense weiterleitet und diese den DNS für alle Geräte im Heimnetz übernimmt. Dazu kann man wie folgt in der Fritz!Box die Einstellungen ändern.

Menü: „Internet“ -> „Zugangsdaten“ -> „DNS-Server“

Hier habe ich als bevorzugten und als alternativen DNS Server die WAN-Adresse der pfSense angegeben, damit die Fritz!Box auch nicht auf die Idee kommt irgendeine Namensanfrage woanders hin zu senden, als an die pfSense.

In der pfSense tragen wir nun noch unter dem Menüpunkt „General Setup“ im Menü „System“ die DNS-Server ein. Wer auf die DNS-Server seines Anbieters verzichten kann und freie DNS-Server wählen möchte, kann dies hier tun. Ich habe mich zum einen für die 85.214.73.63 (FoeBuD – www.foebud.org) und 213.73.91.35 (Chaos Computer Club – www.ccc.de) entschieden. Als ersten Server habe ich jedoch die Fritz!Box mit ihrer LAN IP angegeben. Somit werden alle Anfragen zu erst auf der pfSense bearbeitet, wenn hier kein passendes Ergebnis geliefert wird, wird die Fritz!Box befragt. Sendet auch die keine vernünfitege Antwort, geht die Anfrage an die DNS Server im Internet.

Hinweis: Da die pfSense Multi-WAN fähig ist, kann man zu den DNS-Servern noch ein Gateway angeben, da wir in unserem Beispiel nur ein Netz an der WAN Seite der pfSense haben, spielt die Angabe hier keine Rolle.

Zum Abschluss und zum erfolgreichen Beitritt in die Domäne fehlt uns noch ein DNS Forwarding, was die pfSense praktischer Weise auch beherrscht. Dazu einfach unter „Services“ -> „DNS Forwarder“ die Einstellungen wie unten gezeigt übernehmen. Fertig!

Jetzt funktioniert alles, was wir wollten. Die Gerät an der pfSense und an der Fritz!Box können untereinander kommunizieren und der entfernten Domäne beitreten.

Wenn Fragen auftauchen, dann schreibt gern einen Kommentar. Ich helfe gern weiter.

4 Antworten auf „VPN vom Home Office in die gehostete Domäne“

    1. Hallo Gunnar! Danke für Dein Feedback. Ich bin nicht mehr ganz sicher, wie das im Artikel zustande kam. Ich gehe aber davon aus, dass die erwähnten öffentlichen IPs tatsächlichen entsprachen, die wir mit unseren Kunden geteilt haben. Im Sinne der Screenshots wurden dann wahrscheinlich die verwendet. Ich kläre das nochmal mit unserem Gunnar und er wird dann ggf. nochmal was dazu posten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.