OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Wie aktiviert man einen OpenVPN Server zur Anbindung remoter VPN Clients oder zur Netzwerk Kopplung remoter Netze auf einem Router mit DD-WRT Firmware oder der freien pfSense Firewall ?
Das folgende Tutorial gibt einen Leitfaden für eine preiswerte und effiziente VPN Installation die sowohl zur Anbindung remoter Mitarbeiter als auch zur Netzkopplung eingesetzt werden kann auf Basis der sehr populären VPN Lösung OpenVPN.
Dieses Tutorial basiert auf den bei Administrator.de bereits bestehenden Tutorials von datasearch zum Einrichten eines OpenVPN Servers:
OpenVPN_Teil_2
Wobei hier der Schwerpunkt auf dem Teil 1 zur Erstellung der Schlüssel für Client und Server liegt.
Die Installation die der OpenVPN Teil 2 beschreibt ist, bedingt durch die andere Hardware eines DD-WRT Routers oder der pfSense Weboberfläche zum Konfigurieren folgerichtig etwas unterschiedlich zu einer PC basierten Installation.
Dadurch aber noch einfacher auch für Laien zu realisieren, da alles mit einer einfachen Weboberfläche konfiguriert wird !
Als Alternative zu einer Installation auf Windows oder Linux kommt hier die platzsparendere Variante direkt in einem Router mit DD-WRT Firmware oder der freien Firewall/Router Software pFsense zum Einsatz.
Die VPN Funktion ist somit nicht abhängig von Serverhardware sondern autark auf einer Netzwerkkomponente, was außer der Platz Ersparniss zudem erheblich kostengünstiger ist in der Unterhaltung und vom Hardwareaufwand.
OpenVPN ist eine sehr weit verbreitete freie VPN Lösung mit Client Software für nahezu alle gängigen Betriebssysteme.
Durch ihre Flexibilität erlaubt sie z.B. das wahlfreie Konfigurieren des Tunnel Ports so das dieser z.B. vom Standard UDP 1194 auch auf den gängigen SSL Port TCP 443 gelegt werden kann, um mit der VPN Verbindung problemlos Firewall und Accesslisten ohne einen zusätzlichen Eingriff zu überwinden.
Das Tutorial benutzt die Default Einstellungen von OpenVPN und auch DD-WRT. Anpassungen an vorhandene IP Netzwerk Adressierung ist dann individuell nach vorhandener IP Adressierung zu machen.
Eine Schemazeichnung für das Netzwerkdesign sieht so aus:
Bzw. mit der pFsense Variante dann analog:
Die o.a. Bilder sind nur Schema Zeichnungen zur Funktion. Es besteht keine Beschränkung auf nur einen Client ! Natürlich sind auch Mehrfachverbindungen, sei es per Netz zu Netz Kopplung oder mit remoten Clients, möglich !
pfSense
Die Hardware für die pfSense Variante kann entweder PC basierend sein mit einer preiswerten CF Flashkarte als verschleissfreiem Datenträger für den Dauerbetrieb wie HIER im Kapitel Download und Installation beschrieben.
Auch ein alter PC lässt sich so bequem recyceln.
Viel kosteneffizenter im Hinblick auf den Stromverbrauch und erheblich robuster für den Dauerbetrieb ist aber immer eine kleine, preiswerte Appliance im Eigenbau oder Fertiggerät wie in_diesem_Tutorial beschrieben.
DD-WRT
Hardware Basis ist, wie oben bereits bemerkt, ein Router mit der freien DD-WRT Firmware wie er auch VPN Einrichtung (PPTP) mit DSL Routern und DD-WRT Firmware schon beschrieben ist. Solche Router sind heute meist in Form eines Linksys WRT54GL im Handel (z.B. Reichelt oder Alternate). Teilweise sogar schon mit geflashter DD-WRT Firmware.
Weitere bekannte Plattformen für DD-WRT sind Router der Fa. Buffalo wie der bekannte WZR HP-G300NH oder im unteren Preissegment um die 20 Euro der DLink-DIR 300 und 600 und der TP-Link TL-WR841N
DD-WRT ist auch für andere Router Plattformen von Linksys, NetGear, TP-Link u.a. frei verfügbar ! Eine genaue Übersicht über unterstützte Router Hardware bietet das DD-WRT Wiki:
http://www.dd-wrt.com/wiki/index.php/Supported_Devices
oder die interaktive Router Datenbank:
http://www.dd-wrt.com/dd-wrtv3/dd-wrt/hardware.html
Eine deutsche Projektbeschreibung findet man hier:
http://www.dd-wrt.com/wiki/index.php/DD-WRT_Doku_%28DE%29
Als DD-WRT Router Hardware für das folgende Tutorial dient der populäre WRT54GL, der mit der aktuellen DD-WRT (V24 SP2) geflasht wurde. Das Vorgehen bei anderen Modellen ist aber identisch !
Wichtig ist hier das WRT54 Image xx24-VPN_generic (Man achte auf das "VPN" im Imagenamen ! Version 24) denn das enthält den OpenVPN Server und auch einen Client. Mit dem Client kann ein DD-WRT Router selber OpenVPN Client sein. Dieses Tutorial behandelt die Serverfunktion als VPN Dialin Server und am Beispiel der Standortvernetzung auch die Installation als Client.
Das aktuelle Image zum Download und Flashen für einen Linksys WRT54G findet man auf der DD-WRT Seite wenn man seine Router Modellbezeichnung wie z.B. "WRT-54GL" dort eingibt:
http://www.dd-wrt.com/site/support/router-database
OpenVPN Clients
OVPN Clients sind für nahezu sämtliche Betriebssysteme am Markt erhältlich:
https://openvpn.net/index.php?option=com_content&id=357
Auch für alle gängigen Smartphones ist die "OpenVPN Connect" App kostenlos im App Store verfügbar:
OpenVPN hat gerade für Clients einen erheblichen Vorteil da es ein SSL VPN bereitstellt was nur ein Tunnelprotokoll benötigt und so erheblich leichter NAT Firewalls überwinden lässt als z.B. IPsec.
Zudem ist es erheblich besser mit zusätzlichen Features ausgezeichnet und einer sehr flexiblen Konfiguration wie das folgende Tutorial zeigt.
Beschrieben wird hier die sichere VPN Installation mit Zertifikaten und bewusst nicht mit den einfachen Klartext Passwörtern. Wird so ein Passwort einmal kompromittiert ist das ganze VPN kompromitiert. Bei Zertifikaten ist das nicht der Fall.
Da OpenVPN auf dem Router selber schon durch die DD-WRT Firmware oder pfSense Firmware installiert ist, ist es lediglich erforderlich die erzeugten Schlüssel und die Konfig Datei auf den Router oder die pfSense Firewall zu übertragen.
Auch das ist sehr einfach, lediglich per Cut and Paste, über die webbasierte Installationsseite des Routers zu erledigen. Das ist schon alles um OpenVPN auf dem Router oder der pfsense Firewall/Router zu aktivieren !
Zwingende Voraussetzung ist das Erzeugen der Schlüssel, will man nicht mit einfachen preshared Keys arbeiten, was natürlich auch geht aber sehr unsicher ist (Siehe oben) !
Dazu läd man sich am besten erstmal das komplette Installations Paket des grafischen Windows OpenVPN Clients herunter und installiert es. Das Paket hat schon fertige Skripts (Easy-RSA) zum einfachen und bequemen Generieren der Schlüssel gleich mit an Bord:
http://openvpn.se/
bzw.:
http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-instal ...
Alternativ geht das auch auf allen anderen OVPN Plattformen die diese Skripts alle mitliefern.
Das Erzeugen der Schlüssel und Zertifikate ist damit kinderleicht zu machen.
Die dazu nötigen Schritte sind detailiert im bereits oben erwähnten OpenVPN_Teil_1 Tutorial, auch für Laien verständlich, beschrieben.
Auch das HowTo auf der OpenVPN Projektseite erklärt dieses in einer einfachen Schritt für Schritt Anleitung:
http://www.openvpn.net/index.php/open-source/documentation/howto.html#p ...
ebenso HIER.
Man geht also lediglich in die Eingabeaufforderung von Windows (analog auch MacOS oder Linux), wechselt in das easy-rsa Skriptverzeichnis und führt einfach nacheinander, wie beschrieben, diese Skripte aus und sichert sich so seine Schlüssel z.B. auf einem USB Stick.
Die Schritte im Schnellverfahren unter Windows sehen so aus: (OpenVPN GUI muss zuvor installiert sein !)
set KEY_PROVINCE=Niedersachsen
set KEY_CITY=Hannover
set KEY_ORG=Meyer GmbH
set KEY_EMAIL=name@email.de
Die Inhalte sind mit dem Editor oder Wordpad editierbar.
Das Easy-RSA Tool wird unter Linux genau so bedient wenn man den Server z.B. auf einem Raspberry Pi usw. installiert.
Wer Kommandozeilen nicht mag und die Zertifikate und Schlüssel lieber mit einer grafischen Oberfläche erzeugen will, findet mit dem Tool XCA dafür ein idelaes Werkzeug.
Die Anwendung ist für alle 3 wichtigen Betriebssysteme (Windows, Mac OS-X und Linux) in der aktuellen Version 2.2.1 hier verfügbar:
https://www.hohnstaedt.de/xca/
Sogar in einer portablen Version die keinerlei Installation erfordert !
Eine auch für Laien einfach zu verstehende Anleitung findet sich hier:
http://www.carbonwind.net/VPN/XCA_OpenVPN/XCA_OpenVPN.htm
Noch einfacher ist die Schlüsselerzeugung Online ! Webseiten wie z.B.:
http://www.mobilefish.com/services/ssl_certificates/ssl_certificates.ph ...
erledigen das per Mausklick ohne weitere Zusatzsoftware.
Damit ist ein Erzeugen der Schlüssel dann auch für Kommandozeilen "Muffel" eine einfache Sache von ein paar Mausklicks !
OK, sind nun der Router oder die pfsense Firewall fertig geflasht bzw. installiert und über ihr jeweiliges Konfigurations Webinterface erreichbar und auch die 4 Schlüssel ca.crt, server.crt, server.key und dh1024.pem erzeugt wie oben beschrieben kanns losgehen... !!!
Dazu kopiert man diese 4 Schlüssel Dateien ggf. auf einen Stick oder den Rechner zum Konfigurieren und dann kann die eigentliche Konfiguration des DD-WRT Routers oder der pfsense Firewall beginnen:
Nach Vergabe der Zugangspasswörter bei DD-WRT beim ersten Connect auf die Setup Webseite unter 192.168.1.1 (Default), klickt man auf das Menü Services -> VPN und aktiviert hier den OpenVPN Daemon mit dem Start Type WAN up was bedeutet das der OpenVPN Server immer dann gestartet wird wenn das WAN Interface aktiv ist !
Danach öffnen sich 7 freie Textfelder zur Eingabe:
Public Server Cert
Certificate revoke list ==>> bleibt leer !
Public Client cert
Private Client key
DH pem
OpenVPN config
OpenVPN TLS Auth ==>> bleibt leer !!
In 4 dieser Felder cut und pasted (Kopieren und Einfügen) man nun seine 4 oben erzeugten Schlüsseldaten rein.
Alle Schlüsseldateien sind reine ASCII Textdateien und lassen sich mit dem Word Pad oder einem Text Editor öffnen. Ist der Schlüssel oder Zertifikat editiert, klickt man unter "Bearbeiten" dann auf "Alles markieren" und dann "Kopieren".
Darauf wechselt man in das Textfenster der Routerkonfig mit einem Rechtsklick und "Einfügen" um den Inhalt hier ins Textfeld zu kopieren.
Diese Prozedur macht man jetzt Fenster für Fenster nach folgendem Schema:
Public Server Cert ==>> Master Zertifikat, ca.crt Datei
Certificate revoke list ==>> bleibt leer !!
Public Client cert ==>> Server Zertifikat, server.crt Datei
Private Client key ==>> Server Key, server.key
DH pem ==>> DH Parameter, dh1024.pem Datei
OpenVPN config OpenVPN Konfig Datei, z.B. Beispiel unten
OpenVPN TLS Auth ==>> bleibt leer !!
Die 5te Datei ist die eigentliche OpenVPN Konfigurationsdatei für den Server. Dazu kann man die unten aufgeführte Datei in einen Editor cut and pasten und entsprechend seinen individuellen Einstellungen (IP Adressen etc.) anpassen und dann z.B. mit dem Namen "openvpn-svrconf.txt" sichern und dann per cut an paste in das Feld "OpenVPN config" im Router eingeben.
Ein Port zur Tunnel Encapsulierung: Hier sollte in jedem Fall UDP als Enkapsulierungs Protokoll verwendet werden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Die OpenVPN Konfig zum Editieren sieht dann so aus: (Kommentarzeilen in () rot vorher entfernen !!!)
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /tmp/openvpn/dh.pem (DH Parameter)
server 172.16.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0" (Default LAN IP Netz DD-WRT, muss ggf. auf verwendetes IP Netz geändert werden !!)
push "dhcp-options DNS 192.168.1.x" (Optional die IP des DNS-Server im lokalen Netz, sonst verwendet der Client den Default)
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Zusatz zur o.a. Konfig:
Wer den gesamten Traffic des Clients durch den VPN Tunnel routen möchte leitet einfach dessen Default Gateway in den VPN Tunnel um.
Statt push "route 192.168.1.0 255.255.255.0" lautet das Push Kommando dann push "redirect-gateway def1"
http://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Sehr WICHTIG ist in der o.a Server Konfigurations Datei, das die Pfadangaben oben in der Konfig /tmp/openvpn/ unbedingt stimmen für alle Dateien, denn die sind durch OpenVPN fest vorgegeben !
Ein Screenshot sieht dann so aus: (Zertifikate aus Sicherheitsgründen verkürzt wiedergegeben !)
Zum Schluss sichert dann ein Klick auf SAVE und Apply Settings die Konfig !
Der OpenVPN Client bleibt ausgeschaltet (disable) !!
WICHTIG: Normalerweise lässt die SPI Firewall des DD-WRT aus Sicherheitsgründen keine eingehenden Verbindungen und damit auch keine OVPN Verbindungen vom WAN/Internet Interface zu.
Man kann die jetzt zum Testen die SPI Firewall in den Security Einstellungen testweise abschalten, indem man den Haken bei "SPI Firewall in den Security Settings entfernt.
Damit verzichtet man aber auf einen Teil der Router Sicherheit.
Technisch besser, da sicherer und eleganter ist es, die Firewall etwas anzupassen um eigehende OVPN Sessions mit der SPI Firewall zuzulassen.
Forumsmitglied Spirit hat dazu im Fragenthread unten die Lösung gepostet die wir an dieser Stelle übernehmen:
Wie richtet man ganz einfach diese Firewall Regeln ein:
Auf der Konfig Weboberfläche von DD-WRT geht man in Menü "Administration --> Commands" und bei Commands fügt man ganz einfach per cut and Past die obigen Zeilen ein und klickt dann "Save Firewall" !
FERTIG...!
Zum Abschluss sollte man den Router nun neu booten lassen (Einmal stromlos machen !)
Damit ist die Konfiguration des Routers abgeschlossen und einem ersten Test des OpenVPN Servers steht nichts mehr im Wege !
Leider muss man alle oben beschriebenen Einstellungen über das Websetup blind machen mit Vertrauen alles richtig gemacht zu haben. Man kann leider nicht über die Status Seite den OpenVPN Server im Router auf seine korrekte Funktion überprüfen.
Für die detailierte Fehlersuche ist das aber kein Hinderniss denn die Lösung dafür ist bei DD-WRT recht einfach !
DD-WRT bietet einen Terminalzugang per Telnet oder SSH auf die Konsole !
Der Telnet Zugriff funktioniert sofort über die LAN IP.
Wer es etwas sicherer haben möchte nimmt SSH:
Dafür aktiviert man im Menü Services -> Services mit einem Klick auf enable einfach den SSHd Daemon und sichert diese Einstellung mit SAVE und APPLY.
Mit einem Windows Telnet und SSH Client wie dem bekannten PUTTY oder auch TeraTerm (Apple Macs und Linux haben SSH von sich aus an Bord) hat man dann Zugriff aufs Betriebssystem des Routers indem man Putty oder TeraTerm startet und als Ziel einfach die LAN IP des dd-wrt/pfsense Routers angibt.
Der Benutzername zum SSH Login ist "root" (ohne "") und das Passwort ist das, was beim Starten bzw. Installieren von DD-WRT vergeben wurde !
Die Eingabe von ps am Kommandoprompt zeigt dann eine Liste der laufenden Prozesse im Router. Findet man hier in der Liste seinen OpenVPN Daemon wieder wie im Screenshot unten zu sehen, ist alles OK und der OpenVPN Server betriebsbereit !
Ist er dort nicht zu sehen, sollte man zuerst mit dem Kommando ls -l /tmp/openvpn prüfen ob die 5 Konfig Dateien von oben korrekt im Verzeichnis /tmp/openvpn gelandet sind.
Der Output sollte so aussehen wenn alles geklappt hat:
root@Router:~# ls -l /tmp/openvpn/
-rw-r--r-- 1 root root 1189 Apr 2 12:19 ca.crt
-rw-r--r-- 1 root root 3573 Apr 2 12:19 cert.pem
-rw-r--r-- 1 root root 246 Apr 2 12:19 dh.pem
-rw-r--r-- 1 root root 888 Apr 2 12:19 key.pem
-rw-r--r-- 1 root root 257 Apr 2 12:19 openvpn.conf
-rwx------ 1 root root 36 Apr 2 12:19 route-down.sh
-rwx------ 1 root root 60 Apr 2 12:19 route-up.sh
root@Router:~#
Ist das der Fall, kann man versuchen OpenVPN manuell mit dem Kommando openvpn /tmp/openvpn/openvpn.conf zu starten.
Dabei sollten folgende Meldungen erscheinen:
root@Router:~# openvpn /tmp/openvpn/openvpn.conf
Fri Apr 2 12:34:06 2010 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Fri Apr 2 12:34:06 2010 Diffie-Hellman initialized with 1024 bit key
Fri Apr 2 12:34:06 2010 WARNING: file '/tmp/openvpn/key.pem' is group or others accessible
Fri Apr 2 12:34:06 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Apr 2 12:34:06 2010 TUN/TAP device tun0 opened
Fri Apr 2 12:34:06 2010 TUN/TAP TX queue length set to 100
Fri Apr 2 12:34:06 2010 /sbin/ifconfig tun0 172.16.2.1 pointopoint 172.16.2.2 mtu 1500
Fri Apr 2 12:34:06 2010 /sbin/route add -net 172.16.2.0 netmask 255.255.255.0 gw 172.16.2.2
Fri Apr 2 12:34:06 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Apr 2 12:34:06 2010 Socket Buffers: R=[32767->65534] S=[32767->65534]
Fri Apr 2 12:34:06 2010 UDPv4 link local (bound): [undef]:1194
Fri Apr 2 12:34:06 2010 UDPv4 link remote: [undef]
Fri Apr 2 12:34:06 2010 MULTI: multi_init called, r=256 v=256
Fri Apr 2 12:34:06 2010 IFCONFIG POOL: base=172.16.2.4 size=62
Fri Apr 2 12:34:06 2010 Initialization Sequence Completed
Ist dem so, ist alles korrekt installiert und ein <ctrl c> stoppt den OpenVPN Server im User Modus (kein Eingabeprompt) wieder, damit wir ihn nun als Daemon (Dienst) wieder starten können mit dem folgendem Kommando:
openvpn --daemon --config /tmp/openvpn/openvpn.conf
Wem das zu umständlich ist, der rebootet den DD-WRT Router schlicht und einfach indem er den Netzteil Stecker zieht !
Bei Problemen gibt der OpenVPN Server immer konkrete Fehlermeldungen von sich mit denen man Konfig Fehler dann sofort beheben
kann !
Bei OpenWRT ist das OpenVPN Handling ähnlich wie man HIER ebenfalls sehen kann.
Die grundlegenden Schritte sind wie immer gleich: CA anlegen, Server Zertifikat, Client Zertifikate.
Wer schon fertig erzeugte Zertifikate und Keys hat kann diese natürlich ebenso ganz einfach per cut an paste in die pfSense Firewall via Setup Menü übertragen um z.B. auf diese Plattform zu migrieren.
Wichtig: VPN Nutzer sollten vorher im System Setup unter Advanced -> Miscellaneous den Haken bei AES-NI CPU-based Acceleration setzen ! Das steigert die Kryptoperformance.
Zur späteren Erleichterung des Client Zertifikatexports auf Windows, Mac, Smartphone oder Tablet ist immer zusätzlich über den Packet Manager im Menü System das Packet "openvpn-client-export" zu installieren:
Zum Erstellen der Zertifikate und Keys geht man nun folgendermaßen vor:
Die pfSense Firewall hat praktischerweise ein Tool im Menü System --> Cert Manager gleich mit an Bord um die Zertifikate bequem über ein grafisches GUI zu erzeugen und auch zuexportieren für die Clients. Hier kann man auch ggf. bestehende Zertifikate von CA und Servern usw. importieren sofern die pfSense nur als VPN Client laufen soll oder in eine bereits bestehende CA integriert wird.
Dieses Tutorial geht von einer Site to Site oder einem klassischen remoten Zugang für mobile Client aus mit einer eigenen CA auf der Firewall selber.
Dazu muss man eine eigene CA generieren. Dies sollte man generell immer machen um nicht das US basierte Default Zertifikat auch für den Webzugang nutzen zu müssen.
1. Schritt: Erzeugung der CA
Am schnellsten und einfachsten geht es mit dem OpenVPN Zertifikats "Wizards" im Open VPN Menü. Deshalb ist diese Methode unbedingt zu bevorzugen wenn man sich noch an das Thema VPN herantastet. Damit geht es so gut wie fehlerfrei und klappt sofort.
Man startet den Wizard...
und klickt auf Local User Access und startet damit den...
2. Schritt: Einrichten der CA:
(Diesen Punkt kann man mit "Next" überspringen wenn man die CA schon über den Cert. Manager eingerichtet hat.)
Nachdem die CA mit Klick auf Add CA gesichert wurde kommt man zum...
3. Schritt: Generierung des Server Zertifikats:
Weiter geht es mit dem...
4. Schritt: Einrichtung des OpenVPN Servers:
Hier wird Tunnel Interface und UDP Port definiert für OVPN (Default ist UDP 1194)
Auch hier wieder wie oben der Hinweis in jedem Fall UDP als Enkapsulierungs Protokoll zu verwenden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Achtung: Unter System/Advanced/Miscellaneous/CryptographicHardware unbedingt "BSD Crypto Device" oder "AES NI and BSD Crypto Device" einstellen.
Nur "AES NI" reicht nicht. Diese wird im Wizzard nicht als Hardware Crypto erkannt.
Tunnel Network = Ist das interne VPN Netzwerk. Dieses IP Netz darf NICHT doppelt im Netz vorkommen. (Siehe Kapitel: "Wichtige Tipps zum VPN IP Adress Design !")
Local Network = Nur setzen bei einer Site to Site Koppung (CIDR Form z.B. 192.168.200.0/24). Bleibt leer bei remoten Clients
Compression = Adaptive setzen
Inter Client Comm. = Nur setzen wenn eine Client to Client Kommunikation erwünscht ist. (Entfällt in der Regel)
Hier mit "push route..." das lokale LAN zum VPN Client routen. Das Beispiel push "route 192.168.1.0 255.255.255.0" routet das lokale LAN an die Clients.
Hat man mehrere Netze, macht man mehrere Einträge oder erhöht die Maske. Z.B. routet push "route 192.168.1.0 255.255.192.0" alle Netze .0.0 bis .63.0 in den Tunnel.
Andere Funktionen belässt man im Default oder setzt die Haken nach eigenen Anforderungen.
Im letzten Schritt erzeugt der Wizzard automatisch die FW Regel für den WAN Port damit OpenVPN Pakete die Firewall passieren können und erzeugt auch eine Regel für das interne Tunnel Interface.
Wer das lieber selbst machen möchte entfernt die entsprechenden Haken.
Damit ist der OpenVPN Server fertig eingerichtet !
Es folgt dann der...
5. Schritt: Einrichtung der Clients:
Das geschieht im Menü System -> User Manager
WICHTIG: Hier den Haken setzen zum automatischen Generieren des User Zertifikats
Im Menü VPN -> OpenVPN klickt man auf Client Export
...und erhält eine Liste für die Installationsdateien aller gängigen Plattformen, die man mit einem einfachen Mausklick runterladen kann.
Unter "Bundled Configuration" erhält man als Download eine .zip Datei mit allen Daten.
Die .ovpn Datei ("Most Clients") ist hier die fertige, reine Textdatei mit den entsprechenden OVPN Kommandos wie man sie oben schon bei DD-WRT gesehen hat. Sie enthält praktischerweise auch alle erforderlichen Zertifikate.
Diese .ovpn Datei kann man entsprechend umbenenen (z.B. in client.conf bei Verwendung unter Windows, Apple Mac, Linux, RaspberryPi etc.) und sie bequem direkt im Client in das Konfig Verzeichnis kopieren. Der OVPN Client ist damit sofort "startklar". Siehe dazu auch unten im Kapitel Client Einrichtung.
Hat man alles richtig gemacht und das OpenVPN Status Panel ins Dashboard aktiviert, kann man die erfolgreiche Verbindung des Clients sehen:
Noch ein wichtiger Tip:
Wer den Client mit einem Usernamen/Passwort eingerichtet hat müsste beim Starten der VPN Client Verbindung immer den Usernamen und Passwort per Dialog eintippen, was auf die Dauer lästig ist.
Entweder vergibt man kein Passwort oder automatisiert das Ganze.
Dazu legt man mit einem Texteditor im Konfig Verzeichnis des Clients eine einfache Textdatei an z.B. login.txt mit 2 Zeilen:
<username>
<password>
Die Username und Passwort enthält. In der Konfig Datei ergänzt man dann eine Zeile:
auth-user-pass login.txt
Damit connectet der User dann vollständig automatisiert.
Die wichtigstens Schritte zum Erstellen eines OpenVPN Servers auf einem Mikrotik Router findet man in diesem Thread:
Clientverbindung OpenVPN Mikrotik
Das war alles !
Nun steht einem ersten Test mit einem OpenVPN Client nichts mehr im Wege...!!
Dies kann z.B. schnell mit einem testweise direkt oder per Switch am WAN Interface angeschlossenen PC, Mac, Linux, Smartphone oder Tabelt mit OpenVPN Client geschehen.
Damit lässt sich schnell und einfach vorab lokal das OVPN VPN auf korrekte Funktion testen bevor man es ans Internet hängt für den Fernzugriff.
Die Client Installation geht sehr einfach von der Hand. Durch die Zertifikats Generierung ist der grafische Windows Client schon installiert und das damit erzeugte Client Zertifikat sollte auch im richtigen Verzeichnis sein ist man der Anleitung oben gefolgt.
Das ist wichtig, denn ohne Client Zertifikat wird der Verbindungsversuch abgewiesen. Hat man mehrere Clients generiert man einfach mehrer Client Zertifikate und kann diese zusammen mit der Konfig Datei an remote User aushändigen.
Apple Mac Benutzer finden einen Client hier:
http://code.google.com/p/tunnelblick/
Ein Linux KDE Client gibt es hier:
http://home.gna.org/kvpnc/en/index.html
Auch der Client benötigt wie der Server eine Konfig Datei !
Man kann entweder die Standard Konfig Datei im Windows GUI über einen Rechtsklick auf das Taskleistensymbol und "Edit" editieren und nach den u.a. Vorgaben anpassen oder diese Datei hier direkt übernehmen:
client
dev tun
proto udp
remote 192.168.100.162 1194 <-- ändern auf reale OpenVPN Server IP oder DynDNS !
;remote mein-vpn-server.dyndns.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3
Screenshots des Windows Clients sieht man hier:
http://openvpn.se/screenshots.html
Auch hier gilt wieder das korrekte Eintragen des Pfades auf die Zertifikatsdateien C:/Programme/OpenVPN/easy-rsa/keys/ was aber in der Regel der Client Installer und die Skripte automatisch erledigen !
Achtung: Die obige IP Adresse 192.168.100.162 ist lediglich zum Testen im Labor hier als Beispiel !
In der realen Konfig Datei muss hier die Internet IP Adresse oder der DynDNS Hostname des Internet WAN/DSL Interfaces des Routers oder der pfsense Firewall stehen (VPN Server Zieladresse) !
Da der Linksys WRT54G und auch die pfsense FW kein integriertes DSL_Modem haben, kann man wie oben bereits erwähnt, ihn testweise mit seinem Internet Interface (Ethernet) in das lokale Netz hängen, eine IP Adresse per DHCP vergeben lassen oder statisch einstellen und so die OpenVPN Funktion sauber lokal testen bevor man ihn ans Internet hängt.
Dafür muss man die o.a. Ziel IP Adresse natürlich entsprechend anpassen in der Client Konfig Datei !!
Windows Firewall auf Client Seite.
Bei neueren Windows Versionen wie 7 und höher spielt einem oft die lokale Windows Firewall einen Streich und deklariert den virtuellen tun/tap Adapter als "Öffentlich" mit entsprechendem Profil was meist mit einem einseitigen Blocking endet.
Grund dafür: Durch das fehlende Routing identifiziert Winblows das FW Profil dann als "nicht identifiziertes Netzwerk" und blockt alles.
Hier wird erklärt wie es schnell in den Griff zu bekommen ist:
http://asktheoracle.com/blog/how-to-make-openvpn-work-with-the-windows- ...
http://www.carecom.de/de/blog/hm/blog/openvpn-unter-windows-mit-firewal ...
Die Firewall sollte für den OVPN Adapter ein "Privates Netz" Profil haben.
Klickt man nun beim OVPN Client auf Connect, kann man im aufgehenden Statusfenster genau den Connect Prozess beobachten (Log) und auch bei Fehlern reagieren !
Ist alles OK, schliesst sich das Fenster automatisch und das Taskleistensymbol wechselt auf eine grüne Farbe und zeigt in einem Balloon Tip die VPN IP an !
Ein Ping auf die LAN IP Adresse des Routers 192.168.1.1 sollte dann eine positive Antwort ergeben !
Mit einem route print in der Eingabeaufforderung bei Windows kann man anhand der Routing Tabelle sehen ob alle Netze korrekt über das VPN geroutet werden ! Es zeigt also ob das "push route..." Kommando im Server korrekt erkannt wurde !
Damit ist der VPN Tunnel dann korrekt aufgebaut und bietet einen Zugriff auf alle Endgeräte im remoten Netz ! Weitere IP Netze auf der remoten (Server) Seite lassen sich per push "route <ip_netz_adresse> <mask>" in der Server Konfig Datei dynmaisch auf den Client übertragen so das ein sauberes Routing stattfindet.
Ein wichtiges Augenmerk sollte immer auf die Windows Firewall oder ggf. eine zusätzlich installierte Personal FW geworfen werden wenn andere PCs im Netzwerk erreicht werden müssen !!
In der Regel blockt die FW fremde IP Netze (..und das VPN ist ein solches fremdes IP Netz !!) gnadenlos, so das man hier in den erweiterten Eigenschaften unter Ports den Bereich unbedingt auf "Alle Rechner inkl. Internet" erweitern sollte.
pfsense bietet zudem noch über seine System Logs eine detailierte Möglichkeit die Aktivität des OpenVPN Servers zu beobachten und zu Troubleshooten und hat hier einen Vorteil gegenüber dd-wrt, das diese Möglichkeit nicht besitzt !!
DD-WRT Benutzern ist nicht entgangen das der DD-WRT Router ebenfalls einen OpenVPN Client an Bord hat.
Damit ist der DD-WRT Router in der Lage auf alle OpenVPN Server eine VPN Verbindung mit OpenVPN aufzubauen und so einfach und sehr preiswert eine Standort VPN Vernetzung (LAN to LAN) zu realisieren, was auch vollkommen problemlos funktioniert.
Allerdings gibt es eine DD-WRT Besonderheit zu beachten:
Der DD-WRT OVPN Client nimmt es mit dem Begriff Client VPN sehr genau. Er macht nämlich am Tunnelinterface des VPN Tunnel auch ein NAT (Masquerading).
Das ist insofern fatal, als das damit eine Verbindung ins Client LAN von anderen LANs nicht möglich ist, denn das verhindert die NAT Firewall am Tunnelinterface.
Es ist also immer nur eine Verbindung remotes Standort Netzwerk am Router (OpenVPN Client) zum VPN Server und dessen Netzwerke möglich. Also sogesehen eine Einbahnstrasse.
Für viele Standort VPN Verbindungen die nur Resourcen am zentralen Standort nutzen mag das vollkommen ausreichen. Für die die auch Resourcen im Client LAN (transparente LAN zu LAN Kopplung) nutzen müssen, ist es fatal.
Das DD-WRT Wiki hat auch einen entsprechenden Eintrag dafür:
http://www.dd-wrt.com/wiki/index.php/OpenVPN#GUI_Client_Mode_Disabling_ ...
wie andere Wikis ebenso....
http://cyberdelia.de/2011/03/ddwrt-openvpn-nat-und-lan2lan-kopplung.htm ...
Mit den Patches ist dann ein transparentes LAN to LAN VPN problemlos mit dem DD-WRT Client realisierbar.
Wer die dort geposteten Workarounds vermeiden will muss sich derzeit nach einer anderen Firmware umsehen wie OpenWRT, Tomato usw. die diese NAT Einschränkung beim OVPN Client nicht aufweist.
Alternative ist dann auf einen anderen Router mit OpenVPN Client Option auszuweichen wie Raspberry Pi, pfSense, Mikrotik usw. usw.
Ein weiterer wichtiger Hinweis für die folgende Standort zu Standort VPN Kopplung mit DD-WRT:
Bei allen OVPN Server Konfigs die einen DD-WRT Client Router bedienen darf niemals das Konfig Kommando "client-to-client" in die Server.conf eintragen sein, da sonst keine Verbindung ins remote LAN möglich ist !
"client-to-client" darf nur in die server.conf Datei, wenn nur 2 Clients existieren, also ausschliesslich eine Road Worrior (remote User) Lösung betrieben wird um remote Einzeluser zu bedienen, die auch untereinander kommunizieren dürfen. In der Regel ist das nicht der Fall das Clients untereinander kommunizieren, da VPN Clients ausschliesslich Resourcen zentral im lokalen LAN nutzen.
Mit dem Statement "client-to-client" ist die Verbindung zum remoten LAN bei einer Site to Site Kopplung mit DD-WRT nicht mehr möglich, folglich also darf dieses Kommando auf der Serverseite NICHT verwenden in solchen VPN LAN zu LAN Setups !
Ist das so eingestellt kann man auch die SPI Firewall des DD-WRT problemlos einschalten.
(Dank an Forumsmitglied @orcape für diesen hilfreichen Tip !)
Der GL.inet_Router ist eine sehr interessante HW Plattform. Sie ist sehr preiswert, eignet sich als universaler, portabler Reise OpenVPN Router oder generell als sparsamer OpenVPN Router für den Heimbereich und das sowohl als Client als auch Server.
Sein großer Vorteil ist das mit OpenWRT ein freies Betriebssystem im Hintergrund auf dem Router werkelt und ihn so beliebig erweiterbar macht zu einem Router mit fast einem Profi Featureset. OpenVPN ist im Default schon an Bord sodas keine extra Installation erforderlich ist.
Die GL.inet_Router_Hardware gibt es bei allen üblichen Versandhändlern.
Wie immer ist der erste Schritt ein Update auf die aktuelle_Firmware_Version.
Nach einem Reboot und Einrichtung eines Admin Passworts fährt man mit der Grundinstallation wie IP Adressierung, Uhrzeit usw. fort !
(Wird fortgesetzt...)
Natürlich ist mit der gleichen Einstellung zusätzlich zur Client Einwahl auch sehr einfach eine sog. Site-to-Site Standortvernetzung mit OpenVPN zu realsieren.
Als Beispiel sei folgendes Design angenommen:
Es sind lediglich 2 Standorte mit den Netzen 172.32.10.0 /24 und 172.32.20.0 /24 hinzugekommen. Diese Anzahl an Standorten kann man beliegig erhöhen. Wichtig ist, das oben in der Schlüsselerzeugung auch eine entsprechende Anzahl von Client Schlüsseln erzeugt wurde (Bsp. "client1....clientx")
Die Server Konfiguration wird dazu entsprechend erweitert:
Um auch eine Kommunikation der Standortnetze untereinander zu gewährleisten muss der Haken bei "Client to Client VPN" gesetzt sein ! (Ist eine Kommunikation der Standortnetze untereinander nicht gewünscht lässt man dies weg !)
Der erste Route Befehl leitet alle Pakete aus dem Netz der Zentrale zu den Standortnetzen ins VPN.
Die beiden anderen Route Befehle setzen die Routen an den Standort VPN Routern automatisch so, das Daten ins Netz der Zentrale und zum anderen Standort ebenfalls ins VPN geroutet werden.
Die Konfig wird nun gesichert und folgende Dinge im Reiter "Client Specific Configuration" eingestellt: (Beispiel hier für Standort-1 mit dem Client Key common name client1 )
Hier klickt man auf das "+" und fügt eine Konfig ein und trägt den "Common Name" des oben bei der Schlüsselerzeugung eingegebenen Client Common Names ein (Bsp. hier client1 )
Das Kommando iroute 172.32.10.0 255.255.255.0 blockt eigene, lokale Pakete vom VPN Tunnel.
Das wiederholt man anlog mit einem weiteren "+" für alle lokalen Standortnetze !
Damit ist die Server Konfiguration abgeschlossen.
Die Standorte
Der Standort Router wird wie folgt konfiguriert mit einem Klick auf VPN --> OpenVPN und Client.:
Hier ist lediglich der DynDNS Hostnamen des Routers in der Zentrale oder dessen öffentliche Internet IP als Ziel anzugeben.
"Cryptography" ist wieder auf AES-128-Bit CBC einzustellen wie oben im Server (Wichtig: muss übereinstimmend sein !)
"Authentication" ist auch analog wieder auf PKI zu setzen und die erzeugten Client Keys (client1....clinetx usw.) von oben per cut and paste einzutragen !
Custom Options auf "float" setzen um Adressänderungen bei ggf. doppeltem NAT im Providernetz zu akzeptieren.
Mit der Beschreibung am Ende ist die Client Installation dann abgeschlossen und der Standort wird sich nach dem Klick auf "Save" zur Sicherung sofort mit dem Router der Zentrale verbinden und den VPN Tunnel aufbauen. Das kann man im Systemlog von pfSense kontrollieren !
Damit ist dann die transparente Netzwerk Vernetzung der Standorte mit der Zenrale und unter sich funktionsbereit, was man mit einem Ping der Endgeräte verifizieren kann.
Achtung: Nicht vergessen, da man aus fremden IP Netzen kommt ggf. immer die lokale Firewall anpassen !
Eine sehr interessante Option bietet OpenVPN noch Betreibern einer Windows Domain die am Hauptstandort einen DC mit DNS zentral betreiben.
OpenVPN kann automatisch DNS Anfragen der Standorte an lokale Domainnamen an den DNS abfangen und somit problemlos ohne Klimmzüge lokal auflösen.
Dazu definiert man in den Clients unter Services --> DNS Forwarder einfach die lokale Domain und die dazugehörige DNS Server IP Adresse des DCs.
Damit ist dann auch die Domain Integration der Standorte im Handumdrehen erledigt.
In der Regel hat man schon einen bestehenden NAT (DSL, KabelTV) Router im Netzwerk und möchte dieses Netz mit dem o.a. OpenVPN Server auf einer DD-WRT oder pfSense Firewall erweitern für den VPN Zugriff.
Dies ist ebenso möglich allerdings muss man dann einige Dinge zusätzlich beachten, da der VPN Tunnel erst durch den vorgeschalteten Router hindurch muss (Port Forwarding) !
Die folgende Abbildung zeigt so ein klassisches Design:
Hierbei sind nun folgende Dinge zwingend zu beachten:
und es muss eine Regel definiert sein die OpenVPN Pakete auf die WAN IP Adresse der Firewall erlaubt ! (Default UDP 1194)
Diese Prozedur ist HIER im Kapitel "Installation und Integration ins Netzwerk" und dann "Installation in ein bestehendes Netzwerk mit Router" genau beschrieben !
Beachtet man alle diese Punkte funktioniert auch so ein Design hinter einem NAT Router absolut problemlos !
Gleiches gilt im Übrigen auch für einen OVPN Server der im lokalen LAN angeschlossen ist !
Hier wird fast immer die erforderliche statische Route im Internet Router Setup vergessen. Am Beispiel der FritzBox sieht das gem. der u.a. Netzwerk Zeichnung dann so aus:
Hier muss eine statische Route auf das interne OpenVPN IP Netz eingetragen werden, denn nur so kann der Internet Router die Pakete der VPN Clients auch wieder richtig routen. Ohne diese Route gehen sie per Default Route im Internet Router an den Provider und damit ins "Nirwana! !
Siehe dazu auch dieser_Forumsthread !
Analog dann ein Design bei dem OpenVPN Client und Server im lokalen Netzwerk hinter dem NAT Router liegen:
Wichtiger Tip zum einfachen vorab Testen der fehlerfreien OpenVPN Funktion:
Bevor man den Zugriff von extern über das Internet ausprobiert, testet man die Funktion erst einmal lokal um sicher zu gehen das alles korrekt funktioniert.
Dazu hängt man den OpenVPN Client ganz einfach per Kabel oder WLAN in das "Verbindungs LAN" und gibt in der OpenVPN Client Konfig Datei die Ziel IP des OpenVPN Routers im "Verbindungs LAN" an. (Hier im Beispiel die 192.168.1.254 dann in der Konfig Datei mit der Zeile remote 192.168.1.254 1194 !)
Bei einem Verbindungstest sollte sofort eine gültige VPN Verbindung zustande kommen. (Client Log).
Ein paar zusätzliche Troubleshooting Tips findet man auch auf der OpenVPN_Webseite
Dieser Vorabtest sollte IMMER fehlerfrei durchlaufen, denn so kann man absolut sicher gehen das die OpenVPN Konfiguration selber fehlerfrei ist.
Nachträgliche Fehler oder Verbindungsprobleme liegen dann meist an Firewall Einstellungen am Client oder NAT Routern im Signalweg ! Man kann die Suche dann einzig auf die FW Konfiguration konzentrieren und muss nicht mehr bei der OpenVPN Konfiguration suchen.
Klappt also alles fehlerfrei bis hierhin steht einem finalen Zugriffstest aus dem großen weiten Internet nichts mehr im Wege !
Es gehört zu den goldenen Regeln eines vorausschauenden VPN Designs das lokales und remotes Netzwerk NIEMALS gleich sein dürfen !!
Ist ja auch logisch, da so ein Routing der remoten Netze bei Gleichheit vollkommen unmöglich wird.
Viele Laien wählen als IP Netzwerk die allseits bekannten IP Netze 192.168.1.0 /24 oder 192.168.2.0 /24 usw. da diese oft per Default von allen Consumer DSL (Speedport usw.) und Kabelroutern verwendet werden und zuhauf im Einsatz sind.
192.168.178.0 /24 scheidet ebenfalls aus, da jede FritzBox dieses Netz lokal verwendet ! Niemand macht sich die Mühe das umzustellen und übernimmt oft kritiklos und häufig auch aus Unwissen diese Standard Einstellungen !
Die Folge davon ist das diese IP Netze in vielen öffentlichen Netzen wie in Hotels, Hotspots, Flughäfen und (leider) auch zahllosen Firmennetzen benutzt werden.
Tritt dann IP Gleichheit der remoten und lokalen VPN Netze ein, macht das einen VPN Betrieb technisch unmöglich !
Es ist daher dringend angeraten beim Aufbau und Planung von VPN Zugängen immer etwas exotischere IP Netze für sein lokales LAN zu wählen die einen IP Adresskonflikt dadurch nahezu unmöglich machen und einen störungsfreien VPN Betrieb ermöglichen.
Sieht man sich einmal den RFC-1918 (Private IP Netze) etwas genauer an der die IP Adresskontingente für Private Netze global festlegt:
http://de.wikipedia.org/wiki/Private_IP-Adresse
erkennt man schnell das man sich nicht mit banalen 192.168er IP Adressen abfinden muss, sondern auch noch den Block im 172er und 10er Bereich hat.
Wählt man nun bei der VPN Planung etwas IP netztechnisch "Exotisches" für die Adressierung wie z.B.
192.168.217.0 /24 = 255.255.255.0 24 Bit Adress Maske
oder
172.24.1.0 /24
oder
10.168.70.0 /24
oder oder oder....
kann man sich relativ sicher sein das ein IP Adresskonflikt durch gleiche IP Netze doch sehr sehr selten ist und man sich VPN Probleme gleich von Anfang an aus der (IP) Welt schafft !
Eine andere Alternative ist den Adressbereich des RFC_6598 zu verwenden der für CGN Provider geschaffen ist. (100.64.0.0 /10)
Hiermit geht man dann ganz sicher niemals in irgendeinem der RFC 1918 privaten Adressbereiche zu liegen. Es birgt aber den Nachteil das ggf. in Handynetzen das VPN nicht funktioniert wenn dieses Netz an Endgeräte vergeben wird wie z.B. bei Vodafone.
Letztendlich wird so mit einer etwas intelligenten und vorausschauenden Wahl der VPN IP Adressen dauerhaft ein störungsfreier Betrieb des VPNs erreicht !
Weitere Optionen sind der VPN Tunnelaufbau über Proxy Server und andere Features die OpenVPN bietet. Weitergehende Infos bietet hier die Documentation auf der OpenVPN Seite:
http://www.openvpn.net/index.php/open-source/documentation.html
Eine Standort Vernetzung mit der VPN Funktion der FritzBox ist mit OpenVPN nicht möglich, denn die FB spricht ein anderes VPN Protokoll (IPsec) was nicht kompatibel ist !
Lösung: Man flasht die FB mit der alternativen freetz Firmware wie wieder OVPN supportet.
Eine heterogene Standortvernetzung ist aber problemlos mit FB und Monowall/pfSense möglich nutzt man das IPsec Protokoll.
Dieses Tutorial beschreibt die einzelnen Schritte:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
OpenVPN Grundlagen Tutorials im hiesigen Forum:
Merkzettel: VPN Installation mit OpenVPN
OpenVPN - Teil 1 - Installation, Konfiguration und erstellung der Zertifikate
OpenVPN - Teil 2 - OpenVPN Konfiguration
OpenVPN mit separatem Server und Client im lokalen LAN statt integriert im Internet Router/Firewall:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Problem DS-Lite Anschluss: OpenVPN mit Vermittlungsserver:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
OpenWRT / DD-WRT Router mit OpenVPN: Probleme mit der LAN zu LAN VPN Anbindung sicher umschiffen:
Problem mit site 2 site VPN
Drucken über VPN - CCD Files
Raspberry Pi als OpenVPN Server und Client:
http://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Netzwerk Management Server mit Raspberry Pi
Forentutorial zur OVPN Standort Kopplung:
PfSense - Kopplung dreier Netze via OpenVPN
OpenVPN Standort Kopplung gemischt mit einer IPsec Standort Kopplung:
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client
Mikrotik OpenVPN Konfig Details:
Clientverbindung OpenVPN Mikrotik
OVPN Client Finetuning:
OpenVPN Delegationen
Pfsense OpenVpn TLS Failure
OpenVPN Zugang mit Radius Server absichern:
PfSense, openVPN und FreeRadius -Anfängerfrage
DS-Lite Anschluss und VPN: Lösung mit Vermittlungsserver und fester IP:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
Tücken bei remotem Port Forwarding in den OpenVPN Tunnel beachten !!:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
L2TP VPN mit Mikrotik Router:
Mikrotik VPN Verbindung L2TP, IPSec inkl. Anleitung Windows 7 VPN konfiguration
L2TP VPN mit pfSense/OPNsense Firewall:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Praxistutorial IPsec VPNs:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Praxistutorial Wireguard:
Merkzettel: VPN Installation mit Wireguard
Das folgende Tutorial gibt einen Leitfaden für eine preiswerte und effiziente VPN Installation die sowohl zur Anbindung remoter Mitarbeiter als auch zur Netzkopplung eingesetzt werden kann auf Basis der sehr populären VPN Lösung OpenVPN.
Inhaltsverzeichnis
Allgemeine Einleitung
Dieses Tutorial basiert auf den bei Administrator.de bereits bestehenden Tutorials von datasearch zum Einrichten eines OpenVPN Servers:
OpenVPN_Teil_2
Wobei hier der Schwerpunkt auf dem Teil 1 zur Erstellung der Schlüssel für Client und Server liegt.
Die Installation die der OpenVPN Teil 2 beschreibt ist, bedingt durch die andere Hardware eines DD-WRT Routers oder der pfSense Weboberfläche zum Konfigurieren folgerichtig etwas unterschiedlich zu einer PC basierten Installation.
Dadurch aber noch einfacher auch für Laien zu realisieren, da alles mit einer einfachen Weboberfläche konfiguriert wird !
Als Alternative zu einer Installation auf Windows oder Linux kommt hier die platzsparendere Variante direkt in einem Router mit DD-WRT Firmware oder der freien Firewall/Router Software pFsense zum Einsatz.
Die VPN Funktion ist somit nicht abhängig von Serverhardware sondern autark auf einer Netzwerkkomponente, was außer der Platz Ersparniss zudem erheblich kostengünstiger ist in der Unterhaltung und vom Hardwareaufwand.
OpenVPN ist eine sehr weit verbreitete freie VPN Lösung mit Client Software für nahezu alle gängigen Betriebssysteme.
Durch ihre Flexibilität erlaubt sie z.B. das wahlfreie Konfigurieren des Tunnel Ports so das dieser z.B. vom Standard UDP 1194 auch auf den gängigen SSL Port TCP 443 gelegt werden kann, um mit der VPN Verbindung problemlos Firewall und Accesslisten ohne einen zusätzlichen Eingriff zu überwinden.
Das Tutorial benutzt die Default Einstellungen von OpenVPN und auch DD-WRT. Anpassungen an vorhandene IP Netzwerk Adressierung ist dann individuell nach vorhandener IP Adressierung zu machen.
Eine Schemazeichnung für das Netzwerkdesign sieht so aus:
Bzw. mit der pFsense Variante dann analog:
Die o.a. Bilder sind nur Schema Zeichnungen zur Funktion. Es besteht keine Beschränkung auf nur einen Client ! Natürlich sind auch Mehrfachverbindungen, sei es per Netz zu Netz Kopplung oder mit remoten Clients, möglich !
Hardware Voraussetzungen
pfSense
Die Hardware für die pfSense Variante kann entweder PC basierend sein mit einer preiswerten CF Flashkarte als verschleissfreiem Datenträger für den Dauerbetrieb wie HIER im Kapitel Download und Installation beschrieben.
Auch ein alter PC lässt sich so bequem recyceln.
Viel kosteneffizenter im Hinblick auf den Stromverbrauch und erheblich robuster für den Dauerbetrieb ist aber immer eine kleine, preiswerte Appliance im Eigenbau oder Fertiggerät wie in_diesem_Tutorial beschrieben.
DD-WRT
Hardware Basis ist, wie oben bereits bemerkt, ein Router mit der freien DD-WRT Firmware wie er auch VPN Einrichtung (PPTP) mit DSL Routern und DD-WRT Firmware schon beschrieben ist. Solche Router sind heute meist in Form eines Linksys WRT54GL im Handel (z.B. Reichelt oder Alternate). Teilweise sogar schon mit geflashter DD-WRT Firmware.
Weitere bekannte Plattformen für DD-WRT sind Router der Fa. Buffalo wie der bekannte WZR HP-G300NH oder im unteren Preissegment um die 20 Euro der DLink-DIR 300 und 600 und der TP-Link TL-WR841N
DD-WRT ist auch für andere Router Plattformen von Linksys, NetGear, TP-Link u.a. frei verfügbar ! Eine genaue Übersicht über unterstützte Router Hardware bietet das DD-WRT Wiki:
http://www.dd-wrt.com/wiki/index.php/Supported_Devices
oder die interaktive Router Datenbank:
http://www.dd-wrt.com/dd-wrtv3/dd-wrt/hardware.html
Eine deutsche Projektbeschreibung findet man hier:
http://www.dd-wrt.com/wiki/index.php/DD-WRT_Doku_%28DE%29
Als DD-WRT Router Hardware für das folgende Tutorial dient der populäre WRT54GL, der mit der aktuellen DD-WRT (V24 SP2) geflasht wurde. Das Vorgehen bei anderen Modellen ist aber identisch !
Wichtig ist hier das WRT54 Image xx24-VPN_generic (Man achte auf das "VPN" im Imagenamen ! Version 24) denn das enthält den OpenVPN Server und auch einen Client. Mit dem Client kann ein DD-WRT Router selber OpenVPN Client sein. Dieses Tutorial behandelt die Serverfunktion als VPN Dialin Server und am Beispiel der Standortvernetzung auch die Installation als Client.
Das aktuelle Image zum Download und Flashen für einen Linksys WRT54G findet man auf der DD-WRT Seite wenn man seine Router Modellbezeichnung wie z.B. "WRT-54GL" dort eingibt:
http://www.dd-wrt.com/site/support/router-database
OpenVPN Clients
OVPN Clients sind für nahezu sämtliche Betriebssysteme am Markt erhältlich:
https://openvpn.net/index.php?option=com_content&id=357
Auch für alle gängigen Smartphones ist die "OpenVPN Connect" App kostenlos im App Store verfügbar:
OpenVPN hat gerade für Clients einen erheblichen Vorteil da es ein SSL VPN bereitstellt was nur ein Tunnelprotokoll benötigt und so erheblich leichter NAT Firewalls überwinden lässt als z.B. IPsec.
Zudem ist es erheblich besser mit zusätzlichen Features ausgezeichnet und einer sehr flexiblen Konfiguration wie das folgende Tutorial zeigt.
OpenVPN Zertifikate und Schlüssel
Beschrieben wird hier die sichere VPN Installation mit Zertifikaten und bewusst nicht mit den einfachen Klartext Passwörtern. Wird so ein Passwort einmal kompromittiert ist das ganze VPN kompromitiert. Bei Zertifikaten ist das nicht der Fall.
Da OpenVPN auf dem Router selber schon durch die DD-WRT Firmware oder pfSense Firmware installiert ist, ist es lediglich erforderlich die erzeugten Schlüssel und die Konfig Datei auf den Router oder die pfSense Firewall zu übertragen.
Auch das ist sehr einfach, lediglich per Cut and Paste, über die webbasierte Installationsseite des Routers zu erledigen. Das ist schon alles um OpenVPN auf dem Router oder der pfsense Firewall/Router zu aktivieren !
Zwingende Voraussetzung ist das Erzeugen der Schlüssel, will man nicht mit einfachen preshared Keys arbeiten, was natürlich auch geht aber sehr unsicher ist (Siehe oben) !
Dazu läd man sich am besten erstmal das komplette Installations Paket des grafischen Windows OpenVPN Clients herunter und installiert es. Das Paket hat schon fertige Skripts (Easy-RSA) zum einfachen und bequemen Generieren der Schlüssel gleich mit an Bord:
http://openvpn.se/
bzw.:
http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-instal ...
Alternativ geht das auch auf allen anderen OVPN Plattformen die diese Skripts alle mitliefern.
Das Erzeugen der Schlüssel und Zertifikate ist damit kinderleicht zu machen.
Die dazu nötigen Schritte sind detailiert im bereits oben erwähnten OpenVPN_Teil_1 Tutorial, auch für Laien verständlich, beschrieben.
Auch das HowTo auf der OpenVPN Projektseite erklärt dieses in einer einfachen Schritt für Schritt Anleitung:
http://www.openvpn.net/index.php/open-source/documentation/howto.html#p ...
ebenso HIER.
Man geht also lediglich in die Eingabeaufforderung von Windows (analog auch MacOS oder Linux), wechselt in das easy-rsa Skriptverzeichnis und führt einfach nacheinander, wie beschrieben, diese Skripte aus und sichert sich so seine Schlüssel z.B. auf einem USB Stick.
Die Schritte im Schnellverfahren unter Windows sehen so aus: (OpenVPN GUI muss zuvor installiert sein !)
- Eingabeaufforderung öffnen und mit cd ins Verzeichnis "C:\Programme\OpenVPN\easy-rsa" wechseln.
- Mit dem Editor die Datei vars.bat editieren und nur im unteren Teil die Variablen nach seinen persönlichen Vorgaben/Einstellungen anpassen. Z.B.:
set KEY_PROVINCE=Niedersachsen
set KEY_CITY=Hannover
set KEY_ORG=Meyer GmbH
set KEY_EMAIL=name@email.de
- Datei vars.bat sichern
- Nun in der Eingabeaufforderung die folgenden Kommandos aufrufen: Zuerst vars , dann clean-all und dann build-ca wie es im HowTo steht !
- Die Abfragen nach dem Start von "build-ca" kann man allesamt mit der Eingabetaste bestätigen außer der Fragen nach dem Common name ! Hier trägt man z.B. ein "server" oder "OpenVPN" oder einen anderen spezifischen Namen. Das Feld darf NICHT leerbleiben ! Der Common Name entspricht dann auch später dem Dateinamen des Schlüssels ! Also server.key oder OpenVPN.key bzw. server.crt oder OpenVPN.crt
- Jetzt weiter wie im Tutorial verfahren und in der gleichen Eingabeaufforderung das Kommando build-key-server server eingeben (Erzeugung Schlüssel für den Server) und hier ebenfalls wieder zwingend bei der Abfrage Common name z.B. "server" eingeben oder den Servernamen. Die Frage nach dem Passwort quittiert man mit einem Druck auf die Eingabetaste und die beiden folgenden Fragen "sign certificate" und "...commit" beantwortet man unbedingt mit einem y (yes) !!
- Jetzt die Client Keys (Schlüssel für die remoten Benutzer) erzeugen mit dem Kommando build-key client1. Hier wiederum bei der schon bekannten "Common name" Abfrage "client1" eingeben. Anlog verfährt man für weitere Clients mit build-key client2 bzw. build-key client3, build-key client4 usw. für die Anzahl der Clients die man benötigt. Man kann später weitere Client Keys genau so erzeugen. "Common name" Abfrage wieder entsprechend... "client2"....."client3"...usw. Auch hier ist wieder der Common Name entsprechend Name der Client Schlüsseldatei z.B. client1.key bzw. client1.crt !
- Zum Schuß die Diffie-Hellmann Parameter mit dem Kommando build-dh erzeugen....
- Fertig...!
Die Inhalte sind mit dem Editor oder Wordpad editierbar.
Das Easy-RSA Tool wird unter Linux genau so bedient wenn man den Server z.B. auf einem Raspberry Pi usw. installiert.
Zertifikate und Schlüssel grafisch Online oder per (GUI) mit XCA Programm erzeugen*
Wer Kommandozeilen nicht mag und die Zertifikate und Schlüssel lieber mit einer grafischen Oberfläche erzeugen will, findet mit dem Tool XCA dafür ein idelaes Werkzeug.
Die Anwendung ist für alle 3 wichtigen Betriebssysteme (Windows, Mac OS-X und Linux) in der aktuellen Version 2.2.1 hier verfügbar:
https://www.hohnstaedt.de/xca/
Sogar in einer portablen Version die keinerlei Installation erfordert !
Eine auch für Laien einfach zu verstehende Anleitung findet sich hier:
http://www.carbonwind.net/VPN/XCA_OpenVPN/XCA_OpenVPN.htm
Noch einfacher ist die Schlüsselerzeugung Online ! Webseiten wie z.B.:
http://www.mobilefish.com/services/ssl_certificates/ssl_certificates.ph ...
erledigen das per Mausklick ohne weitere Zusatzsoftware.
Damit ist ein Erzeugen der Schlüssel dann auch für Kommandozeilen "Muffel" eine einfache Sache von ein paar Mausklicks !
Installation auf dem DD-WRT Router
OK, sind nun der Router oder die pfsense Firewall fertig geflasht bzw. installiert und über ihr jeweiliges Konfigurations Webinterface erreichbar und auch die 4 Schlüssel ca.crt, server.crt, server.key und dh1024.pem erzeugt wie oben beschrieben kanns losgehen... !!!
Dazu kopiert man diese 4 Schlüssel Dateien ggf. auf einen Stick oder den Rechner zum Konfigurieren und dann kann die eigentliche Konfiguration des DD-WRT Routers oder der pfsense Firewall beginnen:
Nach Vergabe der Zugangspasswörter bei DD-WRT beim ersten Connect auf die Setup Webseite unter 192.168.1.1 (Default), klickt man auf das Menü Services -> VPN und aktiviert hier den OpenVPN Daemon mit dem Start Type WAN up was bedeutet das der OpenVPN Server immer dann gestartet wird wenn das WAN Interface aktiv ist !
Danach öffnen sich 7 freie Textfelder zur Eingabe:
Public Server Cert
Certificate revoke list ==>> bleibt leer !
Public Client cert
Private Client key
DH pem
OpenVPN config
OpenVPN TLS Auth ==>> bleibt leer !!
In 4 dieser Felder cut und pasted (Kopieren und Einfügen) man nun seine 4 oben erzeugten Schlüsseldaten rein.
Alle Schlüsseldateien sind reine ASCII Textdateien und lassen sich mit dem Word Pad oder einem Text Editor öffnen. Ist der Schlüssel oder Zertifikat editiert, klickt man unter "Bearbeiten" dann auf "Alles markieren" und dann "Kopieren".
Darauf wechselt man in das Textfenster der Routerkonfig mit einem Rechtsklick und "Einfügen" um den Inhalt hier ins Textfeld zu kopieren.
Diese Prozedur macht man jetzt Fenster für Fenster nach folgendem Schema:
Public Server Cert ==>> Master Zertifikat, ca.crt Datei
Certificate revoke list ==>> bleibt leer !!
Public Client cert ==>> Server Zertifikat, server.crt Datei
Private Client key ==>> Server Key, server.key
DH pem ==>> DH Parameter, dh1024.pem Datei
OpenVPN config OpenVPN Konfig Datei, z.B. Beispiel unten
OpenVPN TLS Auth ==>> bleibt leer !!
Die 5te Datei ist die eigentliche OpenVPN Konfigurationsdatei für den Server. Dazu kann man die unten aufgeführte Datei in einen Editor cut and pasten und entsprechend seinen individuellen Einstellungen (IP Adressen etc.) anpassen und dann z.B. mit dem Namen "openvpn-svrconf.txt" sichern und dann per cut an paste in das Feld "OpenVPN config" im Router eingeben.
Ein Port zur Tunnel Encapsulierung: Hier sollte in jedem Fall UDP als Enkapsulierungs Protokoll verwendet werden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Die OpenVPN Konfig zum Editieren sieht dann so aus: (Kommentarzeilen in () rot vorher entfernen !!!)
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /tmp/openvpn/dh.pem (DH Parameter)
server 172.16.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0" (Default LAN IP Netz DD-WRT, muss ggf. auf verwendetes IP Netz geändert werden !!)
push "dhcp-options DNS 192.168.1.x" (Optional die IP des DNS-Server im lokalen Netz, sonst verwendet der Client den Default)
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Zusatz zur o.a. Konfig:
Wer den gesamten Traffic des Clients durch den VPN Tunnel routen möchte leitet einfach dessen Default Gateway in den VPN Tunnel um.
Statt push "route 192.168.1.0 255.255.255.0" lautet das Push Kommando dann push "redirect-gateway def1"
http://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Sehr WICHTIG ist in der o.a Server Konfigurations Datei, das die Pfadangaben oben in der Konfig /tmp/openvpn/ unbedingt stimmen für alle Dateien, denn die sind durch OpenVPN fest vorgegeben !
Ein Screenshot sieht dann so aus: (Zertifikate aus Sicherheitsgründen verkürzt wiedergegeben !)
Zum Schluss sichert dann ein Klick auf SAVE und Apply Settings die Konfig !
Der OpenVPN Client bleibt ausgeschaltet (disable) !!
WICHTIG: Normalerweise lässt die SPI Firewall des DD-WRT aus Sicherheitsgründen keine eingehenden Verbindungen und damit auch keine OVPN Verbindungen vom WAN/Internet Interface zu.
Man kann die jetzt zum Testen die SPI Firewall in den Security Einstellungen testweise abschalten, indem man den Haken bei "SPI Firewall in den Security Settings entfernt.
Damit verzichtet man aber auf einen Teil der Router Sicherheit.
Technisch besser, da sicherer und eleganter ist es, die Firewall etwas anzupassen um eigehende OVPN Sessions mit der SPI Firewall zuzulassen.
Forumsmitglied Spirit hat dazu im Fragenthread unten die Lösung gepostet die wir an dieser Stelle übernehmen:
# Akzeptiert eingehende Anfragen am Port UDP 1194.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc)
iptables -I INPUT 3 -i tun0 -j ACCEPT
# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist.
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN).
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
Wie richtet man ganz einfach diese Firewall Regeln ein:
Auf der Konfig Weboberfläche von DD-WRT geht man in Menü "Administration --> Commands" und bei Commands fügt man ganz einfach per cut and Past die obigen Zeilen ein und klickt dann "Save Firewall" !
FERTIG...!
Zum Abschluss sollte man den Router nun neu booten lassen (Einmal stromlos machen !)
Damit ist die Konfiguration des Routers abgeschlossen und einem ersten Test des OpenVPN Servers steht nichts mehr im Wege !
Ist der OpenVPN Server aktiv ?
Leider muss man alle oben beschriebenen Einstellungen über das Websetup blind machen mit Vertrauen alles richtig gemacht zu haben. Man kann leider nicht über die Status Seite den OpenVPN Server im Router auf seine korrekte Funktion überprüfen.
Für die detailierte Fehlersuche ist das aber kein Hinderniss denn die Lösung dafür ist bei DD-WRT recht einfach !
DD-WRT bietet einen Terminalzugang per Telnet oder SSH auf die Konsole !
Der Telnet Zugriff funktioniert sofort über die LAN IP.
Wer es etwas sicherer haben möchte nimmt SSH:
Dafür aktiviert man im Menü Services -> Services mit einem Klick auf enable einfach den SSHd Daemon und sichert diese Einstellung mit SAVE und APPLY.
Mit einem Windows Telnet und SSH Client wie dem bekannten PUTTY oder auch TeraTerm (Apple Macs und Linux haben SSH von sich aus an Bord) hat man dann Zugriff aufs Betriebssystem des Routers indem man Putty oder TeraTerm startet und als Ziel einfach die LAN IP des dd-wrt/pfsense Routers angibt.
Der Benutzername zum SSH Login ist "root" (ohne "") und das Passwort ist das, was beim Starten bzw. Installieren von DD-WRT vergeben wurde !
Die Eingabe von ps am Kommandoprompt zeigt dann eine Liste der laufenden Prozesse im Router. Findet man hier in der Liste seinen OpenVPN Daemon wieder wie im Screenshot unten zu sehen, ist alles OK und der OpenVPN Server betriebsbereit !
Ist er dort nicht zu sehen, sollte man zuerst mit dem Kommando ls -l /tmp/openvpn prüfen ob die 5 Konfig Dateien von oben korrekt im Verzeichnis /tmp/openvpn gelandet sind.
Der Output sollte so aussehen wenn alles geklappt hat:
root@Router:~# ls -l /tmp/openvpn/
-rw-r--r-- 1 root root 1189 Apr 2 12:19 ca.crt
-rw-r--r-- 1 root root 3573 Apr 2 12:19 cert.pem
-rw-r--r-- 1 root root 246 Apr 2 12:19 dh.pem
-rw-r--r-- 1 root root 888 Apr 2 12:19 key.pem
-rw-r--r-- 1 root root 257 Apr 2 12:19 openvpn.conf
-rwx------ 1 root root 36 Apr 2 12:19 route-down.sh
-rwx------ 1 root root 60 Apr 2 12:19 route-up.sh
root@Router:~#
Ist das der Fall, kann man versuchen OpenVPN manuell mit dem Kommando openvpn /tmp/openvpn/openvpn.conf zu starten.
Dabei sollten folgende Meldungen erscheinen:
root@Router:~# openvpn /tmp/openvpn/openvpn.conf
Fri Apr 2 12:34:06 2010 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Fri Apr 2 12:34:06 2010 Diffie-Hellman initialized with 1024 bit key
Fri Apr 2 12:34:06 2010 WARNING: file '/tmp/openvpn/key.pem' is group or others accessible
Fri Apr 2 12:34:06 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Apr 2 12:34:06 2010 TUN/TAP device tun0 opened
Fri Apr 2 12:34:06 2010 TUN/TAP TX queue length set to 100
Fri Apr 2 12:34:06 2010 /sbin/ifconfig tun0 172.16.2.1 pointopoint 172.16.2.2 mtu 1500
Fri Apr 2 12:34:06 2010 /sbin/route add -net 172.16.2.0 netmask 255.255.255.0 gw 172.16.2.2
Fri Apr 2 12:34:06 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Apr 2 12:34:06 2010 Socket Buffers: R=[32767->65534] S=[32767->65534]
Fri Apr 2 12:34:06 2010 UDPv4 link local (bound): [undef]:1194
Fri Apr 2 12:34:06 2010 UDPv4 link remote: [undef]
Fri Apr 2 12:34:06 2010 MULTI: multi_init called, r=256 v=256
Fri Apr 2 12:34:06 2010 IFCONFIG POOL: base=172.16.2.4 size=62
Fri Apr 2 12:34:06 2010 Initialization Sequence Completed
Ist dem so, ist alles korrekt installiert und ein <ctrl c> stoppt den OpenVPN Server im User Modus (kein Eingabeprompt) wieder, damit wir ihn nun als Daemon (Dienst) wieder starten können mit dem folgendem Kommando:
openvpn --daemon --config /tmp/openvpn/openvpn.conf
Wem das zu umständlich ist, der rebootet den DD-WRT Router schlicht und einfach indem er den Netzteil Stecker zieht !
Bei Problemen gibt der OpenVPN Server immer konkrete Fehlermeldungen von sich mit denen man Konfig Fehler dann sofort beheben
kann !
Bei OpenWRT ist das OpenVPN Handling ähnlich wie man HIER ebenfalls sehen kann.
OpenVPN Installation auf der pfSense Firewall
Die grundlegenden Schritte sind wie immer gleich: CA anlegen, Server Zertifikat, Client Zertifikate.
Wer schon fertig erzeugte Zertifikate und Keys hat kann diese natürlich ebenso ganz einfach per cut an paste in die pfSense Firewall via Setup Menü übertragen um z.B. auf diese Plattform zu migrieren.
Wichtig: VPN Nutzer sollten vorher im System Setup unter Advanced -> Miscellaneous den Haken bei AES-NI CPU-based Acceleration setzen ! Das steigert die Kryptoperformance.
Zur späteren Erleichterung des Client Zertifikatexports auf Windows, Mac, Smartphone oder Tablet ist immer zusätzlich über den Packet Manager im Menü System das Packet "openvpn-client-export" zu installieren:
Zum Erstellen der Zertifikate und Keys geht man nun folgendermaßen vor:
Zertifikate und Schlüssel grafisch im pfSense GUI erzeugen
Die pfSense Firewall hat praktischerweise ein Tool im Menü System --> Cert Manager gleich mit an Bord um die Zertifikate bequem über ein grafisches GUI zu erzeugen und auch zuexportieren für die Clients. Hier kann man auch ggf. bestehende Zertifikate von CA und Servern usw. importieren sofern die pfSense nur als VPN Client laufen soll oder in eine bereits bestehende CA integriert wird.
Dieses Tutorial geht von einer Site to Site oder einem klassischen remoten Zugang für mobile Client aus mit einer eigenen CA auf der Firewall selber.
Dazu muss man eine eigene CA generieren. Dies sollte man generell immer machen um nicht das US basierte Default Zertifikat auch für den Webzugang nutzen zu müssen.
1. Schritt: Erzeugung der CA
Am schnellsten und einfachsten geht es mit dem OpenVPN Zertifikats "Wizards" im Open VPN Menü. Deshalb ist diese Methode unbedingt zu bevorzugen wenn man sich noch an das Thema VPN herantastet. Damit geht es so gut wie fehlerfrei und klappt sofort.
Man startet den Wizard...
und klickt auf Local User Access und startet damit den...
2. Schritt: Einrichten der CA:
(Diesen Punkt kann man mit "Next" überspringen wenn man die CA schon über den Cert. Manager eingerichtet hat.)
Nachdem die CA mit Klick auf Add CA gesichert wurde kommt man zum...
3. Schritt: Generierung des Server Zertifikats:
Weiter geht es mit dem...
4. Schritt: Einrichtung des OpenVPN Servers:
Hier wird Tunnel Interface und UDP Port definiert für OVPN (Default ist UDP 1194)
Auch hier wieder wie oben der Hinweis in jedem Fall UDP als Enkapsulierungs Protokoll zu verwenden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Achtung: Unter System/Advanced/Miscellaneous/CryptographicHardware unbedingt "BSD Crypto Device" oder "AES NI and BSD Crypto Device" einstellen.
Nur "AES NI" reicht nicht. Diese wird im Wizzard nicht als Hardware Crypto erkannt.
Tunnel Network = Ist das interne VPN Netzwerk. Dieses IP Netz darf NICHT doppelt im Netz vorkommen. (Siehe Kapitel: "Wichtige Tipps zum VPN IP Adress Design !")
Local Network = Nur setzen bei einer Site to Site Koppung (CIDR Form z.B. 192.168.200.0/24). Bleibt leer bei remoten Clients
Compression = Adaptive setzen
Inter Client Comm. = Nur setzen wenn eine Client to Client Kommunikation erwünscht ist. (Entfällt in der Regel)
Hier mit "push route..." das lokale LAN zum VPN Client routen. Das Beispiel push "route 192.168.1.0 255.255.255.0" routet das lokale LAN an die Clients.
Hat man mehrere Netze, macht man mehrere Einträge oder erhöht die Maske. Z.B. routet push "route 192.168.1.0 255.255.192.0" alle Netze .0.0 bis .63.0 in den Tunnel.
Andere Funktionen belässt man im Default oder setzt die Haken nach eigenen Anforderungen.
Im letzten Schritt erzeugt der Wizzard automatisch die FW Regel für den WAN Port damit OpenVPN Pakete die Firewall passieren können und erzeugt auch eine Regel für das interne Tunnel Interface.
Wer das lieber selbst machen möchte entfernt die entsprechenden Haken.
Damit ist der OpenVPN Server fertig eingerichtet !
Es folgt dann der...
5. Schritt: Einrichtung der Clients:
Das geschieht im Menü System -> User Manager
WICHTIG: Hier den Haken setzen zum automatischen Generieren des User Zertifikats
Export der Client Zertifikate auf die Clients
Im Menü VPN -> OpenVPN klickt man auf Client Export
...und erhält eine Liste für die Installationsdateien aller gängigen Plattformen, die man mit einem einfachen Mausklick runterladen kann.
Unter "Bundled Configuration" erhält man als Download eine .zip Datei mit allen Daten.
Die .ovpn Datei ("Most Clients") ist hier die fertige, reine Textdatei mit den entsprechenden OVPN Kommandos wie man sie oben schon bei DD-WRT gesehen hat. Sie enthält praktischerweise auch alle erforderlichen Zertifikate.
Diese .ovpn Datei kann man entsprechend umbenenen (z.B. in client.conf bei Verwendung unter Windows, Apple Mac, Linux, RaspberryPi etc.) und sie bequem direkt im Client in das Konfig Verzeichnis kopieren. Der OVPN Client ist damit sofort "startklar". Siehe dazu auch unten im Kapitel Client Einrichtung.
Hat man alles richtig gemacht und das OpenVPN Status Panel ins Dashboard aktiviert, kann man die erfolgreiche Verbindung des Clients sehen:
Noch ein wichtiger Tip:
Wer den Client mit einem Usernamen/Passwort eingerichtet hat müsste beim Starten der VPN Client Verbindung immer den Usernamen und Passwort per Dialog eintippen, was auf die Dauer lästig ist.
Entweder vergibt man kein Passwort oder automatisiert das Ganze.
Dazu legt man mit einem Texteditor im Konfig Verzeichnis des Clients eine einfache Textdatei an z.B. login.txt mit 2 Zeilen:
<username>
<password>
Die Username und Passwort enthält. In der Konfig Datei ergänzt man dann eine Zeile:
auth-user-pass login.txt
Damit connectet der User dann vollständig automatisiert.
Mikrotik Router als OpenVPN Server
Die wichtigstens Schritte zum Erstellen eines OpenVPN Servers auf einem Mikrotik Router findet man in diesem Thread:
Clientverbindung OpenVPN Mikrotik
Das war alles !
Nun steht einem ersten Test mit einem OpenVPN Client nichts mehr im Wege...!!
Dies kann z.B. schnell mit einem testweise direkt oder per Switch am WAN Interface angeschlossenen PC, Mac, Linux, Smartphone oder Tabelt mit OpenVPN Client geschehen.
Damit lässt sich schnell und einfach vorab lokal das OVPN VPN auf korrekte Funktion testen bevor man es ans Internet hängt für den Fernzugriff.
Die OpenVPN Client Installation
Die Client Installation geht sehr einfach von der Hand. Durch die Zertifikats Generierung ist der grafische Windows Client schon installiert und das damit erzeugte Client Zertifikat sollte auch im richtigen Verzeichnis sein ist man der Anleitung oben gefolgt.
Das ist wichtig, denn ohne Client Zertifikat wird der Verbindungsversuch abgewiesen. Hat man mehrere Clients generiert man einfach mehrer Client Zertifikate und kann diese zusammen mit der Konfig Datei an remote User aushändigen.
Apple Mac Benutzer finden einen Client hier:
http://code.google.com/p/tunnelblick/
Ein Linux KDE Client gibt es hier:
http://home.gna.org/kvpnc/en/index.html
Auch der Client benötigt wie der Server eine Konfig Datei !
Man kann entweder die Standard Konfig Datei im Windows GUI über einen Rechtsklick auf das Taskleistensymbol und "Edit" editieren und nach den u.a. Vorgaben anpassen oder diese Datei hier direkt übernehmen:
client
dev tun
proto udp
remote 192.168.100.162 1194 <-- ändern auf reale OpenVPN Server IP oder DynDNS !
;remote mein-vpn-server.dyndns.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3
Screenshots des Windows Clients sieht man hier:
http://openvpn.se/screenshots.html
Auch hier gilt wieder das korrekte Eintragen des Pfades auf die Zertifikatsdateien C:/Programme/OpenVPN/easy-rsa/keys/ was aber in der Regel der Client Installer und die Skripte automatisch erledigen !
Achtung: Die obige IP Adresse 192.168.100.162 ist lediglich zum Testen im Labor hier als Beispiel !
In der realen Konfig Datei muss hier die Internet IP Adresse oder der DynDNS Hostname des Internet WAN/DSL Interfaces des Routers oder der pfsense Firewall stehen (VPN Server Zieladresse) !
Da der Linksys WRT54G und auch die pfsense FW kein integriertes DSL_Modem haben, kann man wie oben bereits erwähnt, ihn testweise mit seinem Internet Interface (Ethernet) in das lokale Netz hängen, eine IP Adresse per DHCP vergeben lassen oder statisch einstellen und so die OpenVPN Funktion sauber lokal testen bevor man ihn ans Internet hängt.
Dafür muss man die o.a. Ziel IP Adresse natürlich entsprechend anpassen in der Client Konfig Datei !!
Windows Firewall auf Client Seite.
Achtung beim Windows Client mit der lokalen Firewall !!
Bei neueren Windows Versionen wie 7 und höher spielt einem oft die lokale Windows Firewall einen Streich und deklariert den virtuellen tun/tap Adapter als "Öffentlich" mit entsprechendem Profil was meist mit einem einseitigen Blocking endet.
Grund dafür: Durch das fehlende Routing identifiziert Winblows das FW Profil dann als "nicht identifiziertes Netzwerk" und blockt alles.
Hier wird erklärt wie es schnell in den Griff zu bekommen ist:
http://asktheoracle.com/blog/how-to-make-openvpn-work-with-the-windows- ...
http://www.carecom.de/de/blog/hm/blog/openvpn-unter-windows-mit-firewal ...
Die Firewall sollte für den OVPN Adapter ein "Privates Netz" Profil haben.
Klickt man nun beim OVPN Client auf Connect, kann man im aufgehenden Statusfenster genau den Connect Prozess beobachten (Log) und auch bei Fehlern reagieren !
Ist alles OK, schliesst sich das Fenster automatisch und das Taskleistensymbol wechselt auf eine grüne Farbe und zeigt in einem Balloon Tip die VPN IP an !
Ein Ping auf die LAN IP Adresse des Routers 192.168.1.1 sollte dann eine positive Antwort ergeben !
Mit einem route print in der Eingabeaufforderung bei Windows kann man anhand der Routing Tabelle sehen ob alle Netze korrekt über das VPN geroutet werden ! Es zeigt also ob das "push route..." Kommando im Server korrekt erkannt wurde !
Damit ist der VPN Tunnel dann korrekt aufgebaut und bietet einen Zugriff auf alle Endgeräte im remoten Netz ! Weitere IP Netze auf der remoten (Server) Seite lassen sich per push "route <ip_netz_adresse> <mask>" in der Server Konfig Datei dynmaisch auf den Client übertragen so das ein sauberes Routing stattfindet.
Ein wichtiges Augenmerk sollte immer auf die Windows Firewall oder ggf. eine zusätzlich installierte Personal FW geworfen werden wenn andere PCs im Netzwerk erreicht werden müssen !!
In der Regel blockt die FW fremde IP Netze (..und das VPN ist ein solches fremdes IP Netz !!) gnadenlos, so das man hier in den erweiterten Eigenschaften unter Ports den Bereich unbedingt auf "Alle Rechner inkl. Internet" erweitern sollte.
pfsense bietet zudem noch über seine System Logs eine detailierte Möglichkeit die Aktivität des OpenVPN Servers zu beobachten und zu Troubleshooten und hat hier einen Vorteil gegenüber dd-wrt, das diese Möglichkeit nicht besitzt !!
Besonderheit DD-WRT Client !!
DD-WRT Benutzern ist nicht entgangen das der DD-WRT Router ebenfalls einen OpenVPN Client an Bord hat.
Damit ist der DD-WRT Router in der Lage auf alle OpenVPN Server eine VPN Verbindung mit OpenVPN aufzubauen und so einfach und sehr preiswert eine Standort VPN Vernetzung (LAN to LAN) zu realisieren, was auch vollkommen problemlos funktioniert.
Allerdings gibt es eine DD-WRT Besonderheit zu beachten:
Der DD-WRT OVPN Client nimmt es mit dem Begriff Client VPN sehr genau. Er macht nämlich am Tunnelinterface des VPN Tunnel auch ein NAT (Masquerading).
Das ist insofern fatal, als das damit eine Verbindung ins Client LAN von anderen LANs nicht möglich ist, denn das verhindert die NAT Firewall am Tunnelinterface.
Es ist also immer nur eine Verbindung remotes Standort Netzwerk am Router (OpenVPN Client) zum VPN Server und dessen Netzwerke möglich. Also sogesehen eine Einbahnstrasse.
Für viele Standort VPN Verbindungen die nur Resourcen am zentralen Standort nutzen mag das vollkommen ausreichen. Für die die auch Resourcen im Client LAN (transparente LAN zu LAN Kopplung) nutzen müssen, ist es fatal.
Das DD-WRT Wiki hat auch einen entsprechenden Eintrag dafür:
http://www.dd-wrt.com/wiki/index.php/OpenVPN#GUI_Client_Mode_Disabling_ ...
wie andere Wikis ebenso....
http://cyberdelia.de/2011/03/ddwrt-openvpn-nat-und-lan2lan-kopplung.htm ...
Mit den Patches ist dann ein transparentes LAN to LAN VPN problemlos mit dem DD-WRT Client realisierbar.
Wer die dort geposteten Workarounds vermeiden will muss sich derzeit nach einer anderen Firmware umsehen wie OpenWRT, Tomato usw. die diese NAT Einschränkung beim OVPN Client nicht aufweist.
Alternative ist dann auf einen anderen Router mit OpenVPN Client Option auszuweichen wie Raspberry Pi, pfSense, Mikrotik usw. usw.
Ein weiterer wichtiger Hinweis für die folgende Standort zu Standort VPN Kopplung mit DD-WRT:
Bei allen OVPN Server Konfigs die einen DD-WRT Client Router bedienen darf niemals das Konfig Kommando "client-to-client" in die Server.conf eintragen sein, da sonst keine Verbindung ins remote LAN möglich ist !
"client-to-client" darf nur in die server.conf Datei, wenn nur 2 Clients existieren, also ausschliesslich eine Road Worrior (remote User) Lösung betrieben wird um remote Einzeluser zu bedienen, die auch untereinander kommunizieren dürfen. In der Regel ist das nicht der Fall das Clients untereinander kommunizieren, da VPN Clients ausschliesslich Resourcen zentral im lokalen LAN nutzen.
Mit dem Statement "client-to-client" ist die Verbindung zum remoten LAN bei einer Site to Site Kopplung mit DD-WRT nicht mehr möglich, folglich also darf dieses Kommando auf der Serverseite NICHT verwenden in solchen VPN LAN zu LAN Setups !
Ist das so eingestellt kann man auch die SPI Firewall des DD-WRT problemlos einschalten.
(Dank an Forumsmitglied @orcape für diesen hilfreichen Tip !)
Installation auf dem GL.inet Router
Der GL.inet_Router ist eine sehr interessante HW Plattform. Sie ist sehr preiswert, eignet sich als universaler, portabler Reise OpenVPN Router oder generell als sparsamer OpenVPN Router für den Heimbereich und das sowohl als Client als auch Server.
Sein großer Vorteil ist das mit OpenWRT ein freies Betriebssystem im Hintergrund auf dem Router werkelt und ihn so beliebig erweiterbar macht zu einem Router mit fast einem Profi Featureset. OpenVPN ist im Default schon an Bord sodas keine extra Installation erforderlich ist.
Die GL.inet_Router_Hardware gibt es bei allen üblichen Versandhändlern.
Wie immer ist der erste Schritt ein Update auf die aktuelle_Firmware_Version.
Nach einem Reboot und Einrichtung eines Admin Passworts fährt man mit der Grundinstallation wie IP Adressierung, Uhrzeit usw. fort !
(Wird fortgesetzt...)
Standortvernetzung mit OpenVPN
Natürlich ist mit der gleichen Einstellung zusätzlich zur Client Einwahl auch sehr einfach eine sog. Site-to-Site Standortvernetzung mit OpenVPN zu realsieren.
Als Beispiel sei folgendes Design angenommen:
Es sind lediglich 2 Standorte mit den Netzen 172.32.10.0 /24 und 172.32.20.0 /24 hinzugekommen. Diese Anzahl an Standorten kann man beliegig erhöhen. Wichtig ist, das oben in der Schlüsselerzeugung auch eine entsprechende Anzahl von Client Schlüsseln erzeugt wurde (Bsp. "client1....clientx")
Die Server Konfiguration wird dazu entsprechend erweitert:
Um auch eine Kommunikation der Standortnetze untereinander zu gewährleisten muss der Haken bei "Client to Client VPN" gesetzt sein ! (Ist eine Kommunikation der Standortnetze untereinander nicht gewünscht lässt man dies weg !)
Der erste Route Befehl leitet alle Pakete aus dem Netz der Zentrale zu den Standortnetzen ins VPN.
Die beiden anderen Route Befehle setzen die Routen an den Standort VPN Routern automatisch so, das Daten ins Netz der Zentrale und zum anderen Standort ebenfalls ins VPN geroutet werden.
Die Konfig wird nun gesichert und folgende Dinge im Reiter "Client Specific Configuration" eingestellt: (Beispiel hier für Standort-1 mit dem Client Key common name client1 )
Hier klickt man auf das "+" und fügt eine Konfig ein und trägt den "Common Name" des oben bei der Schlüsselerzeugung eingegebenen Client Common Names ein (Bsp. hier client1 )
Das Kommando iroute 172.32.10.0 255.255.255.0 blockt eigene, lokale Pakete vom VPN Tunnel.
Das wiederholt man anlog mit einem weiteren "+" für alle lokalen Standortnetze !
Damit ist die Server Konfiguration abgeschlossen.
Die Standorte
Der Standort Router wird wie folgt konfiguriert mit einem Klick auf VPN --> OpenVPN und Client.:
Hier ist lediglich der DynDNS Hostnamen des Routers in der Zentrale oder dessen öffentliche Internet IP als Ziel anzugeben.
"Cryptography" ist wieder auf AES-128-Bit CBC einzustellen wie oben im Server (Wichtig: muss übereinstimmend sein !)
"Authentication" ist auch analog wieder auf PKI zu setzen und die erzeugten Client Keys (client1....clinetx usw.) von oben per cut and paste einzutragen !
Custom Options auf "float" setzen um Adressänderungen bei ggf. doppeltem NAT im Providernetz zu akzeptieren.
Mit der Beschreibung am Ende ist die Client Installation dann abgeschlossen und der Standort wird sich nach dem Klick auf "Save" zur Sicherung sofort mit dem Router der Zentrale verbinden und den VPN Tunnel aufbauen. Das kann man im Systemlog von pfSense kontrollieren !
Damit ist dann die transparente Netzwerk Vernetzung der Standorte mit der Zenrale und unter sich funktionsbereit, was man mit einem Ping der Endgeräte verifizieren kann.
Achtung: Nicht vergessen, da man aus fremden IP Netzen kommt ggf. immer die lokale Firewall anpassen !
Domain Integration (DNS)
Eine sehr interessante Option bietet OpenVPN noch Betreibern einer Windows Domain die am Hauptstandort einen DC mit DNS zentral betreiben.
OpenVPN kann automatisch DNS Anfragen der Standorte an lokale Domainnamen an den DNS abfangen und somit problemlos ohne Klimmzüge lokal auflösen.
Dazu definiert man in den Clients unter Services --> DNS Forwarder einfach die lokale Domain und die dazugehörige DNS Server IP Adresse des DCs.
Damit ist dann auch die Domain Integration der Standorte im Handumdrehen erledigt.
OpenVPN hinter einem NAT Internet Router betreiben
In der Regel hat man schon einen bestehenden NAT (DSL, KabelTV) Router im Netzwerk und möchte dieses Netz mit dem o.a. OpenVPN Server auf einer DD-WRT oder pfSense Firewall erweitern für den VPN Zugriff.
Dies ist ebenso möglich allerdings muss man dann einige Dinge zusätzlich beachten, da der VPN Tunnel erst durch den vorgeschalteten Router hindurch muss (Port Forwarding) !
Die folgende Abbildung zeigt so ein klassisches Design:
Hierbei sind nun folgende Dinge zwingend zu beachten:
- Der WAN Anschluss der der DD-WRT oder pfSense Plattform wird mit dem LAN Anschluss des Internet Routers verbunden.
- Auf dem WAN Port stellt man im Setup Menü eine statische IP Adresse die im LAN IP Netz des vorliegenden NAT Routers liegt und zwar außerhalb dessen DHCP Bereichs um IP Adressüberschneidungen zu vermeiden. Bewährt haben sich IP Adressen "ganz oben" wie z.B. 192.168.1.254 (Beispiel oben. Bei einer FritzBox z.B. 192.168.178.254 usw.) Ebenso ist das Default Gateway und die DNS Server IP auf die LAN IP Adresse des vorliegenden Routers einzustellen ! Alternativ kann man den WAN Port im Setup Auswahlmenü auch im DHCP Modus (Client) betreiben. Warum das nicht ganz so gut ist beschreibt der nächste Punkt.
- Im vorliegenden Router muss eine Port Weiterleitung des UDP Ports 1194 (OpenVPN Default) lokal auf die statische WAN IP Adresse des OpenVPN Routers eingetragen werden. Da diese Port Weiterleitung statisch ist, ist es sehr sinnvoll auch die OVPN Router WAN IP statisch zu setzen. DHCP ginge ebenso, allerdings besteht die Gefahr das sich aufgrund der Dynamik von DHCP diese IP einmal ändert und dann laufen die OpenVPN Pakete von der Port Weiterleitung ins Leere. Es gilt also: "DHCP gut...statisch ist besser !"
- Zusätzlicher Punkt nur für die DD-WRT Plattform: DD-WRT MUSS hier im Gateway Modus laufen und die SPI Firewall muss deaktiviert werden ! Dieser Punkt gilt NICHT für pfSense !!
- Soll der OpenVPN Client das VPN über einen DynDNS Namen bzw. Account erreichen, MUSS dieser DynDNS Dienst auf dem vorliegenden Router aktiviert werden und NICHT auf dem OpenVPN Router ! Logisch, da der OpenVPN Client ja nur die öffentliche IP des vorliegenden Routers sehen kann, der dann ja eingehende UDP 1194 Pakete (OpenVPN default) dann aber weiterleitet auf den OpenVPN Router. VPN Server Ziel ist also immer die öffentliche WAN/DSL Adresse des vorliegenden Routers !
- Wichtig ist darauf zu achten, das sich die IP Adressen des Verbindungs LANs, des lokalen LANs und auch des internen OpenVPN Servernetzes nicht doppeln oder überschneiden ! Hier ist also auf eine korrekte IP Adressierung zu achten. Es gelten wie immer die goldenen_VPN-Regeln beim IP Design !
- Wichtig für pfSense: Hier ist unbedingt der Haken "Block private Networks" am WAN Port zu entfernen, andernfalls blockt die Firewall alle Pakete am WAN Port wenn ein Router davor liegt !
und es muss eine Regel definiert sein die OpenVPN Pakete auf die WAN IP Adresse der Firewall erlaubt ! (Default UDP 1194)
Diese Prozedur ist HIER im Kapitel "Installation und Integration ins Netzwerk" und dann "Installation in ein bestehendes Netzwerk mit Router" genau beschrieben !
Beachtet man alle diese Punkte funktioniert auch so ein Design hinter einem NAT Router absolut problemlos !
Gleiches gilt im Übrigen auch für einen OVPN Server der im lokalen LAN angeschlossen ist !
Hier wird fast immer die erforderliche statische Route im Internet Router Setup vergessen. Am Beispiel der FritzBox sieht das gem. der u.a. Netzwerk Zeichnung dann so aus:
Hier muss eine statische Route auf das interne OpenVPN IP Netz eingetragen werden, denn nur so kann der Internet Router die Pakete der VPN Clients auch wieder richtig routen. Ohne diese Route gehen sie per Default Route im Internet Router an den Provider und damit ins "Nirwana! !
Siehe dazu auch dieser_Forumsthread !
Analog dann ein Design bei dem OpenVPN Client und Server im lokalen Netzwerk hinter dem NAT Router liegen:
Wichtiger Tip zum einfachen vorab Testen der fehlerfreien OpenVPN Funktion:
Bevor man den Zugriff von extern über das Internet ausprobiert, testet man die Funktion erst einmal lokal um sicher zu gehen das alles korrekt funktioniert.
Dazu hängt man den OpenVPN Client ganz einfach per Kabel oder WLAN in das "Verbindungs LAN" und gibt in der OpenVPN Client Konfig Datei die Ziel IP des OpenVPN Routers im "Verbindungs LAN" an. (Hier im Beispiel die 192.168.1.254 dann in der Konfig Datei mit der Zeile remote 192.168.1.254 1194 !)
Bei einem Verbindungstest sollte sofort eine gültige VPN Verbindung zustande kommen. (Client Log).
Ein paar zusätzliche Troubleshooting Tips findet man auch auf der OpenVPN_Webseite
Dieser Vorabtest sollte IMMER fehlerfrei durchlaufen, denn so kann man absolut sicher gehen das die OpenVPN Konfiguration selber fehlerfrei ist.
Nachträgliche Fehler oder Verbindungsprobleme liegen dann meist an Firewall Einstellungen am Client oder NAT Routern im Signalweg ! Man kann die Suche dann einzig auf die FW Konfiguration konzentrieren und muss nicht mehr bei der OpenVPN Konfiguration suchen.
Klappt also alles fehlerfrei bis hierhin steht einem finalen Zugriffstest aus dem großen weiten Internet nichts mehr im Wege !
Wichtige Tipps zum VPN IP Adress Design
Es gehört zu den goldenen Regeln eines vorausschauenden VPN Designs das lokales und remotes Netzwerk NIEMALS gleich sein dürfen !!
Ist ja auch logisch, da so ein Routing der remoten Netze bei Gleichheit vollkommen unmöglich wird.
Viele Laien wählen als IP Netzwerk die allseits bekannten IP Netze 192.168.1.0 /24 oder 192.168.2.0 /24 usw. da diese oft per Default von allen Consumer DSL (Speedport usw.) und Kabelroutern verwendet werden und zuhauf im Einsatz sind.
192.168.178.0 /24 scheidet ebenfalls aus, da jede FritzBox dieses Netz lokal verwendet ! Niemand macht sich die Mühe das umzustellen und übernimmt oft kritiklos und häufig auch aus Unwissen diese Standard Einstellungen !
Die Folge davon ist das diese IP Netze in vielen öffentlichen Netzen wie in Hotels, Hotspots, Flughäfen und (leider) auch zahllosen Firmennetzen benutzt werden.
Tritt dann IP Gleichheit der remoten und lokalen VPN Netze ein, macht das einen VPN Betrieb technisch unmöglich !
Es ist daher dringend angeraten beim Aufbau und Planung von VPN Zugängen immer etwas exotischere IP Netze für sein lokales LAN zu wählen die einen IP Adresskonflikt dadurch nahezu unmöglich machen und einen störungsfreien VPN Betrieb ermöglichen.
Sieht man sich einmal den RFC-1918 (Private IP Netze) etwas genauer an der die IP Adresskontingente für Private Netze global festlegt:
http://de.wikipedia.org/wiki/Private_IP-Adresse
erkennt man schnell das man sich nicht mit banalen 192.168er IP Adressen abfinden muss, sondern auch noch den Block im 172er und 10er Bereich hat.
Wählt man nun bei der VPN Planung etwas IP netztechnisch "Exotisches" für die Adressierung wie z.B.
192.168.217.0 /24 = 255.255.255.0 24 Bit Adress Maske
oder
172.24.1.0 /24
oder
10.168.70.0 /24
oder oder oder....
kann man sich relativ sicher sein das ein IP Adresskonflikt durch gleiche IP Netze doch sehr sehr selten ist und man sich VPN Probleme gleich von Anfang an aus der (IP) Welt schafft !
Eine andere Alternative ist den Adressbereich des RFC_6598 zu verwenden der für CGN Provider geschaffen ist. (100.64.0.0 /10)
Hiermit geht man dann ganz sicher niemals in irgendeinem der RFC 1918 privaten Adressbereiche zu liegen. Es birgt aber den Nachteil das ggf. in Handynetzen das VPN nicht funktioniert wenn dieses Netz an Endgeräte vergeben wird wie z.B. bei Vodafone.
Letztendlich wird so mit einer etwas intelligenten und vorausschauenden Wahl der VPN IP Adressen dauerhaft ein störungsfreier Betrieb des VPNs erreicht !
Weitere Optionen sind der VPN Tunnelaufbau über Proxy Server und andere Features die OpenVPN bietet. Weitergehende Infos bietet hier die Documentation auf der OpenVPN Seite:
http://www.openvpn.net/index.php/open-source/documentation.html
Eine Standort Vernetzung mit der VPN Funktion der FritzBox ist mit OpenVPN nicht möglich, denn die FB spricht ein anderes VPN Protokoll (IPsec) was nicht kompatibel ist !
Lösung: Man flasht die FB mit der alternativen freetz Firmware wie wieder OVPN supportet.
Eine heterogene Standortvernetzung ist aber problemlos mit FB und Monowall/pfSense möglich nutzt man das IPsec Protokoll.
Dieses Tutorial beschreibt die einzelnen Schritte:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Weiterführende Links
OpenVPN Grundlagen Tutorials im hiesigen Forum:
Merkzettel: VPN Installation mit OpenVPN
OpenVPN - Teil 1 - Installation, Konfiguration und erstellung der Zertifikate
OpenVPN - Teil 2 - OpenVPN Konfiguration
OpenVPN mit separatem Server und Client im lokalen LAN statt integriert im Internet Router/Firewall:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Problem DS-Lite Anschluss: OpenVPN mit Vermittlungsserver:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
OpenWRT / DD-WRT Router mit OpenVPN: Probleme mit der LAN zu LAN VPN Anbindung sicher umschiffen:
Problem mit site 2 site VPN
Drucken über VPN - CCD Files
Raspberry Pi als OpenVPN Server und Client:
http://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Netzwerk Management Server mit Raspberry Pi
Forentutorial zur OVPN Standort Kopplung:
PfSense - Kopplung dreier Netze via OpenVPN
OpenVPN Standort Kopplung gemischt mit einer IPsec Standort Kopplung:
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client
Mikrotik OpenVPN Konfig Details:
Clientverbindung OpenVPN Mikrotik
OVPN Client Finetuning:
OpenVPN Delegationen
Pfsense OpenVpn TLS Failure
OpenVPN Zugang mit Radius Server absichern:
PfSense, openVPN und FreeRadius -Anfängerfrage
DS-Lite Anschluss und VPN: Lösung mit Vermittlungsserver und fester IP:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
Tücken bei remotem Port Forwarding in den OpenVPN Tunnel beachten !!:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Alternativen mit anderen VPN Protokollen
L2TP VPN mit Mikrotik Router:
Mikrotik VPN Verbindung L2TP, IPSec inkl. Anleitung Windows 7 VPN konfiguration
L2TP VPN mit pfSense/OPNsense Firewall:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Praxistutorial IPsec VPNs:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Praxistutorial Wireguard:
Merkzettel: VPN Installation mit Wireguard
Please also mark the comments that contributed to the solution of the article
Content-ID: 123285
Url: https://administrator.de/contentid/123285
Printed on: October 11, 2024 at 03:10 o'clock
160 Comments
Latest comment
Hallo zusammen,
habe das eben mal ausprobiert, denke habe aber einen Schreibfehler gefunden:
Serverconfig:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /etc/openvpn/dh.pem (DH Parameter)
server 172.16.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0" (Default LAN IP Netz DD-WRT)
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
der Pfad zu DH musste ich von " /etc/openvpn/dh.pem " auf " /tmp/openvpn/dh.pem " andern, sonst konnte ich den server nicht starten
Aber leider komme ich nicht weiter, ich nutze dies sonst als routing auf einem Rechenr installiert und gebe die enstprechenden Routen im Router ein.
Ich kann mit dieser Serverconfig nicht auf mein Netz hinter dem Router zugreifen und weiss auch nicht die virtuelle IP des VPNServers,
kann hier noch jemand helfen ?
habe das eben mal ausprobiert, denke habe aber einen Schreibfehler gefunden:
Serverconfig:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt (Master Zertifikat)
cert /tmp/openvpn/cert.pem (Server Zertifikat)
key /tmp/openvpn/key.pem (Server Key)
dh /etc/openvpn/dh.pem (DH Parameter)
server 172.16.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0" (Default LAN IP Netz DD-WRT)
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
der Pfad zu DH musste ich von " /etc/openvpn/dh.pem " auf " /tmp/openvpn/dh.pem " andern, sonst konnte ich den server nicht starten
Aber leider komme ich nicht weiter, ich nutze dies sonst als routing auf einem Rechenr installiert und gebe die enstprechenden Routen im Router ein.
Ich kann mit dieser Serverconfig nicht auf mein Netz hinter dem Router zugreifen und weiss auch nicht die virtuelle IP des VPNServers,
kann hier noch jemand helfen ?
Hallo ,
danke für Deine Antwort, ich hatte einen mtu Parameter in meiner Clientconfig, dieses hatt größe Auswirkung auf die Verbindung.
Verbinden funktioniert nun einwandfrei.
Den "push route" Befehl habe ich auf meine lokale LAN Ip angepasst.
Ich kann nun zwar den OpenVPN Server via Virtueller-IP und physikalischer Router-IP erreichen, allerdings erreiche ich keinen Client dahinter. Habe auch zusätzlich im Router noch eine static route in das vpn Netz eingetragen, leider auch ohne Erfolg ?
danke für Deine Antwort, ich hatte einen mtu Parameter in meiner Clientconfig, dieses hatt größe Auswirkung auf die Verbindung.
Verbinden funktioniert nun einwandfrei.
Den "push route" Befehl habe ich auf meine lokale LAN Ip angepasst.
Ich kann nun zwar den OpenVPN Server via Virtueller-IP und physikalischer Router-IP erreichen, allerdings erreiche ich keinen Client dahinter. Habe auch zusätzlich im Router noch eine static route in das vpn Netz eingetragen, leider auch ohne Erfolg ?
Hallo zusammen,
Danke für dieser Tutorial, er ist echt supper.
leider ist Openvpn noch nicht aktiv.
Ich bekomme diese Fehlermeldung:
Thu Jan 28 15:49:51 2010 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Thu Jan 28 15:49:51 2010 Diffie-Hellman initialized with 1024 bit key
Thu Jan 28 15:49:51 2010 Cannot load private key file /tmp/openvpn/key.pem: erro r:0D0680A8:lib(13):func(104):reason(168): error:0D06C03A:lib(13):func(108):reaso n(58): error:0D08303A:lib(13):func(131):reason(58): error:0D09A00D:lib(13):func( 154):reason(13): error:0907B00D:lib(9):func(123):reason(13): error:140B0009:lib( 20):func(176):reason(9)
Thu Jan 28 15:49:51 2010 Error: private key password verification failed
Thu Jan 28 15:49:51 2010 Exiting
root@DD-WRT:~# Cannot load private key file /tmp/openvpn/key.pem
mein generierter Private key sieht so aus:
BEGIN RSA PRIVATE KEY-----
MIIB7TCCAVYCAQAwgZcxCzAJBgNVBAYTAkRFMRowGAYDVQQIExFCYWRlbnd1ZXJ0
dGVtYmVyZzESMBAGA1UEBxMJdHVlYmluZ2VuMRQwEgYDVQQKEwtGb3J0RnVuc3Rv
bjEcMBoGA1UEAxMTbnRvZmZpY2UuZHluZG5zLm9yZzEkMCIGCSqGSIb3DQEJARYV
YW1pbmUyMDY3QGhvdG1haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDQNbKxBXbqIjB7R9XCmg689uQc5LparL6zvKtzfM5cJKzcHR78tNRsP27zu8OA
Q/NlLBKW7XB+wHjVskRbvD1uFWwKA78aRk8MvHOpUF3J7UJU3TH+zxc61eQA6z5D
*
*
*
TD6DOKjzKL52oQRy7oLmYv4=
END RSA PRIVATE KEY-----
Ich würde sehr Dankbar sein für eure hilfe
Danke im Voraus
Amine
Danke für dieser Tutorial, er ist echt supper.
leider ist Openvpn noch nicht aktiv.
Ich bekomme diese Fehlermeldung:
Thu Jan 28 15:49:51 2010 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Thu Jan 28 15:49:51 2010 Diffie-Hellman initialized with 1024 bit key
Thu Jan 28 15:49:51 2010 Cannot load private key file /tmp/openvpn/key.pem: erro r:0D0680A8:lib(13):func(104):reason(168): error:0D06C03A:lib(13):func(108):reaso n(58): error:0D08303A:lib(13):func(131):reason(58): error:0D09A00D:lib(13):func( 154):reason(13): error:0907B00D:lib(9):func(123):reason(13): error:140B0009:lib( 20):func(176):reason(9)
Thu Jan 28 15:49:51 2010 Error: private key password verification failed
Thu Jan 28 15:49:51 2010 Exiting
root@DD-WRT:~# Cannot load private key file /tmp/openvpn/key.pem
mein generierter Private key sieht so aus:
BEGIN RSA PRIVATE KEY-----
MIIB7TCCAVYCAQAwgZcxCzAJBgNVBAYTAkRFMRowGAYDVQQIExFCYWRlbnd1ZXJ0
dGVtYmVyZzESMBAGA1UEBxMJdHVlYmluZ2VuMRQwEgYDVQQKEwtGb3J0RnVuc3Rv
bjEcMBoGA1UEAxMTbnRvZmZpY2UuZHluZG5zLm9yZzEkMCIGCSqGSIb3DQEJARYV
YW1pbmUyMDY3QGhvdG1haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDQNbKxBXbqIjB7R9XCmg689uQc5LparL6zvKtzfM5cJKzcHR78tNRsP27zu8OA
Q/NlLBKW7XB+wHjVskRbvD1uFWwKA78aRk8MvHOpUF3J7UJU3TH+zxc61eQA6z5D
*
*
*
TD6DOKjzKL52oQRy7oLmYv4=
END RSA PRIVATE KEY-----
Ich würde sehr Dankbar sein für eure hilfe
Danke im Voraus
Amine
hallo aqui,
Danke für die Antwort.
Ich habe alle schritte genau verfolgt, ich habe 3 mal die keys generiert am anfang hatte ich Probleme mit CA aber danach mit key.pem.
mein ls-l Output sieht so aus:
root@DD-WRT:~# ls -l /tmp/openvpn
-rw------- 1 root root 1338 Jan 28 15:49 ca.crt
-rw------- 1 root root 3827 Jan 28 15:49 cert.pem
-rw------- 1 root root 245 Jan 28 15:49 dh.pem
-rw------- 1 root root 737 Jan 28 15:49 key.pem
-rw------- 1 root root 255 Jan 28 15:49 openvpn.conf
-rwx------ 1 root root 36 Jan 28 15:49 route-down.sh
-rwx------ 1 root root 60 Jan 28 15:49 route-up.sh
root@DD-WRT:~#
Vielleicht kannst du mir worauf ich achten muss beim Keys generieren.
Vielen Dank
Amine
Danke für die Antwort.
Ich habe alle schritte genau verfolgt, ich habe 3 mal die keys generiert am anfang hatte ich Probleme mit CA aber danach mit key.pem.
mein ls-l Output sieht so aus:
root@DD-WRT:~# ls -l /tmp/openvpn
-rw------- 1 root root 1338 Jan 28 15:49 ca.crt
-rw------- 1 root root 3827 Jan 28 15:49 cert.pem
-rw------- 1 root root 245 Jan 28 15:49 dh.pem
-rw------- 1 root root 737 Jan 28 15:49 key.pem
-rw------- 1 root root 255 Jan 28 15:49 openvpn.conf
-rwx------ 1 root root 36 Jan 28 15:49 route-down.sh
-rwx------ 1 root root 60 Jan 28 15:49 route-up.sh
root@DD-WRT:~#
Vielleicht kannst du mir worauf ich achten muss beim Keys generieren.
Vielen Dank
Amine
Hallo;
ich versuche auch schon seit Tagen,ein funktionierendes OpenVPN auf einem DD-WRT-Router zu installieren. Es scheitert jedoch immer mit folgender Fehlermeldung:
Error: private key password verification failed
Cannot load private key file /tmp/openvpn/key.pem
Die key.pem ist aber dort,wo sie sein sollte. Ich habe das mit der o.g. Anleitung (die wirklich narrensicher ist) immer und immerwieder durchgespielt. Ich habe auch mehrere Router (WRT54GL und WRT610N) mit jeweils verschiedenen Softwareversionen ausprobiert. Ich habe auch mal ausprobiert,die Keys mit WinSCP zu übertragen;fehlgeschlagen
Außerdem habe ich die Keys auch mit XCA erstellt;das Ergebnis ist immer wieder das selbe.
Vielleicht hat der ein oder andere von euch eine zündende Idee oder einen Hinweis,was ich noch tun könnte.
Vielen Dank im voraus.
Gruß,
AGU96
ich versuche auch schon seit Tagen,ein funktionierendes OpenVPN auf einem DD-WRT-Router zu installieren. Es scheitert jedoch immer mit folgender Fehlermeldung:
Error: private key password verification failed
Cannot load private key file /tmp/openvpn/key.pem
Die key.pem ist aber dort,wo sie sein sollte. Ich habe das mit der o.g. Anleitung (die wirklich narrensicher ist) immer und immerwieder durchgespielt. Ich habe auch mehrere Router (WRT54GL und WRT610N) mit jeweils verschiedenen Softwareversionen ausprobiert. Ich habe auch mal ausprobiert,die Keys mit WinSCP zu übertragen;fehlgeschlagen
Außerdem habe ich die Keys auch mit XCA erstellt;das Ergebnis ist immer wieder das selbe.
Vielleicht hat der ein oder andere von euch eine zündende Idee oder einen Hinweis,was ich noch tun könnte.
Vielen Dank im voraus.
Gruß,
AGU96
Die Dateirechte habe ich noch nicht gecheckt;was müsste denn da stehen?
Ich habe die Schlüssel erzeugt unter Windows (Win7 Ultimate 64 Bit) mit dem aktuellsten OpenVPN Installer 2.1.1 in der Eingabeaufforderung gemacht. Testweise auch einmal wie oben beschrieben mit XCA. Das mit dem Binary-Modus habe ich an anderer Stelle gelesen und auch ausprobiert.
Ich habe die Schlüssel erzeugt unter Windows (Win7 Ultimate 64 Bit) mit dem aktuellsten OpenVPN Installer 2.1.1 in der Eingabeaufforderung gemacht. Testweise auch einmal wie oben beschrieben mit XCA. Das mit dem Binary-Modus habe ich an anderer Stelle gelesen und auch ausprobiert.
Hallo aqui,
ich kann es zwar jetzt nicht ausprobieren (weil ich im verlängerten Osterwochenende bin);aber ich bin guter Dinge das ich es nun mit deiner Ergänzung hinbekommen werde. Vielen Dank,das du dir soviel Mühe gemacht hast;auch danke für den Download.
Ich melde mich dann mal am Mittwoch zurück.
Bye,
AGU96
ich kann es zwar jetzt nicht ausprobieren (weil ich im verlängerten Osterwochenende bin);aber ich bin guter Dinge das ich es nun mit deiner Ergänzung hinbekommen werde. Vielen Dank,das du dir soviel Mühe gemacht hast;auch danke für den Download.
Ich melde mich dann mal am Mittwoch zurück.
Bye,
AGU96
Habe gerade mal mit WinSCP auf den Router geschaut, im Verzeichniss "temp/openvpn" liegen die Daten, das heisst, man müsste hier nur die config anpassen und den Zertifikate hier ablegen, werde das ggf. heute Abend mal probieren.
Hoffe das in der Sicherung des Routers alles enthalten ist, falls das nicht funktioniert.
Hoffe das in der Sicherung des Routers alles enthalten ist, falls das nicht funktioniert.
Hallo,
so habe das soweit mal schnell probiert, aus dem Webfronend des Routers das Zertifikat entfernt.
.Das Skript habe ich angepasst und im Webfrontend belassen
pkcs12 /tmp/openvpn/server.p12
die alten Verweise CA usw. habe ich versucht mit # aus zukommentieren, das geht nicht,
dementsprechend habe ich Sie entfernt
.Den DH File habe ich im Frontend belassen.
Das pkcs12 Zertifikat habe ich per WinSCP eingeladen.
Nach einem Neustart ist dieses jedesmal nicht mehr vorhanden!! Warum ??
Wenn ich das Zertifikat nun per SCP wieder rein schreibe, kann ich vpn über putty wieder starten. Also prinzipiell funktioniert das mit p12 Zertifikaten, aber wo kann ich das ablegen damit es nach einem Routerneustart nicht gelöscht wird ?
Gruß
so habe das soweit mal schnell probiert, aus dem Webfronend des Routers das Zertifikat entfernt.
.Das Skript habe ich angepasst und im Webfrontend belassen
pkcs12 /tmp/openvpn/server.p12
die alten Verweise CA usw. habe ich versucht mit # aus zukommentieren, das geht nicht,
dementsprechend habe ich Sie entfernt
.Den DH File habe ich im Frontend belassen.
Das pkcs12 Zertifikat habe ich per WinSCP eingeladen.
Nach einem Neustart ist dieses jedesmal nicht mehr vorhanden!! Warum ??
Wenn ich das Zertifikat nun per SCP wieder rein schreibe, kann ich vpn über putty wieder starten. Also prinzipiell funktioniert das mit p12 Zertifikaten, aber wo kann ich das ablegen damit es nach einem Routerneustart nicht gelöscht wird ?
Gruß
Hallo,
kopiert habe ich die Zertifikate natürlich unter /tmp/openvpn , dort wo sie liegen.
Ich habe mich mal im dd-wrt Forum umgesehen, hoffe ich darf hier mal folgendes zitieren
Schalte den jffs sup. an und lege die PKCS12 im /jffs ab, passe deine ovpn.conf entsprechend an.
Die „normalen vpn Versionen haben aus Platz Gründen leider keinen jffs sup. mehr.
<zitat>Hintergrund zu der PKCS12 Geschichte ist
Alles was du im webIf angibst wird als nvram variable gespeichert diese werden nach einem reboot ausgelesen aus deren Inhalt wird das ganze vpn Gedöns erstellt und neu geschrieben alles andere wird gelöscht bzw. überschrieben somit auch die dort abgelegte PKCS12 . Der einzige ort wo man unter dd-wrt schreibrechte hat und auch alles dauerhaft gespeichert wird ist leider im jffs wenn du also unbedingt für den Server unter dd-wrt PKCS12 verwenden willst bleibt nur ein Wechsel der Firmware Version.>> openvpn_jffs_small.bin <zitat ende>
kopiert habe ich die Zertifikate natürlich unter /tmp/openvpn , dort wo sie liegen.
Ich habe mich mal im dd-wrt Forum umgesehen, hoffe ich darf hier mal folgendes zitieren
Schalte den jffs sup. an und lege die PKCS12 im /jffs ab, passe deine ovpn.conf entsprechend an.
Die „normalen vpn Versionen haben aus Platz Gründen leider keinen jffs sup. mehr.
<zitat>Hintergrund zu der PKCS12 Geschichte ist
Alles was du im webIf angibst wird als nvram variable gespeichert diese werden nach einem reboot ausgelesen aus deren Inhalt wird das ganze vpn Gedöns erstellt und neu geschrieben alles andere wird gelöscht bzw. überschrieben somit auch die dort abgelegte PKCS12 . Der einzige ort wo man unter dd-wrt schreibrechte hat und auch alles dauerhaft gespeichert wird ist leider im jffs wenn du also unbedingt für den Server unter dd-wrt PKCS12 verwenden willst bleibt nur ein Wechsel der Firmware Version.>> openvpn_jffs_small.bin <zitat ende>
Hallo,
bevor ich mir das mit der SD Karte antuhe ;) versuche ich lieber mal die o.g. Firmware. Das sollte eigentlich kein
Probelm sein.
Oder dann lieber doch bei der alten WebIf Eingabe, hab ein mir ein kleines Howto geschrieben welches zeigt wie man
in XCA die Zertifikate mittels GUI erstellt und dann wie diese für dd-wrt zu exportieren sind.
Anschliessend welches Zertifikat in welches WebIf feld kopiert werden müssen.
bevor ich mir das mit der SD Karte antuhe ;) versuche ich lieber mal die o.g. Firmware. Das sollte eigentlich kein
Probelm sein.
Oder dann lieber doch bei der alten WebIf Eingabe, hab ein mir ein kleines Howto geschrieben welches zeigt wie man
in XCA die Zertifikate mittels GUI erstellt und dann wie diese für dd-wrt zu exportieren sind.
Anschliessend welches Zertifikat in welches WebIf feld kopiert werden müssen.
Hallo Aqui,
cool, habe mir die Teile direkt bestellt, das muss ich doch mal testen, hoffe das läuft!
Wie hasst Du die oVPN-Config editiert bzgl. des Pfades auf die SD Karte, bzw. hasst Du die Config
im WebIf belassen und nur die Zertifikate dort abgelegt ?
Poste das bitte doch mal.
Habe die grafische Anleitung zu XCA fertig, kann ich die Dir direkt zukommen lassen ?
cool, habe mir die Teile direkt bestellt, das muss ich doch mal testen, hoffe das läuft!
Wie hasst Du die oVPN-Config editiert bzgl. des Pfades auf die SD Karte, bzw. hasst Du die Config
im WebIf belassen und nur die Zertifikate dort abgelegt ?
Poste das bitte doch mal.
Habe die grafische Anleitung zu XCA fertig, kann ich die Dir direkt zukommen lassen ?
habe eben die "jffs" FW-Version probiert und das Serverzertifikat im p12-Format, sowie den DH-File im Verzeichniss JFFS abgelegt.
Dateien werden in dieser FWE NICHT überschrieben, funktioniert wunderbar.
Allerdings hätte ich auch gern den Config File im JFFS-Verzeichniss, bzw. auf der SD Karte.
Habe hierfür als Startupbefehl " openvpn /jffs/openvpn/openvpn.conf "angegeben, damit wird leider der Server nicht automatisch beim Routerstart gestartet ?
Hasst Du eine Lösung ?
Dateien werden in dieser FWE NICHT überschrieben, funktioniert wunderbar.
Allerdings hätte ich auch gern den Config File im JFFS-Verzeichniss, bzw. auf der SD Karte.
Habe hierfür als Startupbefehl " openvpn /jffs/openvpn/openvpn.conf "angegeben, damit wird leider der Server nicht automatisch beim Routerstart gestartet ?
Hasst Du eine Lösung ?
Hallo Aqui,
ich wollte mich auch nochmal zurückmelden und mich nochmals bedanken,das du dich so für mich ins Zeug gelegt hast. Ich weiss nun,wo bei mir konkret das Problem gelegen hat.
Auch deine Keys haben bei mir am Anfang nicht funktioniert;bei keinem Router (WRT54GL;WRT320N;WRT610N). Ich bekam immer die obige Fehlermeldung. Heute morgen habe ich mal testweise das Einfügen der Keys an einem anderen Gerät (ATOM-System mit Windows XP Prof.) Und siehe da,es funktioniert;bei allen Routern sofort auf anhieb!!!
Bisher habe ich zum übertragen der Keys in das Webinterface bzw. mit WinSCP immer mein Notebook (Lenovo T-500;Win 7 Ultimate 64 Bit genommen);dort habe ich auch die gleichen Versionsstände der Browser wie auf meinem ATOM-System genommen.... Und ich habe auf diesem Notebook Firewall und Antivirusprogramm deaktiviert.... Es funktionierte nie!!!
Auch wenn mein konkretes Problem gelöst ist,so würde es mich trotzdem intressieren,wieso es auf meinen Notebook nicht funktioniert hat. Das Notebook hat übrigens eine eingebaute Intel82567LF Gigabit-LAN Schnittstelle (by the Way,ich habe sogar andere Patchkabel verwendet)...
ich wollte mich auch nochmal zurückmelden und mich nochmals bedanken,das du dich so für mich ins Zeug gelegt hast. Ich weiss nun,wo bei mir konkret das Problem gelegen hat.
Auch deine Keys haben bei mir am Anfang nicht funktioniert;bei keinem Router (WRT54GL;WRT320N;WRT610N). Ich bekam immer die obige Fehlermeldung. Heute morgen habe ich mal testweise das Einfügen der Keys an einem anderen Gerät (ATOM-System mit Windows XP Prof.) Und siehe da,es funktioniert;bei allen Routern sofort auf anhieb!!!
Bisher habe ich zum übertragen der Keys in das Webinterface bzw. mit WinSCP immer mein Notebook (Lenovo T-500;Win 7 Ultimate 64 Bit genommen);dort habe ich auch die gleichen Versionsstände der Browser wie auf meinem ATOM-System genommen.... Und ich habe auf diesem Notebook Firewall und Antivirusprogramm deaktiviert.... Es funktionierte nie!!!
Auch wenn mein konkretes Problem gelöst ist,so würde es mich trotzdem intressieren,wieso es auf meinen Notebook nicht funktioniert hat. Das Notebook hat übrigens eine eingebaute Intel82567LF Gigabit-LAN Schnittstelle (by the Way,ich habe sogar andere Patchkabel verwendet)...
Ich möchte den WRT54 nicht als WAN Router Nutzen, der hängt hinter einem anderem Router und ist per LAN angeschlossen. Also den WRT nur als OpenVPN Server laufen lassen. Deswegen habe ich die Config so ab geändert das OpenVPN das nicht bei "WAN up" startet sondern immer. Des weiteren habe die zusätzliche Firewall weggelassen.
Jetzt klappt das Connecten auf den Router und der Zugriff auf das Webinterface, aber ich komme nicht in das Netz in dem der Router ist. Was habe ich übersehen?
Jetzt klappt das Connecten auf den Router und der Zugriff auf das Webinterface, aber ich komme nicht in das Netz in dem der Router ist. Was habe ich übersehen?
@ christianW
Ja der Internetrouter ist gleichzeitig für die Rechner DHCP und/oder DNS Server.
Static Route in den Internetrouter?
Ich habe eine in den dd-wrt Router eingetragen, und zwar die zum Internetrouter. Des weiteren hat der dd-wrt Router eine feste IP außerhalb des DHPC Pool vom Internetrouter.
Auf dem Internetrouter ist nur ein Port Mapping Eintrag mit IP & Port (UDP) eingetragen, was muss da noch eingerichtet werden?
Ja der Internetrouter ist gleichzeitig für die Rechner DHCP und/oder DNS Server.
Static Route in den Internetrouter?
Ich habe eine in den dd-wrt Router eingetragen, und zwar die zum Internetrouter. Des weiteren hat der dd-wrt Router eine feste IP außerhalb des DHPC Pool vom Internetrouter.
Auf dem Internetrouter ist nur ein Port Mapping Eintrag mit IP & Port (UDP) eingetragen, was muss da noch eingerichtet werden?
Frage am Rande:
Ich habe drei Subnetze (eine Zentrale Z, zwei remote Standorte A + B); die beiden Sites A und B sollen voneinander isoliert sein, aber die Zentrale Z soll natürlich Zugriff auf A und B haben und umgekehrt sollen A und B auch Ressourcen von Z nutzen können.
-Wie erzähle ich's das denn den jetzt den WRT54G VPN-Routern in einem passenden Setup? -Insbesondere, dass sie die UDP Broadcasts auf bestimmten Ports (wie z.B. DHCP requests, aber auch andere) a) überhaupt mal weiter routen und dabei aber auch noch b) A <-> Z und B <-> Z bedienen, aber nicht in der Richtung A <-> B
Geht das überhaupt???
Danke!
Ich habe drei Subnetze (eine Zentrale Z, zwei remote Standorte A + B); die beiden Sites A und B sollen voneinander isoliert sein, aber die Zentrale Z soll natürlich Zugriff auf A und B haben und umgekehrt sollen A und B auch Ressourcen von Z nutzen können.
-Wie erzähle ich's das denn den jetzt den WRT54G VPN-Routern in einem passenden Setup? -Insbesondere, dass sie die UDP Broadcasts auf bestimmten Ports (wie z.B. DHCP requests, aber auch andere) a) überhaupt mal weiter routen und dabei aber auch noch b) A <-> Z und B <-> Z bedienen, aber nicht in der Richtung A <-> B
Geht das überhaupt???
Danke!
Hallo,
habe OpenVPN nach dem Howto wie oben beschrieben eingerichtet. Nun bekomme ich nachdem ich den Client konfiguriert habe untenstehendes Log. Der Prozess bricht an dieser Stelle ab. Die beiden Computer in der Taskleiste bleiben gelb. Irgendwann fängt der Prozess an neu zu starten und stoppt dan wieder bei der gleichen Stelle. Woran kann das liegen? Brauche drignend Hilfe!:
Thu Sep 16 18:38:59 2010 OpenVPN 2.1.3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Aug 20 2010
Thu Sep 16 18:38:59 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Sep 16 18:38:59 2010 LZO compression initialized
Thu Sep 16 18:38:59 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Sep 16 18:38:59 2010 Socket Buffers: R=[8192->8192] S=[32768->32768]
Thu Sep 16 18:38:59 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Sep 16 18:38:59 2010 Local Options hash (VER=V4): '41690919'
Thu Sep 16 18:38:59 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Sep 16 18:38:59 2010 UDPv4 link local: [undef]
Thu Sep 16 18:38:59 2010 UDPv4 link remote: ip-Adresse:1194
Thu Sep 16 18:38:59 2010 TLS: Initial packet from ipadresse:1194, sid=eba33163 e15158ff
Thu Sep 16 18:38:59 2010 VERIFY OK: depth=1, /C=DE/ST=NRW/L=Ort/O=Privat/CN=OpenVPN/emailAddress=name@firma.de
Thu Sep 16 18:38:59 2010 VERIFY OK: nsCertType=SERVER
Thu Sep 16 18:38:59 2010 VERIFY OK: depth=0, /C=DE/ST=NRW/O=Privat/CN=Server/emailAddress=name@firma.de
habe OpenVPN nach dem Howto wie oben beschrieben eingerichtet. Nun bekomme ich nachdem ich den Client konfiguriert habe untenstehendes Log. Der Prozess bricht an dieser Stelle ab. Die beiden Computer in der Taskleiste bleiben gelb. Irgendwann fängt der Prozess an neu zu starten und stoppt dan wieder bei der gleichen Stelle. Woran kann das liegen? Brauche drignend Hilfe!:
Thu Sep 16 18:38:59 2010 OpenVPN 2.1.3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Aug 20 2010
Thu Sep 16 18:38:59 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Sep 16 18:38:59 2010 LZO compression initialized
Thu Sep 16 18:38:59 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Sep 16 18:38:59 2010 Socket Buffers: R=[8192->8192] S=[32768->32768]
Thu Sep 16 18:38:59 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Sep 16 18:38:59 2010 Local Options hash (VER=V4): '41690919'
Thu Sep 16 18:38:59 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Sep 16 18:38:59 2010 UDPv4 link local: [undef]
Thu Sep 16 18:38:59 2010 UDPv4 link remote: ip-Adresse:1194
Thu Sep 16 18:38:59 2010 TLS: Initial packet from ipadresse:1194, sid=eba33163 e15158ff
Thu Sep 16 18:38:59 2010 VERIFY OK: depth=1, /C=DE/ST=NRW/L=Ort/O=Privat/CN=OpenVPN/emailAddress=name@firma.de
Thu Sep 16 18:38:59 2010 VERIFY OK: nsCertType=SERVER
Thu Sep 16 18:38:59 2010 VERIFY OK: depth=0, /C=DE/ST=NRW/O=Privat/CN=Server/emailAddress=name@firma.de
Hallo,
mein Netz sieht etwa so wie unter "OpenVPN hinter einem bestehenden NAT Router betreiben" beschrieben aus. Jetzt würde ich gerne mit dem OpenVPN Client, auf das Netzt vor dem dd-wrt Router zugreifen. Da ich so weiter den Gbit Router nutzen könnte und Kabel nicht immer umstecken müsste, um Gbit nutzen zu können.
Eigendlich müsste es doch reichen im VPN Client das Netz (im Beispiel die 192.168.1.0) als Route über die 172.16.2.0 einzutragen.
Geht das und wen ja wie?
mein Netz sieht etwa so wie unter "OpenVPN hinter einem bestehenden NAT Router betreiben" beschrieben aus. Jetzt würde ich gerne mit dem OpenVPN Client, auf das Netzt vor dem dd-wrt Router zugreifen. Da ich so weiter den Gbit Router nutzen könnte und Kabel nicht immer umstecken müsste, um Gbit nutzen zu können.
Eigendlich müsste es doch reichen im VPN Client das Netz (im Beispiel die 192.168.1.0) als Route über die 172.16.2.0 einzutragen.
Geht das und wen ja wie?
Bezogen auf das befestigen der SD Karte, ihr kennt sicherlich noch die Alten Diskettenlaufwerke 5,25 zoll, diesen anschluss kann man sehr gut nutzen um SD karten Flexibel zu benutzen. Wobei die Mini SD methode auch nicht schlecht ist ^^
Siehe Wiki: http://upload.wikimedia.org/wikipedia/commons/4/46/Floppy_buskabel.jpg
Siehe Wiki: http://upload.wikimedia.org/wikipedia/commons/4/46/Floppy_buskabel.jpg
Das er ziemlich Groß ist das stimmt allerdings, aber beim WRT hat er sehr viel Platz, habe vor Jahren ein SD Mod in meinen WRT 54g Ver. 3.1 eingebaut und der hat richtig gut platz, der Stecker hat dazu noch einen vorteil nimmt man die überflüßigen pins raus und plaziert die SD karte so das man die führung des Steckers nutzen kann so hat man die möglichkeit die sd karte immer passend und ohne viel drumher hinein und herraus zu nehmen. Aber wie schon von dir geschrieben mit einer Mini SD karte geht das natürlich auch ganz gut, damals gab es nur leider so was noch nicht ^^.
Hi zusammen,
der Thread ist zwar schon alt, meine Frage passt aber gut hier her ...
Ich habe auf pfsense (Alix-Board) einen OpenVPN-Server eingerichtet. Leider kann ich mich nicht drauf verbinden.
Das Logfile der pfsense sagt folgendes:
openvpn[19742]: Authenticate/Decrypt packet error: packet HMAC authentication failed
openvpn[19742]: TLS Error: incoming packet authentication failed from [AF_INET]91.xx.xx.xx:58355
Deaktiviere ich am Server tls-auth und kommentiere es auch in der konfig vom OpenVPN Client aus, kann ich mich problemlos verbinden.
Ich hab den KEY aus dem Webinterface der pfsense kopiert und daraus ein ta.key gemacht. Dieser liegt bei den anderen key-files Ordner..
mein *.ovpn file sieht so aus:
client
dev tun
proto udp
remote 80.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/config/CA+EDV.crt
cert C:/config/OVPN-Client1.crt
key C:/config/OVPN-Client1.key
;tls-auth C:/config/ta.key 1
;ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 3
Kann mir hier bitte wer kurz helfen damit das auch mit tls-auth funktioniert?
Danke!
lg
Stefan
der Thread ist zwar schon alt, meine Frage passt aber gut hier her ...
Ich habe auf pfsense (Alix-Board) einen OpenVPN-Server eingerichtet. Leider kann ich mich nicht drauf verbinden.
Das Logfile der pfsense sagt folgendes:
openvpn[19742]: Authenticate/Decrypt packet error: packet HMAC authentication failed
openvpn[19742]: TLS Error: incoming packet authentication failed from [AF_INET]91.xx.xx.xx:58355
Deaktiviere ich am Server tls-auth und kommentiere es auch in der konfig vom OpenVPN Client aus, kann ich mich problemlos verbinden.
Ich hab den KEY aus dem Webinterface der pfsense kopiert und daraus ein ta.key gemacht. Dieser liegt bei den anderen key-files Ordner..
mein *.ovpn file sieht so aus:
client
dev tun
proto udp
remote 80.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/config/CA+EDV.crt
cert C:/config/OVPN-Client1.crt
key C:/config/OVPN-Client1.key
;tls-auth C:/config/ta.key 1
;ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 3
Kann mir hier bitte wer kurz helfen damit das auch mit tls-auth funktioniert?
Danke!
lg
Stefan
Danke Aqui
Das habe ich gelesen aber die client.crt ist doch nicht dabei sondern die server.crt? Es gibt die möglichkeit Openvpn als installer mit allen configs drin auf pfSense zu downloaden.
System ==> Packages ==> OpenVPN Client Export Utility installieren. Dann kann unter VPN / openvpn / Client Export die Datei heruntergeladen werden.
momentan habe ich aber folgenden Fehler:
Die Rules sind eingerichtet und am Win 7 PC habe ich den Firewall zum Test deaktiviert. Ich versuche momentan von meinem LAN 192.168.0.1 auf den pfSense (WAN)192.168.0.112 / (LAN)192.168.1.0/24 Tunnel IP 10.10.0.0/24 zu gelangen bekomme aber folgende Fehler
Fri Aug 03 21:49:18 2012 OpenVPN 2.2.0 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] [IPv6 payload 20110521-1 (2.2.0)] built on May 21 2011
Enter Management Password:
Fri Aug 03 21:49:24 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Fri Aug 03 21:49:24 2012 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Fri Aug 03 21:49:24 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Aug 03 21:49:24 2012 Control Channel Authentication: using 'pfsense-udp-1194-tls.key' as a OpenVPN static key file
Fri Aug 03 21:49:24 2012 LZO compression initialized
Fri Aug 03 21:49:24 2012 UDPv4 link local (bound): [undef]:1194
Fri Aug 03 21:49:24 2012 UDPv4 link remote: 192.168.0.112:1194
Fri Aug 03 21:50:24 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Aug 03 21:50:24 2012 TLS Error: TLS handshake failed
Fri Aug 03 21:50:24 2012 SIGTERM[soft,tls-error] received, process exiting
Das habe ich gelesen aber die client.crt ist doch nicht dabei sondern die server.crt? Es gibt die möglichkeit Openvpn als installer mit allen configs drin auf pfSense zu downloaden.
System ==> Packages ==> OpenVPN Client Export Utility installieren. Dann kann unter VPN / openvpn / Client Export die Datei heruntergeladen werden.
momentan habe ich aber folgenden Fehler:
Die Rules sind eingerichtet und am Win 7 PC habe ich den Firewall zum Test deaktiviert. Ich versuche momentan von meinem LAN 192.168.0.1 auf den pfSense (WAN)192.168.0.112 / (LAN)192.168.1.0/24 Tunnel IP 10.10.0.0/24 zu gelangen bekomme aber folgende Fehler
Fri Aug 03 21:49:18 2012 OpenVPN 2.2.0 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] [IPv6 payload 20110521-1 (2.2.0)] built on May 21 2011
Enter Management Password:
Fri Aug 03 21:49:24 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Fri Aug 03 21:49:24 2012 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Fri Aug 03 21:49:24 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Aug 03 21:49:24 2012 Control Channel Authentication: using 'pfsense-udp-1194-tls.key' as a OpenVPN static key file
Fri Aug 03 21:49:24 2012 LZO compression initialized
Fri Aug 03 21:49:24 2012 UDPv4 link local (bound): [undef]:1194
Fri Aug 03 21:49:24 2012 UDPv4 link remote: 192.168.0.112:1194
Fri Aug 03 21:50:24 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Aug 03 21:50:24 2012 TLS Error: TLS handshake failed
Fri Aug 03 21:50:24 2012 SIGTERM[soft,tls-error] received, process exiting
Hallo zusammen,
ich habe wie immer Probleme mit den IP´s und dem Gateway.
Folgendes ich habe einen Router an einem großen LAN Netzwerk der Router(Linksys) zeigt mir die WAN IP: 192.168.115.250 an.
Ich soll nun per VPN eine Verbindung aufbauen von meinem rechner zu einem server in einem anderen netz.
Sprich
Client1(Mein PC): 192.168.115.140
Client2(Server): 192.168.200.2
Habe es so verstanden das der "Server" des DD-WRT Routers eine andere addresse bekommt sprich ich hab ihm einfach mal die IP:192.168.201.1 verpasst.
Meine Fragen sind hab ich mal wieder einen denkfehler? Welchen Default gateway müssen diese haben bei dem Server file des Routers welche push "route" müsste eingetragen werden?Funktioniert das überhaupt so?
EDIT:
Hab in den Router Settings noch mal nach geschaut:
Das WAN netzwerk hat die Ip: 192.168.115.250
Der Router die IP: 192.168.200.1
Alles hat als default-gateway 192.168.115.33
das war jetzt ne kleine zusatz info meine fragen bestehen weiterhin..
Mfg Chaotize
ich habe wie immer Probleme mit den IP´s und dem Gateway.
Folgendes ich habe einen Router an einem großen LAN Netzwerk der Router(Linksys) zeigt mir die WAN IP: 192.168.115.250 an.
Ich soll nun per VPN eine Verbindung aufbauen von meinem rechner zu einem server in einem anderen netz.
Sprich
Client1(Mein PC): 192.168.115.140
Client2(Server): 192.168.200.2
Habe es so verstanden das der "Server" des DD-WRT Routers eine andere addresse bekommt sprich ich hab ihm einfach mal die IP:192.168.201.1 verpasst.
Meine Fragen sind hab ich mal wieder einen denkfehler? Welchen Default gateway müssen diese haben bei dem Server file des Routers welche push "route" müsste eingetragen werden?Funktioniert das überhaupt so?
EDIT:
Hab in den Router Settings noch mal nach geschaut:
Das WAN netzwerk hat die Ip: 192.168.115.250
Der Router die IP: 192.168.200.1
Alles hat als default-gateway 192.168.115.33
das war jetzt ne kleine zusatz info meine fragen bestehen weiterhin..
Mfg Chaotize
Danke erstmal für die super antwort =).
Gut ich fang dann mal an mein Problem so ausführlich wie möglich zu schlidern =D.
Ich habe den Router entsprechent mit den Zertifikaten und den Keys ausgestattet habe die Router settings also meiner Meinung nach richtig.
Der externe Server der verbunden werden soll ist nicht für den Server des Routers zuständig sondern soll als ganz normaler Client anpingbar sein.
Der Lokaler Client(externer Server) ist dierekt mit dem Router verbunden.
Der OpenVPN Client (mein PC)ist über ecken und Kanten mit dem Router verbunden(für einstellungen). (Ist ein großes Firmen Netwerk) wie genau alles verbunden ist weis ich nicht. =(
Ich habe auf meinem Rechner die OpenVPN GUI .
Der Computer hat eine einzigartige IP der Externe Server auch und der DD-WRT Server auch.
Der OpenVPNClient IP: 192.168.115.140
Der LokalerClient IP:192.168.200.100
Der Router hat die IP:192.168.200.1
Der DD-WRT Server hat die IP:192.168.201.1
Sobald ich diese einstellungen vorgenommen habe kann ich weder Router noch irgendetwas anderes von Meinem PC anpingen. Ich schätze das liegt am Standart gateway in der Netzwerkkarten einstellung, Router einstellung und vllt auch am Config file von der OpenVPN GUI.
Ich weis nicht genau was ich als Gateway eintragen soll. also bei den CLients und beim Router. das ist eigentlich mein größtes Problem.
Und hier nochmal mein OpenVPN GUI config file
____________________________
client
dev tun
proto udp
remote 192.168.201.1 1194
;remote mein-vpn-server.dyndns.org
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3
____________________________
EDIT:
Das geschieht wenn ich versuche mit dem Client 1 zu verbinden:
Tue Aug 28 13:03:51 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Aug 28 13:03:51 2012 Re-using SSL/TLS context
Tue Aug 28 13:03:51 2012 LZO compression initialized
Tue Aug 28 13:03:51 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug 28 13:03:51 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug 28 13:03:51 2012 Local Options hash (VER=V4): '41690919'
Tue Aug 28 13:03:51 2012 Expected Remote Options hash (VER=V4): '530fdded'
Tue Aug 28 13:03:51 2012 UDPv4 link local: [undef]
Tue Aug 28 13:03:51 2012 UDPv4 link remote: 192.168.200.1:1194
hab schon mit der 192.168.201.1 versucht etc... bin nen bisschen hilflos muss ich zugeben
Hab mir das gerade nochmal Angeschaut Also ich glaube zu wissen das der Router mit dem Inet verbunden ist zumindest ist in diesem Port nen Kabel xD Das Wan Netzwerk ist glaube ich erstmal nur dafür da damit ich mit diesem Kommunizieren kann um den halt einzustellen ETC. Ist halt keine wirklich reale umgebung sondern nur ein Test oder wie mans nennen Mag so hab jetzt langsam mal nen bisschen mehr geschnallt aber meine Probleme werden dadurch nicht wirklich behoben..
Mfg Chaotize
Gut ich fang dann mal an mein Problem so ausführlich wie möglich zu schlidern =D.
Ich habe den Router entsprechent mit den Zertifikaten und den Keys ausgestattet habe die Router settings also meiner Meinung nach richtig.
Der externe Server der verbunden werden soll ist nicht für den Server des Routers zuständig sondern soll als ganz normaler Client anpingbar sein.
Der Lokaler Client(externer Server) ist dierekt mit dem Router verbunden.
Der OpenVPN Client (mein PC)ist über ecken und Kanten mit dem Router verbunden(für einstellungen). (Ist ein großes Firmen Netwerk) wie genau alles verbunden ist weis ich nicht. =(
Ich habe auf meinem Rechner die OpenVPN GUI .
Der Computer hat eine einzigartige IP der Externe Server auch und der DD-WRT Server auch.
Der OpenVPNClient IP: 192.168.115.140
Der LokalerClient IP:192.168.200.100
Der Router hat die IP:192.168.200.1
Der DD-WRT Server hat die IP:192.168.201.1
Sobald ich diese einstellungen vorgenommen habe kann ich weder Router noch irgendetwas anderes von Meinem PC anpingen. Ich schätze das liegt am Standart gateway in der Netzwerkkarten einstellung, Router einstellung und vllt auch am Config file von der OpenVPN GUI.
Ich weis nicht genau was ich als Gateway eintragen soll. also bei den CLients und beim Router. das ist eigentlich mein größtes Problem.
Und hier nochmal mein OpenVPN GUI config file
____________________________
client
dev tun
proto udp
remote 192.168.201.1 1194
;remote mein-vpn-server.dyndns.org
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/client1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3
____________________________
EDIT:
Das geschieht wenn ich versuche mit dem Client 1 zu verbinden:
Tue Aug 28 13:03:51 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Aug 28 13:03:51 2012 Re-using SSL/TLS context
Tue Aug 28 13:03:51 2012 LZO compression initialized
Tue Aug 28 13:03:51 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug 28 13:03:51 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug 28 13:03:51 2012 Local Options hash (VER=V4): '41690919'
Tue Aug 28 13:03:51 2012 Expected Remote Options hash (VER=V4): '530fdded'
Tue Aug 28 13:03:51 2012 UDPv4 link local: [undef]
Tue Aug 28 13:03:51 2012 UDPv4 link remote: 192.168.200.1:1194
hab schon mit der 192.168.201.1 versucht etc... bin nen bisschen hilflos muss ich zugeben
Hab mir das gerade nochmal Angeschaut Also ich glaube zu wissen das der Router mit dem Inet verbunden ist zumindest ist in diesem Port nen Kabel xD Das Wan Netzwerk ist glaube ich erstmal nur dafür da damit ich mit diesem Kommunizieren kann um den halt einzustellen ETC. Ist halt keine wirklich reale umgebung sondern nur ein Test oder wie mans nennen Mag so hab jetzt langsam mal nen bisschen mehr geschnallt aber meine Probleme werden dadurch nicht wirklich behoben..
Mfg Chaotize
Danke für die antwort
Nur wo nimmst du die 192.168.115.250 her ??
Tut mir echt leid wenn ich dich mit Fragen zu spamme aber sitze den ganzen Tag daran und bekomms nicht richtig hin...
Das hat keinen tieferen sinn das ist einfach nur eine Aufgabe =)
Wenn ich die im Client so ändere dann passiert das (ist trotzdem ein glücksgefühl denn wenigstens hab ich jetzt ne fehlermeldung xD) :
Tue Aug 28 15:10:04 2012 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Tue Aug 28 15:10:04 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Aug 28 15:10:04 2012 LZO compression initialized
Tue Aug 28 15:10:04 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug 28 15:10:04 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug 28 15:10:04 2012 Local Options hash (VER=V4): '41690919'
Tue Aug 28 15:10:04 2012 Expected Remote Options hash (VER=V4): '530fdded'
Tue Aug 28 15:10:04 2012 UDPv4 link local: [undef]
Tue Aug 28 15:10:04 2012 UDPv4 link remote: 192.168.115.250:1194
Tue Aug 28 15:10:04 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:06 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:09 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:11 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:13 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:15 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:18 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:20 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:22 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:24 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:26 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:28 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:30 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:31 2012 TCP/UDP: Closing socket
Tue Aug 28 15:10:31 2012 SIGTERM[hard,] received, process exiting
Weiteres problem erkannt und zwar wird das ca.cert nicht mit übernommen und abgespeichert weis aber nicht warum das so ist ...
Nur wo nimmst du die 192.168.115.250 her ??
Tut mir echt leid wenn ich dich mit Fragen zu spamme aber sitze den ganzen Tag daran und bekomms nicht richtig hin...
Das hat keinen tieferen sinn das ist einfach nur eine Aufgabe =)
Wenn ich die im Client so ändere dann passiert das (ist trotzdem ein glücksgefühl denn wenigstens hab ich jetzt ne fehlermeldung xD) :
Tue Aug 28 15:10:04 2012 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Tue Aug 28 15:10:04 2012 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Aug 28 15:10:04 2012 LZO compression initialized
Tue Aug 28 15:10:04 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug 28 15:10:04 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug 28 15:10:04 2012 Local Options hash (VER=V4): '41690919'
Tue Aug 28 15:10:04 2012 Expected Remote Options hash (VER=V4): '530fdded'
Tue Aug 28 15:10:04 2012 UDPv4 link local: [undef]
Tue Aug 28 15:10:04 2012 UDPv4 link remote: 192.168.115.250:1194
Tue Aug 28 15:10:04 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:06 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:09 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:11 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:13 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:15 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:18 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:20 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:22 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:24 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:26 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:28 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:30 2012 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 28 15:10:31 2012 TCP/UDP: Closing socket
Tue Aug 28 15:10:31 2012 SIGTERM[hard,] received, process exiting
Weiteres problem erkannt und zwar wird das ca.cert nicht mit übernommen und abgespeichert weis aber nicht warum das so ist ...
Hallo,
ich bin der Praktikumsleiter von chaotize. Um seiner Fragestellung etwas mehr Klarheit zu verschaffen, werde ich erst mal grob das Projekt definieren und sein Problem darstellen. Unser Praktikant hat von uns die Aufgabe bekommen die Durchführbarkeit eines OpenVPN Servers auf Basis eines Routers mit DD-WRT Firmware zu prüfen. Wir selbst haben für diese Aufgabe wenig Zeit und daher lag es nahe ihn damit zu beauftragen. Jetzt die Eckdaten der Umgebung. Der DD-WRT Router hängt wie bereits vermutet hinter einem anderen Router und diente bisher als bloßer W-Lan Access Point für Gäste unseres Unternehmens. Er hat an der WAN-Schnittstelle eine feste IP aus dem Netz des Produktiv-Routers. Diese lautet: 192.168.115.250/24...Der DD-WRT Router hat ein eigenes internes Netz, mit dem Adressraum 192.168.200.0 /24. Ziel war es, dass aus dem Netz 192.168.115.0/24 ein Server hinter dem DD-WRT Router im Netz 192.168.200.0/24 ereichbar ist. Sinn des ganzen ist die Realisierbarkeit zu prüfen und etwaig den Produktivrouter ersetzen damit zukünftig Mitarbeiter über OpenVPN aus der Ferne am System arbeiten können. Es gab bei unserem Praktikanten kleine Verständnisschwierigkeiten bezüglich der Funktionsweise eines VPNs. Die Verantwortung dafür übernehme ich, da ich ihm nicht genügend zur Seite gestanden habe. Er hatte wohl nicht Hinterkopf das Quell und Zielnetz natürlich nicht, ohne weiteres, ein und dasselbe Subnetz bilden dürfen. Außerdem wird zwischen dem VPN Client und dem VPN Router normalerweise durch ein öffentliches Netz ein "virtuelles Netz" aufgebaut. Diese Erkenntnis fehlte ihm, daher anfangs die Konfigurationsschwierigkeiten. Was nun aber für Probleme sorgt ist, dass das ca.cert nicht vom DD-WRT Router übernommen wird. Ich werde unseren Praktikanten morgen darum bitten, einen eigenen Thread zu diesem Thema aufzumachen, das ganze Projekt ordentlich zu schildern, die Zertifikate und Konfigurationen bereitzustellen, damit eine zielgerichtete Fehlersuche möglich ist. Danke.
ich bin der Praktikumsleiter von chaotize. Um seiner Fragestellung etwas mehr Klarheit zu verschaffen, werde ich erst mal grob das Projekt definieren und sein Problem darstellen. Unser Praktikant hat von uns die Aufgabe bekommen die Durchführbarkeit eines OpenVPN Servers auf Basis eines Routers mit DD-WRT Firmware zu prüfen. Wir selbst haben für diese Aufgabe wenig Zeit und daher lag es nahe ihn damit zu beauftragen. Jetzt die Eckdaten der Umgebung. Der DD-WRT Router hängt wie bereits vermutet hinter einem anderen Router und diente bisher als bloßer W-Lan Access Point für Gäste unseres Unternehmens. Er hat an der WAN-Schnittstelle eine feste IP aus dem Netz des Produktiv-Routers. Diese lautet: 192.168.115.250/24...Der DD-WRT Router hat ein eigenes internes Netz, mit dem Adressraum 192.168.200.0 /24. Ziel war es, dass aus dem Netz 192.168.115.0/24 ein Server hinter dem DD-WRT Router im Netz 192.168.200.0/24 ereichbar ist. Sinn des ganzen ist die Realisierbarkeit zu prüfen und etwaig den Produktivrouter ersetzen damit zukünftig Mitarbeiter über OpenVPN aus der Ferne am System arbeiten können. Es gab bei unserem Praktikanten kleine Verständnisschwierigkeiten bezüglich der Funktionsweise eines VPNs. Die Verantwortung dafür übernehme ich, da ich ihm nicht genügend zur Seite gestanden habe. Er hatte wohl nicht Hinterkopf das Quell und Zielnetz natürlich nicht, ohne weiteres, ein und dasselbe Subnetz bilden dürfen. Außerdem wird zwischen dem VPN Client und dem VPN Router normalerweise durch ein öffentliches Netz ein "virtuelles Netz" aufgebaut. Diese Erkenntnis fehlte ihm, daher anfangs die Konfigurationsschwierigkeiten. Was nun aber für Probleme sorgt ist, dass das ca.cert nicht vom DD-WRT Router übernommen wird. Ich werde unseren Praktikanten morgen darum bitten, einen eigenen Thread zu diesem Thema aufzumachen, das ganze Projekt ordentlich zu schildern, die Zertifikate und Konfigurationen bereitzustellen, damit eine zielgerichtete Fehlersuche möglich ist. Danke.
Hallo aqui,
danke nochmals für deine Unterstützung =). Bevor ich mir den Kommentar von dir durchgelesen habe, habe ich nochmal neue Zertifikate generiert habe alles noch mal durch gecheckt und hatte ein bisschen Hilfe von meinem Praktikums leiter. Hab verbunden und es funktioniert =). Das ist halt nich unbedingt mein Spezialgebiet also entschuldige ich mich nochmals für meine unwissenheit ;).
Liebe grüße Chaotize
danke nochmals für deine Unterstützung =). Bevor ich mir den Kommentar von dir durchgelesen habe, habe ich nochmal neue Zertifikate generiert habe alles noch mal durch gecheckt und hatte ein bisschen Hilfe von meinem Praktikums leiter. Hab verbunden und es funktioniert =). Das ist halt nich unbedingt mein Spezialgebiet also entschuldige ich mich nochmals für meine unwissenheit ;).
Liebe grüße Chaotize
Hallo aqui
Super Anleitung. Danke dafür.
Aber eine Frage habe ich. Bei dem Bild, wo das mit der "Client-to-Client" Einstellung gezeigt wird, frage ich mich in welchem Menü (PfSense) du dich dafür befindest. Ich finde diese Option auf der Serverseite nirgends. Und wird das nicht eigentlich vorher ganz am Anfang angegeben (Remote Access, Peer-to-Peer)? Im selben bild ist zu sehen dass du die "Custom options" einträgst. Aber auch das kann ja am Anfang gemacht werden. Wo ist da der Unterscheid, bzw. wo ist überhaupt dieses "zweite" Menü?
Danke nochmals für die Anleitung.
Gruss
Super Anleitung. Danke dafür.
Aber eine Frage habe ich. Bei dem Bild, wo das mit der "Client-to-Client" Einstellung gezeigt wird, frage ich mich in welchem Menü (PfSense) du dich dafür befindest. Ich finde diese Option auf der Serverseite nirgends. Und wird das nicht eigentlich vorher ganz am Anfang angegeben (Remote Access, Peer-to-Peer)? Im selben bild ist zu sehen dass du die "Custom options" einträgst. Aber auch das kann ja am Anfang gemacht werden. Wo ist da der Unterscheid, bzw. wo ist überhaupt dieses "zweite" Menü?
Danke nochmals für die Anleitung.
Gruss
Hallo aqui
Ich meinte dieses Bild hier:
Wobei ich das nun gefunden habe (meine ich zumindest):
Scheint sich mit der Version geändert zu haben. Weil das Menü aus deinem Screenshot (bzw. das erste Bild in diesem Post), findet sich nicht in der pfSense Version 2.0.1.
Ich habe das Ganze eingerichtet, aber habe ein seltsames Problem mit den Routen. Wenn ich mir danach per ifconfig die Adressen auf dem Server anschaue, sehe ich beim OpenVPN Adapter "inet 10.254.1.1 --> 10.254.1.2 netmask 0xffffffff". Und beim Client, "inet 10.254.1.6 --> 10.254.1.5 netmask 0xffffffff". Irgendwie erhalte ich zwei Adressen?!? In den Logs heisst es "openvpn[17031]: /sbin/ifconfig ovpnc1 10.254.1.6 10.254.1.5 mtu 1500 netmask 255.255.255.255 up". Wobei ich hierfür einen eigenen Thread (Frage) starte, da es hier den Rahmen sprengt und nicht hinein passt.
Danke.
Ich meinte dieses Bild hier:
Wobei ich das nun gefunden habe (meine ich zumindest):
Scheint sich mit der Version geändert zu haben. Weil das Menü aus deinem Screenshot (bzw. das erste Bild in diesem Post), findet sich nicht in der pfSense Version 2.0.1.
Ich habe das Ganze eingerichtet, aber habe ein seltsames Problem mit den Routen. Wenn ich mir danach per ifconfig die Adressen auf dem Server anschaue, sehe ich beim OpenVPN Adapter "inet 10.254.1.1 --> 10.254.1.2 netmask 0xffffffff". Und beim Client, "inet 10.254.1.6 --> 10.254.1.5 netmask 0xffffffff". Irgendwie erhalte ich zwei Adressen?!? In den Logs heisst es "openvpn[17031]: /sbin/ifconfig ovpnc1 10.254.1.6 10.254.1.5 mtu 1500 netmask 255.255.255.255 up". Wobei ich hierfür einen eigenen Thread (Frage) starte, da es hier den Rahmen sprengt und nicht hinein passt.
Danke.
Hallo,
hab soeben nach dieser Konfigurationsmethode OpenVPN am DD-WRT konfiguriert und konnte eine Verbindung aufbauen.
Verbindung steht und ich kann auch mit der Lokalen IP des Remotenetzwerkes auf einen Remotedesktop zugreifen, auch kann ich Geräte anpingen.
Was aber nicht funktioniert: Ich kann auf keine Dateifreigaben zugreifen...
Beispiel:
Lokales Netz: 172.16.5.0
VPN Netz: 172.16.40.0
Remote Netz: 172.16.10.0
Wenn ich nun aber \\172.16.10.10 eingebe, dann tut sich einfach nichts, und nach paar Minuten kommt eine Fehlermeldung. Wenn ich das aber im Remotenetzwerk lokal mache, funktioniert dass ohne Probleme... Sprich über den VPN Tunnel kann er auf keine Dateifreigaben zugreifen... Wie löse ich das..?
Frage2: Gibt es eine Möglichkeit, Clientseitig zu entscheiden, ob man den gesamten Traffic über VPN schicken möchte oder eben nicht..? Szenario wäre zum Beispiel: Ich habe einen VPN Server in der Firma. Wenn ich nun von zuhause aus Arbeite, möchte ich nur meine benötigten Firmendaten über VPN tunneln, aber mein Surfinternet nicht. Anders wiederrum mit dem Mobiltelefon, bei dem ich den FirmenVPN Server für unterwegs als Secure Surf Internet missbrauchen möchte. Dafür müsste ich aber nun die möglichkeit haben, die Routen je nach User zu differenzieren. gibt es da eine möglichkeit..?
Vielen DANK bereits im voraus.
BTW: http://wiki.openvpn.eu/index.php/Schlüsselverwaltung_mit_XCA In dieser Anleitung ist die Erstellung der Zertifikate mit XCA ein wenig einfacher erklärt als bei der oben angegebenen Anleitung. Besonders gut finde ich den Hinweis auf den "Exportieren als PKCS#12-Dateien". Dies ist für Clientzertifikate doch um einiges angenehmer.
hab soeben nach dieser Konfigurationsmethode OpenVPN am DD-WRT konfiguriert und konnte eine Verbindung aufbauen.
Verbindung steht und ich kann auch mit der Lokalen IP des Remotenetzwerkes auf einen Remotedesktop zugreifen, auch kann ich Geräte anpingen.
Was aber nicht funktioniert: Ich kann auf keine Dateifreigaben zugreifen...
Beispiel:
Lokales Netz: 172.16.5.0
VPN Netz: 172.16.40.0
Remote Netz: 172.16.10.0
Wenn ich nun aber \\172.16.10.10 eingebe, dann tut sich einfach nichts, und nach paar Minuten kommt eine Fehlermeldung. Wenn ich das aber im Remotenetzwerk lokal mache, funktioniert dass ohne Probleme... Sprich über den VPN Tunnel kann er auf keine Dateifreigaben zugreifen... Wie löse ich das..?
Frage2: Gibt es eine Möglichkeit, Clientseitig zu entscheiden, ob man den gesamten Traffic über VPN schicken möchte oder eben nicht..? Szenario wäre zum Beispiel: Ich habe einen VPN Server in der Firma. Wenn ich nun von zuhause aus Arbeite, möchte ich nur meine benötigten Firmendaten über VPN tunneln, aber mein Surfinternet nicht. Anders wiederrum mit dem Mobiltelefon, bei dem ich den FirmenVPN Server für unterwegs als Secure Surf Internet missbrauchen möchte. Dafür müsste ich aber nun die möglichkeit haben, die Routen je nach User zu differenzieren. gibt es da eine möglichkeit..?
Vielen DANK bereits im voraus.
BTW: http://wiki.openvpn.eu/index.php/Schlüsselverwaltung_mit_XCA In dieser Anleitung ist die Erstellung der Zertifikate mit XCA ein wenig einfacher erklärt als bei der oben angegebenen Anleitung. Besonders gut finde ich den Hinweis auf den "Exportieren als PKCS#12-Dateien". Dies ist für Clientzertifikate doch um einiges angenehmer.
Hallo,
hmm zur Frage 2: "push redirect-gateway" ist aber eine Serverseitige einstellung und somit dann global für ALLE Verbindungen, die zum VPN Server aufgebaut werden. und eben genau das möchte ich nicht.
ich möchte als Client entscheiden können, ob ich alles tunnle (Surfinternet etc) oder nur lokale Anfragen in dieses Netz.
Eventuell auf verschiedene User, unterschiedliches Verhalten zuweisen. Sprich Client1 = nur lokales tunneln... client2 = alles tunneln... so auf diese art und weise.
hmm zur Frage 2: "push redirect-gateway" ist aber eine Serverseitige einstellung und somit dann global für ALLE Verbindungen, die zum VPN Server aufgebaut werden. und eben genau das möchte ich nicht.
ich möchte als Client entscheiden können, ob ich alles tunnle (Surfinternet etc) oder nur lokale Anfragen in dieses Netz.
Eventuell auf verschiedene User, unterschiedliches Verhalten zuweisen. Sprich Client1 = nur lokales tunneln... client2 = alles tunneln... so auf diese art und weise.
Zitat von @aqui:
Dein Problem bei der Freigabe ist die lokale Firewall auf dem Rechner der das Share freigibt. Der lässt nur lokale IPs zu !
Du aber kommst via VPN ja mit einer fremden IP dort an und wirst folglich geblockt !
Änder also die FW Einstellungen für die Datei- und Druckerfreigabe, dann klappt das auch sofort !
Dein Problem bei der Freigabe ist die lokale Firewall auf dem Rechner der das Share freigibt. Der lässt nur lokale IPs zu !
Du aber kommst via VPN ja mit einer fremden IP dort an und wirst folglich geblockt !
Änder also die FW Einstellungen für die Datei- und Druckerfreigabe, dann klappt das auch sofort !
so habe soeben die komplette Windows Firewall zum Test auf dem Rechner, auf dem die Dateifreigabe liegt, deaktiviert und es funktioniert trotzdem nicht :/
hast du eventuell noch einen anderen Ratschlag was da sein könnte..?
Was mir noch aufgefallen ist:
ich kann den Computer über VPN auch nicht pingen.. im lokalen Netz geht es ohne Probleme.
außer dem Router und meinem "HyperV Server" kann ich sonst kein einzig anderes Gerät pingen :/
lg
Meine OpenVPN Serverconfig:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 172.16.40.0 255.255.255.0
push "route 172.16.10.0 255.255.255.0" *Mein VLAN10
push "route 172.16.20.0 255.255.255.0" *Mein VLAN20
push "route 172.16.30.0 255.255.255.0" *Mein VLAN30
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
DD-WRT: Advanced Routing
Operating Mode: Gateway Modus
Routing Table Entry ListDestination LAN NET Subnet Mask Gateway Interface
79.170.212.56 255.255.255.255 0.0.0.0 ppp0
172.16.40.2 255.255.255.255 0.0.0.0 tun0
172.16.20.0 255.255.255.0 172.16.10.250 LAN & WLAN
172.16.30.0 255.255.255.0 172.16.10.250 LAN & WLAN
172.16.10.0 255.255.255.0 0.0.0.0 LAN & WLAN
172.16.40.0 255.255.255.0 172.16.40.2 tun0
169.254.0.0 255.255.0.0 0.0.0.0 LAN & WLAN
0.0.0.0 0.0.0.0 79.170.212.56 ppp0
Hallo,
so hab mich heute mal wieder mit OpenVPN am DD-WRT beschäftigt.
In der Anleitung steht, dass die SPI Firewall deaktiviert sein muss, da es ansonsten nicht funktioniert.
Da ich dass so einfach nicht hinnehmen wollte, habe ich die SPI Firewall aktiviert und mein Glück mit Firewallregeln herausgefordert...
BTW: Ich nutze OpenVPN im TUN Modus sprich Layer 3 (Routing).
Fazit der Geschichte:
Wie richtet man diese Regeln ein:
auf der Weboberfläche von DD-WRT auf "Administration > Commands" gehen und bei Commands die Zeilen einfügen und dann "Save Firewall" drücken. FERTIG.
so hab mich heute mal wieder mit OpenVPN am DD-WRT beschäftigt.
In der Anleitung steht, dass die SPI Firewall deaktiviert sein muss, da es ansonsten nicht funktioniert.
Da ich dass so einfach nicht hinnehmen wollte, habe ich die SPI Firewall aktiviert und mein Glück mit Firewallregeln herausgefordert...
BTW: Ich nutze OpenVPN im TUN Modus sprich Layer 3 (Routing).
Fazit der Geschichte:
# Akzeptiert eingehende Anfragen am Port 1194.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc)
iptables -I INPUT 3 -i tun0 -j ACCEPT
# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist.
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN).
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
Wie richtet man diese Regeln ein:
auf der Weboberfläche von DD-WRT auf "Administration > Commands" gehen und bei Commands die Zeilen einfügen und dann "Save Firewall" drücken. FERTIG.
Was mir jedoch noch nicht gelungen ist:
Ich möchte gerne den Status der OpenVPN Verbindungen unter "Status > OpenVPN" ausgeben, jedoch zeigt er mir hier nichts an...
Habe aber schon die Zeile "management localhost 5001" in den OpenVPN Serverconfigs hinzugefügt. geht aber nicht.
hat jemand eine idee?
Übrigends meine vollständige Serverconfig:
Ich möchte gerne den Status der OpenVPN Verbindungen unter "Status > OpenVPN" ausgeben, jedoch zeigt er mir hier nichts an...
Habe aber schon die Zeile "management localhost 5001" in den OpenVPN Serverconfigs hinzugefügt. geht aber nicht.
hat jemand eine idee?
Übrigends meine vollständige Serverconfig:
dev tun0
proto udp
port 1194
server 172.16.40.0 255.255.255.0
push "route 172.16.10.0 255.255.255.0"
push "route 172.16.20.0 255.255.255.0"
push "route 172.16.30.0 255.255.255.0"
keepalive 10 120
tun-mtu 1500
tun-mtu-extra 32
management localhost 5001
verb 3
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
Hallo,
ja dass mit MTU hab ich mir eh schon gedacht, hab es wieder auf tun-mtu 1492 und tun-mtu-extra 32 gesetzt.
ja klar, füg die iptables hinzu ;)
übrigends
dieser Teil in deiner Beschreibung ist nicht mehr Zeitgemäß, da der Aufbau bei den neueren DD-WRT Versionen anders betitelt ist.
Des weiteren wurde ein neuer Punkt eingeführt... Man kann nun OpenVPN als Server oder als Daemon starten. Unterschied ist der, dass bei "Config as Server" Felder für die "additional config" vorgibt und man auch direkt einen PKCS12 Key hinzufügen kann. Sprich man braucht außer den push routen in der "additional config" nichts mehr hinzufügen.
ja dass mit MTU hab ich mir eh schon gedacht, hab es wieder auf tun-mtu 1492 und tun-mtu-extra 32 gesetzt.
ja klar, füg die iptables hinzu ;)
übrigends
Public Server Cert ==>> Master Zertifikat, ca.crt Datei
Certificate revoke list ==>> bleibt leer !!
Public Client cert ==>> Server Zertifikat, server.crt Datei
Private Client key ==>> Server Key, server.key
DH pem ==>> DH Parameter, dh1024.pem Datei
OpenVPN config OpenVPN Konfig Datei, z.B. Beispiel unten
OpenVPN TLS Auth ==>> bleibt leer !!
dieser Teil in deiner Beschreibung ist nicht mehr Zeitgemäß, da der Aufbau bei den neueren DD-WRT Versionen anders betitelt ist.
CA CERT => CA.crt (Master Zertifikat)
Public Server CERT => Server.crt (Server Zertifikat)
Private Server Key => Server.pem (Server Key)
DH PEM => dhxxxx.pem (DH Parameter)
Additional Config => Server Konfig
TLS Auth Key => bleibt leer
Certificate Revoke List => bleibt leer
Des weiteren wurde ein neuer Punkt eingeführt... Man kann nun OpenVPN als Server oder als Daemon starten. Unterschied ist der, dass bei "Config as Server" Felder für die "additional config" vorgibt und man auch direkt einen PKCS12 Key hinzufügen kann. Sprich man braucht außer den push routen in der "additional config" nichts mehr hinzufügen.
OpenVPN Statusanzeigeproblem ist gelöst!!!!
Durch das Durchspielen der "Config as Server" Konfiguration ist mir aufgefallen, dass DD-WRT in der "openvpn.conf" Datei selbstständig folgende Zeile hinzufügt:
Somit funktioniert die OpenVPN Statusanzeige in der "Config as Server" Variante.
Wenn man sie auch in der "Config as Daemon" Variante laufen haben möchte, muss man einfach die Zeile in der additional Config hinzufügen.
High Five for me :P haha
Durch das Durchspielen der "Config as Server" Konfiguration ist mir aufgefallen, dass DD-WRT in der "openvpn.conf" Datei selbstständig folgende Zeile hinzufügt:
management localhost 14
Somit funktioniert die OpenVPN Statusanzeige in der "Config as Server" Variante.
Wenn man sie auch in der "Config as Daemon" Variante laufen haben möchte, muss man einfach die Zeile in der additional Config hinzufügen.
High Five for me :P haha
Hallo,
hab ne kleine Frage:
wie kann ich einen einzelnen DNS Eintrag pushen..?
Szenario: Ich bin per VPN mit dem Firmennetzwerk verbunden. DNS und GATEWAY werden nicht gepusht, sprich mein gesamter Internettraffic, sofern es nicht das Firmennetzwerk betrifft, gehen über mein normalen Gateway.
So nun möchte ich aber, dass die Adresse "xy.test.com" nicht über das Internet aufgelöst wird, sondern dass diese Anfrage in das VPN Netzwerk geht, bzw. vom dortigen DNS Server aufgelöst wird, da es sich hierbei um die lokale Webserveradresse handelt.
wie füge ich so eine Route dem OpenVPN Server hinzu, damit alle Clients automatisch diese Route drinnen haben und ich nicht bei jedem Client das Hostfile manuell bearbeiten muss..???
hab ne kleine Frage:
wie kann ich einen einzelnen DNS Eintrag pushen..?
Szenario: Ich bin per VPN mit dem Firmennetzwerk verbunden. DNS und GATEWAY werden nicht gepusht, sprich mein gesamter Internettraffic, sofern es nicht das Firmennetzwerk betrifft, gehen über mein normalen Gateway.
So nun möchte ich aber, dass die Adresse "xy.test.com" nicht über das Internet aufgelöst wird, sondern dass diese Anfrage in das VPN Netzwerk geht, bzw. vom dortigen DNS Server aufgelöst wird, da es sich hierbei um die lokale Webserveradresse handelt.
wie füge ich so eine Route dem OpenVPN Server hinzu, damit alle Clients automatisch diese Route drinnen haben und ich nicht bei jedem Client das Hostfile manuell bearbeiten muss..???
Hallo,
ja DNS meinte ich...
habe genau das schon glesen und dabei ist mir dann aufgestoßen, dass alle meine lokalen DNS Anfragen dann über den VPN Server laufen und dabei dachte ich mir, ob dass nicht performance einbusen mit sich bringt, da ja jedesmal eine Anfrage an den VPN Server gesendet wird und der dann wieder zurück senden muss woher er auflösen muss. Da der VPN Server nur an einer 30/4er Leitung hängt, weiß ich nicht ob das so ratsam ist. Habe ich dadurch nicht Bandbreiteneinbusen bzw. höhere Latenzzeiten..?
Gibt es außer dieser Möglichkeit keine weitere um einfach beim Verbinden mit dem OpenVPN Server diesen DNS Eintrag zu setzen, dass "xy.test.com" ins VPN Netz geroutet wird und vom dortigen DNS Server aufgelöst wird..?
lg
ja DNS meinte ich...
habe genau das schon glesen und dabei ist mir dann aufgestoßen, dass alle meine lokalen DNS Anfragen dann über den VPN Server laufen und dabei dachte ich mir, ob dass nicht performance einbusen mit sich bringt, da ja jedesmal eine Anfrage an den VPN Server gesendet wird und der dann wieder zurück senden muss woher er auflösen muss. Da der VPN Server nur an einer 30/4er Leitung hängt, weiß ich nicht ob das so ratsam ist. Habe ich dadurch nicht Bandbreiteneinbusen bzw. höhere Latenzzeiten..?
Gibt es außer dieser Möglichkeit keine weitere um einfach beim Verbinden mit dem OpenVPN Server diesen DNS Eintrag zu setzen, dass "xy.test.com" ins VPN Netz geroutet wird und vom dortigen DNS Server aufgelöst wird..?
lg
So habe es nun über diesen Weg gemacht:
Ich habe folgende Zeile in der OpenVPN Konfig eingefügt:
Die IP Adresse ist der DNS Server.
Für alle deren DNS Server (dnsmasq) auch der DD-WRT Router ist, so wie bei mir, wird aber feststellen, dass die DNS Anfragen vom VPN Client nicht verarbeitet werden und mit einem "DNS Request timed out." quitiert werden.
Um das zu lösen, fügt man folgende Zeilen unter "Additional DNSMasq Options" hinzu:
Somit werden DNS Anfragen vom Interface "tun0" also dem OpenVPN Interface angenommen und bearbeitet.
no-dhcp-interface könnte man auch weglassen.
Ich habe folgende Zeile in der OpenVPN Konfig eingefügt:
push "dhcp-option DNS 10.0.0.1"
Die IP Adresse ist der DNS Server.
Für alle deren DNS Server (dnsmasq) auch der DD-WRT Router ist, so wie bei mir, wird aber feststellen, dass die DNS Anfragen vom VPN Client nicht verarbeitet werden und mit einem "DNS Request timed out." quitiert werden.
Um das zu lösen, fügt man folgende Zeilen unter "Additional DNSMasq Options" hinzu:
interface=tun0
no-dhcp-interface=tun0
Somit werden DNS Anfragen vom Interface "tun0" also dem OpenVPN Interface angenommen und bearbeitet.
no-dhcp-interface könnte man auch weglassen.
moinmoin ...
... so ganz bin ich noch nicht durch mit meinem Verständnis für DNS, fürchte ich ...
Die VPN-Verbindung zwischen der pfSense am Server-Standort und meinem Win8-Client in der Aussenstelle steht und der Traffic zu meinem Windows DC (2K8R2) wird lt. tracert auch durch den Tunnel geleitet.
Die Routen scheinen zu stimmen.
Aber mit der Namensauflösung stehe ich noch auf Kriegsfuss!
push "dhcp-option DNS <IP-des-DC>"; ist gesetzt und wird auch angewandt.
Eigentlich dachte ich, nun sollte es klappen ...
Aber ipconfig /all zeigt mir zwei DNS am TAP-Adapter an! 8.8.8.8 und die IP-des-DC ...
nslookup läuft somit immer mit dem google-DNS ...
ändere ich am TAP-Win32 Adapter nun die default-settings des DNS und trage dort nur die IP-des-DC ein, klappt es auch mit nslookup, allerdings bislang nur mit dem FQDN.
Ich finde einfach nicht heraus, wo das TAP-Adapter die 8.8.8.8 her hat ...
Ich will ja nicht den gesamten Traffic über das VPN routen, nur die dierekten Anfragen an den DC und den TerminalServer.
Das ganze ist eine Testumgebung, da ich im Endeffekt alle Außenstellen via pfSense site-to-site koppeln möchte.
Die DCs der einzelnen Standorte sollen dann als Standorte im ADS registriert werden.
Hauptgrund hierfür ist die zentrale Verwaltung der User, die derzeit noch pro Standort durchgeführt wird.
... so ganz bin ich noch nicht durch mit meinem Verständnis für DNS, fürchte ich ...
Die VPN-Verbindung zwischen der pfSense am Server-Standort und meinem Win8-Client in der Aussenstelle steht und der Traffic zu meinem Windows DC (2K8R2) wird lt. tracert auch durch den Tunnel geleitet.
Die Routen scheinen zu stimmen.
Aber mit der Namensauflösung stehe ich noch auf Kriegsfuss!
push "dhcp-option DNS <IP-des-DC>"; ist gesetzt und wird auch angewandt.
Eigentlich dachte ich, nun sollte es klappen ...
Aber ipconfig /all zeigt mir zwei DNS am TAP-Adapter an! 8.8.8.8 und die IP-des-DC ...
nslookup läuft somit immer mit dem google-DNS ...
ändere ich am TAP-Win32 Adapter nun die default-settings des DNS und trage dort nur die IP-des-DC ein, klappt es auch mit nslookup, allerdings bislang nur mit dem FQDN.
Ich finde einfach nicht heraus, wo das TAP-Adapter die 8.8.8.8 her hat ...
Ich will ja nicht den gesamten Traffic über das VPN routen, nur die dierekten Anfragen an den DC und den TerminalServer.
Das ganze ist eine Testumgebung, da ich im Endeffekt alle Außenstellen via pfSense site-to-site koppeln möchte.
Die DCs der einzelnen Standorte sollen dann als Standorte im ADS registriert werden.
Hauptgrund hierfür ist die zentrale Verwaltung der User, die derzeit noch pro Standort durchgeführt wird.
Händisch eingetragen ist er bei mir auf dem Client.
Meine NIC hat als DNS unseren StandortDC und den google-DNS eingetragen.
Die pfSense läuft auf einem Root-Server bei Hetzner (ESXi) und hat die DNS von Hetzner eingetragen.
Da die IP des Tunnels ja von der pFsense kommt müsste doch dort irgendwo die 8.8.8.8 herkommen ... da habe ich aber nie etwas in der Richtung konfiguriert.
Meine NIC hat als DNS unseren StandortDC und den google-DNS eingetragen.
Die pfSense läuft auf einem Root-Server bei Hetzner (ESXi) und hat die DNS von Hetzner eingetragen.
Da die IP des Tunnels ja von der pFsense kommt müsste doch dort irgendwo die 8.8.8.8 herkommen ... da habe ich aber nie etwas in der Richtung konfiguriert.
Jetzt habe ich die Config der pfSense (OVPN-Server) komplett gecheckt ...
Da finde ich nirgends einen Hinweis drauf, die 8.8.8.8 an die clients zu pushen.
Also muss es doch irgendwo an meinem Windows Client hängen, dass der primary DNS immer 8.8.8.8 ist.
Der DNS, der gepushed wird kommt korrekt an, ebenso das DNS-Suffix.
Stelle ich bei bestehender Verbindung den DNS des TAP-Adapters manuell auf den der VPN-LAN-Site um, läuft alles wie geschmiert.
Änderungen des DNS an der NIC des Clients ändern nix daran, dass ich am TAP-Interface die 8.8.8.8 und den DNS des VPN-LAN erhalte.
Da finde ich nirgends einen Hinweis drauf, die 8.8.8.8 an die clients zu pushen.
Also muss es doch irgendwo an meinem Windows Client hängen, dass der primary DNS immer 8.8.8.8 ist.
Der DNS, der gepushed wird kommt korrekt an, ebenso das DNS-Suffix.
Stelle ich bei bestehender Verbindung den DNS des TAP-Adapters manuell auf den der VPN-LAN-Site um, läuft alles wie geschmiert.
Änderungen des DNS an der NIC des Clients ändern nix daran, dass ich am TAP-Interface die 8.8.8.8 und den DNS des VPN-LAN erhalte.
Hi
Ich muss diesen Thread nochmal ausgraben mein Problem ist das Openvpn (Alles PFsense) funktioniert Standort A is der Server Standort B und C greifen auf A zu das funktioniert nur habe ich das Problem das B und C sich nicht sehen leider habe ich die funktion client to client vpn nicht in meiner konfiguration das gibts nur bei remote access aber nicht unter peer to peer Standort A hat version 2.01 Standort B und C haben beide version 2.0.3 irgendeine Idee dazu ? sry schon mal für schreibfehler und satzzeichen die fehlen
Ich muss diesen Thread nochmal ausgraben mein Problem ist das Openvpn (Alles PFsense) funktioniert Standort A is der Server Standort B und C greifen auf A zu das funktioniert nur habe ich das Problem das B und C sich nicht sehen leider habe ich die funktion client to client vpn nicht in meiner konfiguration das gibts nur bei remote access aber nicht unter peer to peer Standort A hat version 2.01 Standort B und C haben beide version 2.0.3 irgendeine Idee dazu ? sry schon mal für schreibfehler und satzzeichen die fehlen
Mein Flash hatte scheinbar einen Defekt und ich musste neu Flashen und die gespeicherte Config habe ich nicht mehr gefunden Kurz ich stehe wieder (fast) am Anfang.
Der dd-WRT -Router soll nur als VPN-Server betrieben werden. SPI-Firewall ist aus.
Ich habe die VPN-Config:
port 1195
proto udp
dev tun0
server 172.16.2.0 255.255.255.0 // Muss diese mit Zielnetz übereinstimmen oder ist dies nur ein Logisches Netz? (WAN: 192.168.179.0 ?)
push "route 192.168.178.0 255.255.255.0"
push "route 192.168.179.0 255.255.255.0"
push "dhcp-options DNS 192.168.178.1"
Ich habe bereits mehrere Varianten Durchprobiert, wenn ich nun den den dd-WRT-Router (DHCP off) per Switch mit dem Internet-Router verbinde, kann ich eine VPN-Verbindung aufbauen und auf den Router zugreifen. Allerdings ist das 192.168.178.0 Netz trotz Push nicht erreichbar
dd-WRT-Router Config:
IP: 192.168.178.2/24
DNS & Gateway 192.168.178.1
Alternativ hatte ich auch schon den Router per WAN-Port verbunden, dann kam aber keine VPN Verbindung zustande. Port-FW war eingerichtet
dd-WRT-Router Config:
IP: 192.168.179.2/24
DNS & Gateway 192.168.178.1
Wo liegt mein Denk- bzw. Konfigurationsfehler?
Der dd-WRT -Router soll nur als VPN-Server betrieben werden. SPI-Firewall ist aus.
Ich habe die VPN-Config:
port 1195
proto udp
dev tun0
server 172.16.2.0 255.255.255.0 // Muss diese mit Zielnetz übereinstimmen oder ist dies nur ein Logisches Netz? (WAN: 192.168.179.0 ?)
push "route 192.168.178.0 255.255.255.0"
push "route 192.168.179.0 255.255.255.0"
push "dhcp-options DNS 192.168.178.1"
Ich habe bereits mehrere Varianten Durchprobiert, wenn ich nun den den dd-WRT-Router (DHCP off) per Switch mit dem Internet-Router verbinde, kann ich eine VPN-Verbindung aufbauen und auf den Router zugreifen. Allerdings ist das 192.168.178.0 Netz trotz Push nicht erreichbar
dd-WRT-Router Config:
IP: 192.168.178.2/24
DNS & Gateway 192.168.178.1
Alternativ hatte ich auch schon den Router per WAN-Port verbunden, dann kam aber keine VPN Verbindung zustande. Port-FW war eingerichtet
dd-WRT-Router Config:
IP: 192.168.179.2/24
DNS & Gateway 192.168.178.1
Wo liegt mein Denk- bzw. Konfigurationsfehler?
So ich habe nun herausgefunden das die Config richtig ist bzw. war Ich bekommen eine Verbindung und kann auf die Netzwerke zugreifen.
Aber leider startet OpenVPN nicht automatisch nach jedem Booten/Reboot des Routers, sondern ich muss erst unter "VPN" Apply Setting den OpenVPN Server starten.
Der Befehl "openvpn --daemon --config /tmp/openvpn/openvpn.conf" hat leider das Problem nicht gelöst.
Aber leider startet OpenVPN nicht automatisch nach jedem Booten/Reboot des Routers, sondern ich muss erst unter "VPN" Apply Setting den OpenVPN Server starten.
Der Befehl "openvpn --daemon --config /tmp/openvpn/openvpn.conf" hat leider das Problem nicht gelöst.
Danke, hätte ich auch selber drauf kommen können, aber vor Freudentaumel das ich die Ursache Gefunden habe und es richtig konfiguriert hatte bin ich nicht auf die Idee gekommen.
Das Verlinkte musste ich so Modifizieren
d. h. --daemon hinzufügen und dann lief es.
Bezüglich Sicherheit verbessern, da die wrt54 FWs sind schon etwas älter sind, wollte ich fragen, ob es Updates außer der aktuelleren Versionen aus der DB gibt? Bzw. welche Version man mindestens nehmen sollte.
Im Log steht das TLS 1.0 verwendet wird ist das korrekt? Inzwischen ist doch 1.2 aktuell?!
Das Verlinkte musste ich so Modifizieren
d. h. --daemon hinzufügen und dann lief es.
Bezüglich Sicherheit verbessern, da die wrt54 FWs sind schon etwas älter sind, wollte ich fragen, ob es Updates außer der aktuelleren Versionen aus der DB gibt? Bzw. welche Version man mindestens nehmen sollte.
Im Log steht das TLS 1.0 verwendet wird ist das korrekt? Inzwischen ist doch 1.2 aktuell?!
In einer Konfiguration wie oben wollte ich einen PC per WOL im Netz vor dem dd-WRT Router aufwecken, da WOL Pakete über OpenVPN nicht ohne weiteres Funktionieren, habe ich dies über die dd-wrt Oberfläche versucht ohne Erfolg.
Wie kann ich am besten die WOL Funktionalität herstellen?
P.S.:
Die WOL Funktion auf dem PC selbst funktioniert (getestet).
Wie kann ich am besten die WOL Funktionalität herstellen?
P.S.:
Die WOL Funktion auf dem PC selbst funktioniert (getestet).
Hallo,
danke habe es gerade gefunden die Zertifikate kann ich unter System > Cert-Manager erstellen/bzw. vorhandene per Drag&Drop einfügen.
Kann ich ohne Schwierigkeiten die bestehende "webConfigurator default " entfernen, oder sollte man das nicht tun ?
Die aktuelle Konfiguration aus dem DDWRT, kann ich allerdings nicht komplett wie sie ist per Drag&Drop übernehmen, oder wäre es möglich alles einfach bei der Serverkonfiguration in das "Advanced configuration"- Feld zu kopieren ?
Gruß
danke habe es gerade gefunden die Zertifikate kann ich unter System > Cert-Manager erstellen/bzw. vorhandene per Drag&Drop einfügen.
Kann ich ohne Schwierigkeiten die bestehende "webConfigurator default " entfernen, oder sollte man das nicht tun ?
Die aktuelle Konfiguration aus dem DDWRT, kann ich allerdings nicht komplett wie sie ist per Drag&Drop übernehmen, oder wäre es möglich alles einfach bei der Serverkonfiguration in das "Advanced configuration"- Feld zu kopieren ?
Gruß
Hallo,
danke ich habe dies schnell per Drag and Drop über die GUI erledigt, die CA und Zertifikate sind somit verfügbar.
Ich habe nun den Server konfiguriert.
Nach ein wenig Testen und schauen im LOG habe ich die Fehler beheben können, die eine Verbindung nicht zu Stande kommen ließen (Authentifizierung).
Verbindung wird nun aufgebaut, allerdings kann ich kein Ping auf den OpenVPN-Server abgeben, geschweige denn auf das interne-Lan.
Was mich ein wenig wundert, ich kann dennoch verbinden, auch wenn beide Firewallregeln deaktiviert sind ?
OpenVPN Server:
Firewall WAN-Interface:
Firewall OpenVPN-Interface:
Clientkonfig, allerding hat sich an dieser zum DDWRT nichts geändert, sollte daher eigentlich alles passen:
dev tun
proto udp
port 1194
remote REMOTEADRESSE
ns-cert-type server
tls-client
pkcs12 "C:\\Program Files\\OpenVPN\\config\\Zertifikat.p12"
auth-nocache
pull
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
verb 3
mute 50
ping-timer-rem
persist-key
persist-tun
PS: Habe noch ein wenig getestet, die Verbindung wie oben beschrieben steht, Ping funktioniert nicht, ich sehe in der FW das die ICMP Pakete ein drop erhalten.
Ich stellte dann fest das ich meine Shares dennoch erreichen kann! Weiterhin hat die FW-Rule am WAN Port keine Auswirkung ? Denn verbinden ohne diese kann ich und die Shares ebenfalls erreichen.
Wo für soll diese sein ? Warum geht kein ICMP Paket durch ?
danke ich habe dies schnell per Drag and Drop über die GUI erledigt, die CA und Zertifikate sind somit verfügbar.
Ich habe nun den Server konfiguriert.
Nach ein wenig Testen und schauen im LOG habe ich die Fehler beheben können, die eine Verbindung nicht zu Stande kommen ließen (Authentifizierung).
Verbindung wird nun aufgebaut, allerdings kann ich kein Ping auf den OpenVPN-Server abgeben, geschweige denn auf das interne-Lan.
Was mich ein wenig wundert, ich kann dennoch verbinden, auch wenn beide Firewallregeln deaktiviert sind ?
OpenVPN Server:
Firewall WAN-Interface:
Firewall OpenVPN-Interface:
Clientkonfig, allerding hat sich an dieser zum DDWRT nichts geändert, sollte daher eigentlich alles passen:
dev tun
proto udp
port 1194
remote REMOTEADRESSE
ns-cert-type server
tls-client
pkcs12 "C:\\Program Files\\OpenVPN\\config\\Zertifikat.p12"
auth-nocache
pull
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
verb 3
mute 50
ping-timer-rem
persist-key
persist-tun
PS: Habe noch ein wenig getestet, die Verbindung wie oben beschrieben steht, Ping funktioniert nicht, ich sehe in der FW das die ICMP Pakete ein drop erhalten.
Ich stellte dann fest das ich meine Shares dennoch erreichen kann! Weiterhin hat die FW-Rule am WAN Port keine Auswirkung ? Denn verbinden ohne diese kann ich und die Shares ebenfalls erreichen.
Wo für soll diese sein ? Warum geht kein ICMP Paket durch ?
Der VPN Tunneladapter ist wie bei einer Firewall üblich im Default für allen Traffic geblockt. Gehe also in das Rules
Setup, wähle den VPN Tunneladapter und erlaube dort den Traffic.
Oh, hatte ich übersehen das ich nicht alle Protokolle freigegeben habe, war wohl etwas zu spätSetup, wähle den VPN Tunneladapter und erlaube dort den Traffic.
Ahem, das ist ja auch klar und logisch !! Hier kommt ja dein im Tunnel verschlüsselter Traffic rein. Es muss also nur eine
Regel eingestellt werden die Eingehenden Traffic auf UDP 1194 erlaubt (OVPN Tunnel).
Etwas logisch nachdenken wie ein VPN funktioniert, dann kommt auch die Erkenntnis
Hier haben wie wohl aneinander vorbei gesprochen, die VPN Topologie ist mir schon bewusst.Regel eingestellt werden die Eingehenden Traffic auf UDP 1194 erlaubt (OVPN Tunnel).
Etwas logisch nachdenken wie ein VPN funktioniert, dann kommt auch die Erkenntnis
Allerdings konnte ich konnektieren obwohl ich die Rule am WAN-Port gänzlich gelöscht habe, ansonsten ist diese schon klar.
Habe das Heute nochmal nachgestellt. Wenn die Regel am WAN-Port angelegt ist, und man diese löscht, geht ein neu-konnektieren, bis
die pfSense neu gestartet wurde. Obwohl das Ruleset ja neu eingelesen wir ohne Neustart !
Vielen Dank an aqui und alle Beteiligten für diese gelungene Anleitung, hat (fast) auf Anhieb funktioniert! Ich hab meinen pfsense Proxy nach der Anleitung eingerichtet und konnte auch sofort eine Verbindung herstellen, nur der Traffic wurde nicht richtig geroutet. Nach ein paar Stunden frustrierender Suche bin ich auf die sehr banale Lösung des Problems gestoßen: man muss den OVPN Client mit Admin-Rechten starten...
Vielleicht hab ich's in der Anleitung überlesen, falls nicht, könnte man es bei Gelegenheit ergänzen. Vielen Dank nochmal, war mir eine große Hilfe!
Vielleicht hab ich's in der Anleitung überlesen, falls nicht, könnte man es bei Gelegenheit ergänzen. Vielen Dank nochmal, war mir eine große Hilfe!
Hallo,
ich habe nun meinen alten dd-wrt Router ersetzt und auf einen neuen dd-wrt Router OpenVPN eingerichtet. Die Verbindung wird erfolgreich aufgebaut und Router sowie Website eines PCs sind aufrufbar. Allerdings sind Samba und ftp-Server des gleichen PCs nicht erreichbar, scheinbar ist nur Port 80 nutzbar. Welcher Konfigurationsfehler führt zu diesem Verhalten?
Grüße,
DoeJoe
ich habe nun meinen alten dd-wrt Router ersetzt und auf einen neuen dd-wrt Router OpenVPN eingerichtet. Die Verbindung wird erfolgreich aufgebaut und Router sowie Website eines PCs sind aufrufbar. Allerdings sind Samba und ftp-Server des gleichen PCs nicht erreichbar, scheinbar ist nur Port 80 nutzbar. Welcher Konfigurationsfehler führt zu diesem Verhalten?
Grüße,
DoeJoe
Zitat von @aqui:
Entweder lokale Firewall die da zuschlägt oder das interne IP Netz des OVPN Servers ist nicht in der Samba Konf aktiviert.
OVPN selber limitiert den Zugriff logischerweise nicht. Kann also nur die iptables FW sein. Ggf. mal deaktivieren und nochmal
testen.
Entweder lokale Firewall die da zuschlägt oder das interne IP Netz des OVPN Servers ist nicht in der Samba Konf aktiviert.
OVPN selber limitiert den Zugriff logischerweise nicht. Kann also nur die iptables FW sein. Ggf. mal deaktivieren und nochmal
testen.
Ich habe IP Adressen mäßig nichts geändert, trotzdem gehen ftp samba nicht im VPN-Server Netz, zudem habe ich keinen Zugriff auf den davor geschalteten Router.
Egal ob ich die Firewall ein oder ausgeschaltet habe.
Hallo zusammen,
ich wollte auf meinem Router auch den OpenVPN Server einrichten. Habe allerdings das Problem, dass wenn ich mich per SSH aufschalte, sehe ich das der Server nicht läuft.
Ich verwende für den Router folgende Firmware: DD-WRT v24-sp2 (06/23/14) std
Die Dateien liegen im Ordner Temp siehe
https://www.dropbox.com/s/kso0trg1072dk7r/router.PNG?dl=0
zusätzlich liegt hier bei mir noch eine ccd Datei. Keine Ahnung was diese bringt.
Was allerdings beim Router etwas komisch finde. Ich habe auch die 7 Textfelder. Bei mir heißen manche aber etwas anders. Sie kommen bei mir in folgender Reihenfolge:
CA-Cert
Public Server Cert
Privat Server Key
DH Pem
Additional Config
TLS Auth Key
Certificate Revoke List
Versuche ich den Server nun über die SSH Konsole zu starten, dann erhalte ich folgende Fehlermeldung:
Options error: --dh fails with 'temp/openvpn/dh.pem' : No such file or directory.
Meldung kommt bei:
dh
ca
cert
key
Siehe
https://www.dropbox.com/s/ocanhsdgliwg1yw/router2.PNG?dl=0
Wäre super wenn mir jemand helfen könnte.
ich wollte auf meinem Router auch den OpenVPN Server einrichten. Habe allerdings das Problem, dass wenn ich mich per SSH aufschalte, sehe ich das der Server nicht läuft.
Ich verwende für den Router folgende Firmware: DD-WRT v24-sp2 (06/23/14) std
Die Dateien liegen im Ordner Temp siehe
https://www.dropbox.com/s/kso0trg1072dk7r/router.PNG?dl=0
zusätzlich liegt hier bei mir noch eine ccd Datei. Keine Ahnung was diese bringt.
Was allerdings beim Router etwas komisch finde. Ich habe auch die 7 Textfelder. Bei mir heißen manche aber etwas anders. Sie kommen bei mir in folgender Reihenfolge:
CA-Cert
Public Server Cert
Privat Server Key
DH Pem
Additional Config
TLS Auth Key
Certificate Revoke List
Versuche ich den Server nun über die SSH Konsole zu starten, dann erhalte ich folgende Fehlermeldung:
Options error: --dh fails with 'temp/openvpn/dh.pem' : No such file or directory.
Meldung kommt bei:
dh
ca
cert
key
Siehe
https://www.dropbox.com/s/ocanhsdgliwg1yw/router2.PNG?dl=0
Wäre super wenn mir jemand helfen könnte.
Zitat von @marcel90:
Hallo zusammen,
ich wollte auf meinem Router auch den OpenVPN Server einrichten. Habe allerdings das Problem, dass wenn ich mich per SSH
aufschalte, sehe ich das der Server nicht läuft.
Hallo zusammen,
ich wollte auf meinem Router auch den OpenVPN Server einrichten. Habe allerdings das Problem, dass wenn ich mich per SSH
aufschalte, sehe ich das der Server nicht läuft.
Stell das als reguläre frage statt es als Kommentar in die Anleitung zu schreiben. Dann wird Dir eher geholfen werden können.
lks
Super Anleitung aber irgendwas klappt bei mir nicht, der ovpn Service startet nicht!
Vorweg meine Konfiguration:
- Router, LAN 10.0.0.1
- pfSense / APU, WAN 10.0.0.2, Bridge 192.168.1.1 (Members: LAN & WiFi)
- pfSense 2.2.2-RELEASE (amd64)
Ich habe einen OpenVPN Server nach dieser Anleitung eingerichtet aber mein openvpn service startet nicht. Die Fehlermeldung aus dem log file ist:
openvpn[97889]: Options error: --server directive netmask allows for too many host addresses (subnet must be 255.255.0.0 (/16) or higher)
An irgendeiner Stelle habe ich scheinbar den adressierbaren Netzwerkbereich zu gross angegeben, ich weiss allerdings nicht wo.
Meine OpenVPN Tunnel Network IP hab ich als 172.16.1.0/12 definiert. Damit haette ich meine 3 Netzwerke lokal 'optisch' getrennt. 10.0.0.x zwischen Router und pfSense, 192.168.1.x zwischen allen normalen Clients im WiFi und LAN Bereich und fuer OpenVPN eben den 172.16.1.x Bereich. Wie sinnvoll das ist weiss ich nicht, ich fands 'sauber' aber vermutlich hab ich ja irgendwas falsch gemacht denn sonst wuerde es ja gehen.
Vorweg meine Konfiguration:
- Router, LAN 10.0.0.1
- pfSense / APU, WAN 10.0.0.2, Bridge 192.168.1.1 (Members: LAN & WiFi)
- pfSense 2.2.2-RELEASE (amd64)
Ich habe einen OpenVPN Server nach dieser Anleitung eingerichtet aber mein openvpn service startet nicht. Die Fehlermeldung aus dem log file ist:
openvpn[97889]: Options error: --server directive netmask allows for too many host addresses (subnet must be 255.255.0.0 (/16) or higher)
An irgendeiner Stelle habe ich scheinbar den adressierbaren Netzwerkbereich zu gross angegeben, ich weiss allerdings nicht wo.
Meine OpenVPN Tunnel Network IP hab ich als 172.16.1.0/12 definiert. Damit haette ich meine 3 Netzwerke lokal 'optisch' getrennt. 10.0.0.x zwischen Router und pfSense, 192.168.1.x zwischen allen normalen Clients im WiFi und LAN Bereich und fuer OpenVPN eben den 172.16.1.x Bereich. Wie sinnvoll das ist weiss ich nicht, ich fands 'sauber' aber vermutlich hab ich ja irgendwas falsch gemacht denn sonst wuerde es ja gehen.
Gibt es eine Möglichkeit die Performance zu Optimieren? Ich bin von einem WRT54 v1.1 auf einen TP-Link TL-WDR3600 umgestiegen (125 vs. 560 Mhz + IPC Verbesserungen?!), dabei ist die Bandbreite von ca. 5Mbit auf gerade einmal ~14Mbit angestiegen. Ich hatte mir mehr erhofft, auch liegt die CPU-Auslastung laut Status-Seite bei gerade einmal gut 60% und RAM ist noch etliches frei.
Wird dem OpenVPN nicht mehr CPU-Zeit eingeräumt? Es sieht auf den ersten Blick zu mindestens nicht nach einem Hardware Beschränkung aus.
Wird dem OpenVPN nicht mehr CPU-Zeit eingeräumt? Es sieht auf den ersten Blick zu mindestens nicht nach einem Hardware Beschränkung aus.
Super tutorial, sehr hilfreich. Habe ich zusätzlich zu dieser Anleitung genutzt: https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_sit ...
Folgende Fragen:
Zum einen heißt es oben
"Wichtig für pfSense: Hier ist unbedingt der Haken "Block private Networks" am WAN Port zu entfernen, andernfalls blockt die Firewall alle Pakete am WAN Port wenn ein Router davor liegt ! "
Das gilt nicht, wenn die Firewall in der DMZ des Routers eingetragen wurde, korrekt? (zumindest scheint es bei uns so zu funktionieren)
Dann folgendes:
Ich habe heute unsere Außenstelle via peer-to-peer OpenVPN verbunden, alles läuft (Tunnel via SDSL an beiden Seiten), jedoch würde ich gerne auf den DSL (nicht SDSL) Router dort zugreifen. Die Konstellation sieht wie folgt aus:
plus LAN, natürlich
Wenn ich in der Zentrale die 192.168.3.1 vom PC aus eingebe, gelange ich auf den LTE-Router. Mir ist jedoch nicht ganz klar, welche Route oder Firewallregel ich einstellen muss, um auf die 192.168.3.1 der Außenstelle zu gelangen, sofern das möglich ist.
Folgende Fragen:
Zum einen heißt es oben
"Wichtig für pfSense: Hier ist unbedingt der Haken "Block private Networks" am WAN Port zu entfernen, andernfalls blockt die Firewall alle Pakete am WAN Port wenn ein Router davor liegt ! "
Das gilt nicht, wenn die Firewall in der DMZ des Routers eingetragen wurde, korrekt? (zumindest scheint es bei uns so zu funktionieren)
Dann folgendes:
Ich habe heute unsere Außenstelle via peer-to-peer OpenVPN verbunden, alles läuft (Tunnel via SDSL an beiden Seiten), jedoch würde ich gerne auf den DSL (nicht SDSL) Router dort zugreifen. Die Konstellation sieht wie folgt aus:
Zentrale | Zentrale | Funktion | Außenstelle | Außenstelle |
DSL Router (Bridge) | pfsense PPPoE | OVPN fallback | pfsense (192.168.3.53) | DSL Router (192.168.3.1; Einwahl) |
LTE Router (192.168.3.1; FW in DMZ) | pfsense 192.168.3.253 | Bürointernet | ||
SDSL Router (keine Einwahl, kein Zugriff via WAN/LAN möglich) | pfsense (statische IPs vom ISP) | OVPN | pfsense (statische IPs vom ISP) | SDSL Router (k.E., k.Z. v. W/L m.) |
Wenn ich in der Zentrale die 192.168.3.1 vom PC aus eingebe, gelange ich auf den LTE-Router. Mir ist jedoch nicht ganz klar, welche Route oder Firewallregel ich einstellen muss, um auf die 192.168.3.1 der Außenstelle zu gelangen, sofern das möglich ist.
Ah, verdammt, man merkt, dass Freitag war, ich hatte erst einen anderen Text dastehen, wo auch die LAN Adressen standen. Ich schätze, dich hat die doppelte 3.1 wirklich verwirrt *gg* somit verwirrt mich dein Text ebenso, also versuche ich es noch einmal klarer =) (auch noch einmal komplett, sicher ist sicher)
Zentrale
LTE Router 192.168.3.1 (pfsense in der DMZ eingetragen)
Außenstelle
DSL Router 192.168.3.1 (macht Einwahl, Speedport W 700V, scheint keine Bridgemöglichkeit oder DMZ zu haben)
Statische Routen habe ich keine eingerichtet (hatte ich erst in der Zentrale fälschlicherweise, daraufhin wollte der apinger nicht mehr mit dem LTE, was mir aber auch erst Wochen später auffiel; ich bin mir bis heute nicht sicher, wann eine statische Route gesetzt werden sollte), LTE wird nicht(!) für OpenVPN benutzt (grausame Latenz bei UDP).
SDSL ist Tier 1 für OpenVPN, DSL jeweils Tier 2 sollte SDSL doch mal ausfallen (Gatewaygroup, Portregeln für die Gateways in der pfsense erstellt/kopiert) [da fällt mir ein, ich muss noch die Portweiterleitung für 1195 im Speedport einrichten, falls der weiter die Einwahl tätigt]
Der fehlende Zugriff ist also von der Zentrale aus auf den Speedport DSL Router der Außenstelle.
Wenn ich in der Zentrale die 192.168.3.1 aufrufe, lande ich logischerweise auf dem LTE-Router der Zentrale, vielleicht sollte ich einfach die IP des Speedport ändern? Denn ich müsste doch der zentralen pfsense erstmal eine Route setzen, damit diese weiß, dass sie für die Speedportanfrage zur anderen pfsense muss (da sie ja nur das remote LAN kennt, nicht aber deren Gateways), oder?
Zentrale
LTE Router 192.168.3.1 (pfsense in der DMZ eingetragen)
dazugehöriges Interface der pfsense 192.168.3.253 statisch
SDSL Router (ISP vorkonfiguriert, hat keine eigene bekannte IP)dazugehöriges Interface der pfsense ist statisch (IP, Subnet, Gateway des ISP eingetragen) [DEFAULT gateway]
DSL Router (Bridge)dazugehöriges Interface der pfsense PPPoE Einwahl)
LAN 192.168.100.0/24dazugehöriges Interface der pfsense 192.168.100.254
OpenVPN Server (p2p) 10.200.0.0/30:1195 [gibt nen zweiten OVPN Server da drauf mit 10.100.0.0/24:1194 für auth user+key+cert Zugriffe, spielt aber hierfür keine Rolle]local und remote Netzwerke eingetragen
Außenstelle
DSL Router 192.168.3.1 (macht Einwahl, Speedport W 700V, scheint keine Bridgemöglichkeit oder DMZ zu haben)
dazugehöriges Interface der pfsense 192.168.3.253 statisch (gewohnte Adressen *hust*) [DEFAULT gateway]
SDSL Router (ISP vorkonfiguriert, hat keine eigene bekannte IP)dazugehöriges Interface der pfsense ist statisch (IP, Subnet, Gateway des ISP eingetragen)
LAN 192.168.200.0/24dazugehöriges Interface der pfsense 192.168.200.254
OpenVPN Client (p2p) 10.200.0.0/30:1195 TunnelnetzwerkStatische Routen habe ich keine eingerichtet (hatte ich erst in der Zentrale fälschlicherweise, daraufhin wollte der apinger nicht mehr mit dem LTE, was mir aber auch erst Wochen später auffiel; ich bin mir bis heute nicht sicher, wann eine statische Route gesetzt werden sollte), LTE wird nicht(!) für OpenVPN benutzt (grausame Latenz bei UDP).
SDSL ist Tier 1 für OpenVPN, DSL jeweils Tier 2 sollte SDSL doch mal ausfallen (Gatewaygroup, Portregeln für die Gateways in der pfsense erstellt/kopiert) [da fällt mir ein, ich muss noch die Portweiterleitung für 1195 im Speedport einrichten, falls der weiter die Einwahl tätigt]
Der fehlende Zugriff ist also von der Zentrale aus auf den Speedport DSL Router der Außenstelle.
Wenn ich in der Zentrale die 192.168.3.1 aufrufe, lande ich logischerweise auf dem LTE-Router der Zentrale, vielleicht sollte ich einfach die IP des Speedport ändern? Denn ich müsste doch der zentralen pfsense erstmal eine Route setzen, damit diese weiß, dass sie für die Speedportanfrage zur anderen pfsense muss (da sie ja nur das remote LAN kennt, nicht aber deren Gateways), oder?
Ich seh' schon: Heute mit Bildern (allerdings nur Zentrale, auf die FW der Außenstelle komme ich von hier nicht rauf, das hab ich nur für die IP meines Arbeitsrechners freigegeben, fällt mir ein ^^)
Transfernetzwerk? Verstehe nicht, was du meinst, sorry.
Muss mich da aber auch korrigieren (Daten waren gestern aus dem Kopf), das OpenVPN Tunnel Netzwerk ist 10.244.200.0/30, somit hat der Client (also die pfsense der Außenstelle) die 10.244.200.1 als virt. addr.
Das mit dem SDSL scheinst du missverstanden zu haben, schätze ich oder man versteht mich (mal wieder) nicht.
Die SDSL-Anschlüsse sind 176.er /29 Netze, die wieauchimmer konfigurierten Router dienen lt. ISP nur zum Synchronisieren und Nutzen der vier Leitungen, das Teil selbst hat keine IP aus dem Addressbereich und auch keinerleit Routerfunktionen aktiv (auch kein NAT).
Die Daten, die in der pfsense eingetragen werden, sind vom ISP übermittelte Adressen, da es sich um öffentliche IP Adressen handelt (zumindest das Gateway, man kann sich ja aber die weiteren Adressen berechnen) habe ich diese hier nur nicht mitgeteilt.
Der einzige Router, der momenten bezüglich OpenVPN NAT ausführt, ist der Speedport (natürlich führt der LTE-Router auch NAT aus, ist aber a) kein OpenVPN Zugang und b) sollte das ja nicht kümmern, da die pfsense in der DMZ eingetragen ist).
Zum Thema MultiWAN:
Das habe ich ganz simpel eingestellt: Reine Gatewaygruppen, kein load balancing.
Welche Gateways default sind, hab ich eigentlich beim letzten Mal doch sichtbar gemacht, meine ich.
In der Außenstelle gibt es nur eine Gatewaygruppe, SDSL Tier 1 > ADSL Tier 2 [ADSL/GW_WAN ist noch Default Gateway]
Ist ein Gateway down, greift sich pfsense das nächste, funktioniert seit Jahren so einwandfrei.
Somit ist bei den OpenVPN Servern die OVPN Gatewaygroup als Interface gesetzt.
Dementsprechend sind die Regeln bei den betreffenden Interfaces dann auch gleich
Ich hoffe, das ist hilfreich für dich, mir ist nur das mit dem Transfernetzwerk nicht klar.
Transfernetzwerk? Verstehe nicht, was du meinst, sorry.
Muss mich da aber auch korrigieren (Daten waren gestern aus dem Kopf), das OpenVPN Tunnel Netzwerk ist 10.244.200.0/30, somit hat der Client (also die pfsense der Außenstelle) die 10.244.200.1 als virt. addr.
Das mit dem SDSL scheinst du missverstanden zu haben, schätze ich oder man versteht mich (mal wieder) nicht.
Die SDSL-Anschlüsse sind 176.er /29 Netze, die wieauchimmer konfigurierten Router dienen lt. ISP nur zum Synchronisieren und Nutzen der vier Leitungen, das Teil selbst hat keine IP aus dem Addressbereich und auch keinerleit Routerfunktionen aktiv (auch kein NAT).
Die Daten, die in der pfsense eingetragen werden, sind vom ISP übermittelte Adressen, da es sich um öffentliche IP Adressen handelt (zumindest das Gateway, man kann sich ja aber die weiteren Adressen berechnen) habe ich diese hier nur nicht mitgeteilt.
Der einzige Router, der momenten bezüglich OpenVPN NAT ausführt, ist der Speedport (natürlich führt der LTE-Router auch NAT aus, ist aber a) kein OpenVPN Zugang und b) sollte das ja nicht kümmern, da die pfsense in der DMZ eingetragen ist).
Zum Thema MultiWAN:
Das habe ich ganz simpel eingestellt: Reine Gatewaygruppen, kein load balancing.
Welche Gateways default sind, hab ich eigentlich beim letzten Mal doch sichtbar gemacht, meine ich.
In der Außenstelle gibt es nur eine Gatewaygruppe, SDSL Tier 1 > ADSL Tier 2 [ADSL/GW_WAN ist noch Default Gateway]
Ist ein Gateway down, greift sich pfsense das nächste, funktioniert seit Jahren so einwandfrei.
Somit ist bei den OpenVPN Servern die OVPN Gatewaygroup als Interface gesetzt.
Dementsprechend sind die Regeln bei den betreffenden Interfaces dann auch gleich
Ich hoffe, das ist hilfreich für dich, mir ist nur das mit dem Transfernetzwerk nicht klar.
Zitat von @aqui:
Das ist immer das Netz was direkt am Eingansrouter ist und zum pfSense WAN Port führt ! Laut deiner beschreibung ist das mit der .3.0 /24 gleich an beiden Standorten.
Ok, also Netz des Speedport ändern, wird gemacht - bzw. gucken, ob ich ihn auf PPPoE Passthrough setzen kann (hab beim letzten Mal erstmal keine Option dafür gefunden), sodass die pfsense die PPPoE Einwahl betreibt.Das ist immer das Netz was direkt am Eingansrouter ist und zum pfSense WAN Port führt ! Laut deiner beschreibung ist das mit der .3.0 /24 gleich an beiden Standorten.
OK, bedeutet du bekommst am LAN Port des Provider Routers ein kleines öffentliches Subnetz, richtig ?
Richtig, der Router ist ein Technicolor TG670s und von dessen LAN Port geht es in den Opt2 der pfsense.Deshalb auch die berechtigte Frage WO die Default Gateways der pfSense hinzeigen bzw. WIE deren Routing Tabellen aussehen !!!
Da du mehrere WAN Ports hier betreibst ist das für den Traffic Flow essentiell wichtig zu wissen.
Sowas wie "DMZ" gibt es an einen Speedport Schrottrouter nicht. Vergiss den Quatsch. Was du hier machst ist ein sog. exposed Host. Sprich der Speedport schaufelt alle TCP/UDP Ports von inbound Traffic die er nicht selber kennt an die pfSense. Mit DMZ hat sowas rein gar nichts zu tun !
Richtig, Exposed Host nennt sich das beim LTE-Router [fiel mir nicht mehr ein, bin DMZ so gewohnt], der Speedport hat das nicht mal, soweit ich in den Einstellungen sehen konnte.Da du mehrere WAN Ports hier betreibst ist das für den Traffic Flow essentiell wichtig zu wissen.
Sowas wie "DMZ" gibt es an einen Speedport Schrottrouter nicht. Vergiss den Quatsch. Was du hier machst ist ein sog. exposed Host. Sprich der Speedport schaufelt alle TCP/UDP Ports von inbound Traffic die er nicht selber kennt an die pfSense. Mit DMZ hat sowas rein gar nichts zu tun !
Zentrale
Außenstelle
Entspricht die Topo Zeichnung oben nun den aktuellen Gegebenheiten oder muss die noch korrigiert werden ?
Stimmt so.So oder so ist die Konfig aber OK wenn man mal davon absieht so wichtige Komponenten über ungeschütztes Port Forwarding zugänglich zu machen. Da fragt man sich ernsthaft warum du ein VPN hast ?
*Schulterzuck* war damals im IPCop so, bevor wir OpenVPN hatten, hab mich damit nicht weiter auseinandergesetzt.Wir haben auf dem virt. SQL Server gleichzeitig nen IIS, der die Fehlzeitenverwaltung und Auftragsbuchung macht. Daher Port 80 auf den, weil jeder dann via dyndns auf das Portal kommt (unsere Monteure buchen via Smartphonebrowser darüber).
Das Alarmanlagenzeugs ist relativ neu, die Anfragen gehen wohl auf das Interface (wohl als App, k.A. steck' da nicht drin, wurde völlig überrumpelt damit)
Ich hab' mich immer gefragt, ob das nicht eigentlich eine direkte Sicherheitslücke ist, aber da ich es nicht besser weiß, regelt ein unfangreich konfiguriertes SNORT auf der pfsense was da reinkommt und/oder geblockt wird.
Achja, eine (wohl wichtige?) Information hab ich bisher verpennt mitzuteilen: Die OVPN Gatewaygruppe der Zentrale gibt seine aktuelle IP an dyndns weiter (zwar hat SDSL ja eine feste, aber wenn das doch mal ausfällt ...). Also alle Zugriffe von außen gehen via dyndns rein (auch der OpenVPN Client der Außenstelle).
Wenn sich das mit den Ports anders regeln lässt, bin ich ganz Ohr.
Werden jetzt noch weitere Informationen benötigt?
LAN Regeln?
- in der Außenstelle geht DHCP [Alias] über WAN, Rest [Alias] über die OVPN Gruppe
- in der Zentrale: DHCP [Alias] via WAN; Rest [Alias] über die "Firma" Gruppe
Die ursprüngliche Frage war ja, wie ich auf den Speedport von der Zentrale aus komme, aber a) ist da momentan ja noch die Dopplung 3.1 und b) wäre der als bridge idealer, wodurch sich die Thematik dann eigentlich in Luft auflösen würde *lach*
(Das Problem für mich ist momentan vorallem die Einwahldaten zu bekommen, nicht dass vor mir irgendwer was sinnvoll dokumentiert oder abgelegt hätte ...)
(Das Problem für mich ist momentan vorallem die Einwahldaten zu bekommen, nicht dass vor mir irgendwer was sinnvoll dokumentiert oder abgelegt hätte ...)
Der Klassiker war es, vor Ort falsche Daten vorzufinden und einzugeben, um dann nach einer Sperre bei der Telekom anzurufen.
Dann also hat man endlich die richtigen Daten, jedoch schafft es die pfsense nicht, sich einzuwählen. (DHCP im Speedport deaktiviert, PPPoE-Passthrough aktiviert)
pfsense neugestartet, Speedport neugestarte, Kabel rein / raus (Speedport und pfsense hardware zeigen aktiven link/LED)
Hab dann auch im WAN Interface die MAC der NIC eingetragen (spoof), falls das für die Telekom notwenig ist - nada. Ob das nun an dem ### Speedport liegt oder kann ich da jetzt noch was an der pfsense testen?
Nachtrag: ### drauf, ich werd das von dir verlinkte Modem besorgen, dann muss ich mich nicht ständig mit dem Speedport rumärgern, die Außenstelle muss netzwerktechnisch eh noch etwas ausgebaut werden, gibt's eben solange kein OpenVPN failover (denn das schöne Portforwarding frisst scheinbar auch nur IPs die er von sich aus via DHCP ins NAT holt, geiles Teil).
Dann also hat man endlich die richtigen Daten, jedoch schafft es die pfsense nicht, sich einzuwählen. (DHCP im Speedport deaktiviert, PPPoE-Passthrough aktiviert)
May 25 12:28:47 ppp: [wan_link0] LCP: Down event
May 25 12:28:47 ppp: [wan_link0] Link: reconnection attempt 3 in 4 seconds
May 25 12:28:51 ppp: [wan_link0] Link: reconnection attempt 3
May 25 12:28:51 ppp: [wan_link0] PPPoE: Connecting to ''
May 25 12:29:00 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
May 25 12:29:00 ppp: [wan_link0] Link: DOWN event
May 25 12:29:00 ppp: [wan_link0] LCP: Down event
May 25 12:29:00 ppp: [wan_link0] Link: reconnection attempt 4 in 2 seconds
May 25 12:29:02 ppp: [wan_link0] Link: reconnection attempt 4
May 25 12:29:02 ppp: [wan_link0] PPPoE: Connecting to ''
May 25 12:29:11 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
May 25 12:29:11 ppp: [wan_link0] Link: DOWN event
May 25 12:29:11 ppp: [wan_link0] LCP: Down event
May 25 12:29:11 ppp: [wan_link0] Link: reconnection attempt 5 in 3 seconds
May 25 12:29:14 ppp: [wan_link0] Link: reconnection attempt 5
May 25 12:29:14 ppp: [wan_link0] PPPoE: Connecting to ''
May 25 12:29:23 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
May 25 12:29:23 ppp: [wan_link0] Link: DOWN event
May 25 12:29:23 ppp: [wan_link0] LCP: Down event
May 25 12:29:23 ppp: [wan_link0] Link: reconnection attempt 6 in 1 seconds
May 25 12:29:24 ppp: [wan_link0] Link: reconnection attempt 6
May 25 12:29:24 ppp: [wan_link0] PPPoE: Connecting to ''
May 25 12:29:33 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
May 25 12:29:33 ppp: [wan_link0] Link: DOWN event
May 25 12:29:33 ppp: [wan_link0] LCP: Down event
May 25 12:29:33 ppp: [wan_link0] Link: reconnection attempt 7 in 3 seconds
May 25 12:29:36 ppp: [wan_link0] Link: reconnection attempt 7
May 25 12:29:36 ppp: [wan_link0] PPPoE: Connecting to ''
May 25 12:29:45 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
May 25 12:29:45 ppp: [wan_link0] Link: DOWN event
May 25 12:29:45 ppp: [wan_link0] LCP: Down event
Hab dann auch im WAN Interface die MAC der NIC eingetragen (spoof), falls das für die Telekom notwenig ist - nada. Ob das nun an dem ### Speedport liegt oder kann ich da jetzt noch was an der pfsense testen?
Nachtrag: ### drauf, ich werd das von dir verlinkte Modem besorgen, dann muss ich mich nicht ständig mit dem Speedport rumärgern, die Außenstelle muss netzwerktechnisch eh noch etwas ausgebaut werden, gibt's eben solange kein OpenVPN failover (denn das schöne Portforwarding frisst scheinbar auch nur IPs die er von sich aus via DHCP ins NAT holt, geiles Teil).
Ist halt nur komisch, dass es beim 1. Mal ja scheinbar geklappt hat - als ich die falschen Daten hatte und die pfsense einfach ohne Ende sich damit versuchte einzuwählen (und somit der Anschluss automatisch gesperrt wurde, weswegen ich bei der Telekom Kundenhotline anrufen musste), mit den korrekten Daten dann aber kein Link mehr zustande kam ... wobei ich nachwievor dem T-DSL Benutzernamen nicht traue.
in der config.bin des Routers war die 12-stellige Anschlusskennung + 12-stellige T-Online Kennung + Raute + Benutzerzahl, dabei soll die Raute lt. off. Telekomeintragungen nur dann eingetragen werden, wenn die T-Online Kennung weniger als 12 Stellen hat.
PPPoE war bei dieser auch erst deaktiviert, Firmware war auf 3.33.000 also der letzte Stand.
Aber gut, das ginge dann auch weiter am Thema des Threads vorbei (ich dachte auch nicht, dass meine "kleine" Anfrage so ausufern würde *lach*).
Eine letzte Frage zur pfsense hätte ich allerdings noch (ich glaube, darum hab ich damals bei der Zentrale statische Routen für den apinger eingerichtet): Man hat ja auf der Startseite (ich nutze weiterhin version 2.6, die 3er lief auf dem nano nicht fehlerfrei) die Interfaces, wenn jedoch ein Gateway down ist (zumindest wenn static ip), wird das Interface nachwievor als up angezeigt (intern greifen aber die korrekten Gatewaygruppen, man ist dann mit dem failover aktiv). Ich setze ja extra OpenDNS oder google DNS Server als Monitor IP, was nutzt da die Information der Interfaces, wenn sie nichts über den Zustand der Internetverbindung aussagt?
in der config.bin des Routers war die 12-stellige Anschlusskennung + 12-stellige T-Online Kennung + Raute + Benutzerzahl, dabei soll die Raute lt. off. Telekomeintragungen nur dann eingetragen werden, wenn die T-Online Kennung weniger als 12 Stellen hat.
PPPoE war bei dieser auch erst deaktiviert, Firmware war auf 3.33.000 also der letzte Stand.
Aber gut, das ginge dann auch weiter am Thema des Threads vorbei (ich dachte auch nicht, dass meine "kleine" Anfrage so ausufern würde *lach*).
Eine letzte Frage zur pfsense hätte ich allerdings noch (ich glaube, darum hab ich damals bei der Zentrale statische Routen für den apinger eingerichtet): Man hat ja auf der Startseite (ich nutze weiterhin version 2.6, die 3er lief auf dem nano nicht fehlerfrei) die Interfaces, wenn jedoch ein Gateway down ist (zumindest wenn static ip), wird das Interface nachwievor als up angezeigt (intern greifen aber die korrekten Gatewaygruppen, man ist dann mit dem failover aktiv). Ich setze ja extra OpenDNS oder google DNS Server als Monitor IP, was nutzt da die Information der Interfaces, wenn sie nichts über den Zustand der Internetverbindung aussagt?
So, nun hat ja der Speedport die 192.168.33.1 (kreativ, gelle) und das pfsense WAN Interface der Außenstelle die 192.168.33.253 - es gibt also keine Dopplung mehr, dennoch komme ich von der Zentrale aus nicht zum Speedport der Außenstelle.
Interessanterweise (und das ist für mich ein Rätsel), musste ich vor Ort in der pfsense der Außenstelle bei LAN
erstellen, obwohl es ja
gibt. Aber ich kam vor Ort vorher auch nicht vom 200er Netzwerk auf den Speedport.
Dort ist im OpenVPN tab auch
eingetragen, aber(!)
ich sehe vom Windows-client via tracert, dass die Anfrage an die 192.168.33.1 über das LTE (192.168.3.1; was momentan mein Internetgateway ist) geht, also gar nicht irgendwie über das OpenVPN verarbeitet wird.
Auch via ping und traceroute auf der pfsense selbst gibt es keine Ergebnisse.
Ich habe das 192.168.33.0/24 mit beim OpenVPN Server als Remotenetzwerk eingetragen und den Service neugestartet, dies ist die Routentabelle der Zentrale:
Da ich in Kürze längere Zeit ausfallen werde, wird der Speedport so schnell nicht durch das Modem ersetzt werden, daher möchte ich zumindest noch den Zugriff auf das Gerät von der Zentrale hinbekommen, also sind wir wieder am Anfang meines Problemes und ich hoffe weiterhin auf deine kompetente Hilfestellung, für die ich sehr dankbar bin.
Interessanterweise (und das ist für mich ein Rätsel), musste ich vor Ort in der pfsense der Außenstelle bei LAN
IPv4 * | LAN net | * | 192.168.33.1 | * | * | none |
IPv4 * | LAN net | * | * | * | * | none |
Dort ist im OpenVPN tab auch
IPv4 * | 192.168.100.20 | * | This Firewall | * | OVPN | none |
IPv4 * | 192.168.100.12 | * | This Firewall | * | OVPN | none |
IPv4 * | 192.168.100.20 | * | 192.168.33.0/24 | * | * | none |
IPv4 * | Berlin | * | OfficeFW | * |
ich sehe vom Windows-client via tracert, dass die Anfrage an die 192.168.33.1 über das LTE (192.168.3.1; was momentan mein Internetgateway ist) geht, also gar nicht irgendwie über das OpenVPN verarbeitet wird.
Auch via ping und traceroute auf der pfsense selbst gibt es keine Ergebnisse.
Ich habe das 192.168.33.0/24 mit beim OpenVPN Server als Remotenetzwerk eingetragen und den Service neugestartet, dies ist die Routentabelle der Zentrale:
default | 176.94.227.17 | UGS | 28654896 | 1500 | xl2 |
8.8.4.4 | pppoe1 | UHS | 395498 | 1492 | pppoe1 |
8.8.8.8 | 188.103.216.1 | UGHS | 82 | 1492 | pppoe1 |
10.244.100.0/24 | 10.244.100.2 | UGS | 0 | 1500 | ovpns1 |
10.244.100.1 | link#10 | UHS | 0 | 16384 | lo0 |
10.244.100.2 | link#10 | UH | 0 | 1500 | ovpns1 |
10.244.200.1 | link#11 | UHS | 0 | 16384 | lo0 |
10.244.200.2 | link#11 | UH | 0 | 1500 | ovpns2 |
127.0.0.1 | link#7 | UH | 8791 | 16384 | lo0 |
176.XXX.XXX.16/29 | link#4 | U | 216 | 1500 | xl2 |
176.XXX.XXX.22 | link#4 | UHS | 0 | 16384 | lo0 |
188.XXX.XXX.1 | link#9 | UH | 0 | 1492 | pppoe1 |
188.XXX.XXX.200 | link#9 | UHS | 0 | 16384 | lo0 |
192.168.3.0/24 | link#3 | U | 3 | 1500 | xl1 |
192.168.3.253 | link#3 | UHS | 0 | 16384 | lo0 |
192.168.33.0/24 | 10.244.200.2 | UGS | 0 | 1500 | ovpns2 |
192.168.100.0/24 | link#1 | U | 142513697 | 1500 | re0 |
192.168.100.254 | link#1 | UHS | 0 | 16384 | lo0 |
192.168.200.0/24 | 10.244.200.2 | UGS | 77 | 1500 | ovpns2 |
208.67.220.220 | 192.168.3.1 | UGHS | 12387010 | 1500 | xl1 |
208.67.222.222 | 176.94.227.17 | UGHS | 3944161 | 1500 | xl2 |
Da ich in Kürze längere Zeit ausfallen werde, wird der Speedport so schnell nicht durch das Modem ersetzt werden, daher möchte ich zumindest noch den Zugriff auf das Gerät von der Zentrale hinbekommen, also sind wir wieder am Anfang meines Problemes und ich hoffe weiterhin auf deine kompetente Hilfestellung, für die ich sehr dankbar bin.
Ich komme vor Ort aus dem .200/24 auf den Speedport.
Von der Zentrale schiebt die pfsense aber die Anfrage nicht durch den Tunnel. Ein traceroute ergibt nur * * * mit tracert aus der cmd sehe ich, dass die Anfrage über das LTE-Gateway geht, also das 192.168.3.1; also wie jede normale Anfrage ans Internet.
Wie mache ich der pfsense in der Zentrale nun klar, dass die diese Anfrage gefälligst in den Tunnel zur Außenstelle schiebt?
Eigentlich dachte ich, dass die Eintragung des Netzes als zusätzliches remote network ausreichen würde, da es ja dann auch in der routing Tabelle auftaucht.
Von der Zentrale schiebt die pfsense aber die Anfrage nicht durch den Tunnel. Ein traceroute ergibt nur * * * mit tracert aus der cmd sehe ich, dass die Anfrage über das LTE-Gateway geht, also das 192.168.3.1; also wie jede normale Anfrage ans Internet.
Wie mache ich der pfsense in der Zentrale nun klar, dass die diese Anfrage gefälligst in den Tunnel zur Außenstelle schiebt?
Eigentlich dachte ich, dass die Eintragung des Netzes als zusätzliches remote network ausreichen würde, da es ja dann auch in der routing Tabelle auftaucht.
Ich hab nur pfsense GUI, keine .conf, es kommunizieren ja nur pfsense und pfsense und keine Windows-OVPN-Clients über das ptp.
Daher sind auch keine manuellen route oder push route gesetzt, denn ich ging davon aus, dass es genau deswegen ja die Felder Local Networks und Remote Networks gibt und man nichts mehr händisch eintragen muss unter Advanced.
Und in der zentralen pfsense steht ja nun:
Local Network/s: 192.168.100.0/24
Remote Networks: 192.168.200.0/24, 192.168.33.0/24
und in der Außenstelle:
Remote Network/s: 192.168.100.0/24
[dort gibt es Local Networks nicht als Feld]
Also muss ich jetzt doch noch 'nen route Eintrag im Advanced der Außenstelle eintragen, damit die Zentrale die Anfrage dort hinschickt?
Für das .200 Netwerk musste ich ja auch keine setzen, daher überrascht mich das.
Daher sind auch keine manuellen route oder push route gesetzt, denn ich ging davon aus, dass es genau deswegen ja die Felder Local Networks und Remote Networks gibt und man nichts mehr händisch eintragen muss unter Advanced.
These are the IPv4 networks that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables.
Und in der zentralen pfsense steht ja nun:
Local Network/s: 192.168.100.0/24
Remote Networks: 192.168.200.0/24, 192.168.33.0/24
und in der Außenstelle:
Remote Network/s: 192.168.100.0/24
[dort gibt es Local Networks nicht als Feld]
Also muss ich jetzt doch noch 'nen route Eintrag im Advanced der Außenstelle eintragen, damit die Zentrale die Anfrage dort hinschickt?
Für das .200 Netwerk musste ich ja auch keine setzen, daher überrascht mich das.
Ach, sowas. Ich leite ja via LAN Regeln einzelne Clients über andere Gateways, mich ja auch. Nun hab ich mich mal aus dem Alias geworfen, sodass keine gesonderte LAN Regel gilt und schon geht die Anfrage an die 33.1 zumindest über den Tunnel
Nachtrag: Eine zusätzliche Regel davor, um meine LAN IP an 192.168.33.0/24 über das default gateway zu erlauben, hat das dann auch gelöst, sodass ich weiter im Alias geführt werde.
Also muss ich zum Einen wohl doch noch irgendwo 'ne route (oder push route?) eintragen? Die Interface IP geht, zum Speedport bleibt es bei der virt. OpenVPN Adresse des pfsense Client hängen.
Nachtrag: Eine zusätzliche Regel davor, um meine LAN IP an 192.168.33.0/24 über das default gateway zu erlauben, hat das dann auch gelöst, sodass ich weiter im Alias geführt werde.
Routenverfolgung zu 192.168.33.253 über maximal 30 Abschnitte
1 <1 ms <1 ms <1 ms pfsense.wpt-berlin.zz [192.168.100.254]
2 9 ms 8 ms 9 ms 192.168.33.253
Ablaufverfolgung beendet.
Routenverfolgung zu 192.168.33.1 über maximal 30 Abschnitte
1 <1 ms <1 ms <1 ms pfsense.wpt-berlin.zz [192.168.100.254]
2 9 ms 8 ms 8 ms 10.244.200.2
3 * * * Zeitüberschreitung der Anforderung.
Also muss ich zum Einen wohl doch noch irgendwo 'ne route (oder push route?) eintragen? Die Interface IP geht, zum Speedport bleibt es bei der virt. OpenVPN Adresse des pfsense Client hängen.
Hi,
die Konfiguration hat sich inzwischen geändert ich hänge mit einem ddr-wrt Router (im Switch-Modus) mit OpenVPN Server hinter einem dd-wrt Router.
Ich kann im lokalen Netz eine OpenVPN Verbindung aufbauen, leider komme ich nicht durch die SPI-Firewall, obwohl ich die FW wie folgt konfiguriert habe:
iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
Im NAT habe ich folgende Port Forwarding Einstellungen erstellt:
Name1 UDP 0.0.0.0 (Sub-Net) 1194 (Source) 192.168.X.A 1194 (to Port)
Name2 UDP 0.0.0.0 (Sub-Net) 1195 (Source) 192.168.X.B 1195 (to Port)
Regel1 (Name1) kommt durch 1194 ABER 1195 nicht!?
Der Client meldet:
[ECONNREFUSED]:Connection refused (code=111)
Google hat mir leider nicht weiter geholfen und die stöber schon zu x-mal die Config durch und sehe den Fehler nicht
die Konfiguration hat sich inzwischen geändert ich hänge mit einem ddr-wrt Router (im Switch-Modus) mit OpenVPN Server hinter einem dd-wrt Router.
Ich kann im lokalen Netz eine OpenVPN Verbindung aufbauen, leider komme ich nicht durch die SPI-Firewall, obwohl ich die FW wie folgt konfiguriert habe:
- Akzeptiert eingehende Anfragen am Port UDP 1194.
iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT
- Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfl&#-28;che, SSH etc)
- Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist.
- Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht f&#-4;r LAN und WLAN).
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
Im NAT habe ich folgende Port Forwarding Einstellungen erstellt:
Name1 UDP 0.0.0.0 (Sub-Net) 1194 (Source) 192.168.X.A 1194 (to Port)
Name2 UDP 0.0.0.0 (Sub-Net) 1195 (Source) 192.168.X.B 1195 (to Port)
Regel1 (Name1) kommt durch 1194 ABER 1195 nicht!?
Der Client meldet:
[ECONNREFUSED]:Connection refused (code=111)
Google hat mir leider nicht weiter geholfen und die stöber schon zu x-mal die Config durch und sehe den Fehler nicht
Mit Switch-Modus meinte ich das der WAN Port als LAN Port konfiguriert ist.
iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT ist für die zweite OpenVPN instanz auf dem Router 192.168.X.B ich habe nun in der zeie die Destination hinzugefügt:
iptables -I INPUT 1 -d 192.168.X.B/24 -p udp --dport 1195 -j ACCEPT
Leider geht es immer noch nicht.
iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT ist für die zweite OpenVPN instanz auf dem Router 192.168.X.B ich habe nun in der zeie die Destination hinzugefügt:
iptables -I INPUT 1 -d 192.168.X.B/24 -p udp --dport 1195 -j ACCEPT
Leider geht es immer noch nicht.
Der Sinn dahinter ist das ich den WAN Port als LAN-Port nutzen kann und somit ein gemeinsames Netzwerk habe.
Wie meinst du das mit einbeinig? Der zweite OPVN Server hängt am RouterA mit der IP 192.168.X.A als Gateway/DNS etc. Der Router B mit 192.168.X.B ist als Switch/Access-Point und 2. OPVN konfiguriert.
Im Netz 192.168.X.X kann ich zu 192.168.X.B eine OVPN Verbindung aufbauen. Sobald ich außerhalb von (bzw. vor) 192.168.X.A kommt nun inzwischen folgendes:
TLS Error: TLSkey negotiation failed or occur within 60 sec
TLS hansshake failed
Das ist sehr generisch... leider.
Da tcpdump noch extra installiert werden muss, bin ich noch nicht dazu gekommen.
Wie meinst du das mit einbeinig? Der zweite OPVN Server hängt am RouterA mit der IP 192.168.X.A als Gateway/DNS etc. Der Router B mit 192.168.X.B ist als Switch/Access-Point und 2. OPVN konfiguriert.
Im Netz 192.168.X.X kann ich zu 192.168.X.B eine OVPN Verbindung aufbauen. Sobald ich außerhalb von (bzw. vor) 192.168.X.A kommt nun inzwischen folgendes:
TLS Error: TLSkey negotiation failed or occur within 60 sec
TLS hansshake failed
Das ist sehr generisch... leider.
Da tcpdump noch extra installiert werden muss, bin ich noch nicht dazu gekommen.
Wenn man Open VPN als "VPN Split" haben möchte. Was muss muss man in die Config eintragen ?
Gruss
Rainer
Gruss
Rainer
An dieser Stelle stellvertretend für die vielen Anleitungen ein riesen Dankeschön an aqui!
Ich hatte ohne Übertreibung ein halbes dutzend Tutorials durch und wollte bereits aufgeben, als ich hier in dieser Anleitung den Hinweis sah: Hier ist unbedingt der Haken "Block private Networks" am WAN Port zu entfernen, andernfalls blockt die Firewall alle Pakete am WAN Port wenn ein Router davor liegt!
Mit etwas besserem Verständnis der Materie hätte man das sicher auch selbst erkennen können, aber nochmal vielen Dank für diese und viele andere Anleitungen und Tipps!
Ich hatte ohne Übertreibung ein halbes dutzend Tutorials durch und wollte bereits aufgeben, als ich hier in dieser Anleitung den Hinweis sah: Hier ist unbedingt der Haken "Block private Networks" am WAN Port zu entfernen, andernfalls blockt die Firewall alle Pakete am WAN Port wenn ein Router davor liegt!
Mit etwas besserem Verständnis der Materie hätte man das sicher auch selbst erkennen können, aber nochmal vielen Dank für diese und viele andere Anleitungen und Tipps!
Hallo ich habe eine Frage bezüglich der statischen Routing Tabelle in der Fritzbox. Ich habe das Setup mal Angehängt. Kann mir jemand sagen wie ich korrekte Einstellungen in der Fritzbox vornehmen kann? Derzeit ist der Server nicht im Internet erreichbar deshalb denke ich müsste es am fehlenden Routing durch die Fritzbox liegen. Leider komme ich trotz der Screenshots im Thread nicht dahinter.
Vielen dank! Wenn mehr Infos gebraucht werden kurz melden!
lg.
Vielen dank! Wenn mehr Infos gebraucht werden kurz melden!
lg.
Habe das auf einem APU4D4 Board mit pfSense 2.4.5-RELEASE umgesetzt.
Dazu 2 kleine Anmerkungen:
Unter System/Advanced/Miscellaneous/CryptographicHardware unbedingt "BSD Crypto Device" oder "AES NI and BSD Crypto Device" einstellen.
Nur "AES NI" reicht nicht. Diese wird im Wzard nicht als Hardware Crypto erkannt.
Ausserdem musste ich nach dieser Änderung die pfSense neu starten. Erst dann erschien die Hardware Crypto im Wizard.
Die Custom Options für den Eintrag "push route ..." wurde mir im Wizard gar nicht angezeigt.
Ist aber kein Problem, einfach den Wizard bis zum Ende durchlaufen und dann unter
VPN/OpenVPN/Servers/Edit ganz unten bei AdvancedConfiguration/CustomOptions nachtragen.
Ansonsten hat alles problemlos geklappt. Danke für das Tutorial!
Dazu 2 kleine Anmerkungen:
Unter System/Advanced/Miscellaneous/CryptographicHardware unbedingt "BSD Crypto Device" oder "AES NI and BSD Crypto Device" einstellen.
Nur "AES NI" reicht nicht. Diese wird im Wzard nicht als Hardware Crypto erkannt.
Ausserdem musste ich nach dieser Änderung die pfSense neu starten. Erst dann erschien die Hardware Crypto im Wizard.
Die Custom Options für den Eintrag "push route ..." wurde mir im Wizard gar nicht angezeigt.
Ist aber kein Problem, einfach den Wizard bis zum Ende durchlaufen und dann unter
VPN/OpenVPN/Servers/Edit ganz unten bei AdvancedConfiguration/CustomOptions nachtragen.
Ansonsten hat alles problemlos geklappt. Danke für das Tutorial!