23.08.2009, aktualisiert am 12.12.2024

338084

160

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.

Allgemeine Einleitung

Dieses Tutorial basiert auf den bei Administrator.de bereits bestehenden Tutorials von @datasearch zum Einrichten eines OpenVPN Servers:
OpenVPN_Teil_2 und auch Merkzettel: VPN Installation mit OpenVPN
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:

b3d4ab85fd51708473007faa1c7da21c-openvpn

Bzw. mit der pFsense Variante dann analog:

dd3cd9d586a54d7bfffeff24ce75ac6e-openvpn1

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_COUNTRY=DE
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 Schlüsselerzeugung ist damit abgeschlossen und alle Schlüssel findet man im Verzeichnis /keys in das man dann mit "cd keys" wechselt und die man dann z.B. auf USB Stick sichert oder aus diesem Verzeichnis direkt in die entsprechenden Eingabefelder bei dd-wrt per cut and paste kopiert.
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 !

81e2056934737de0d8ea4570cbea9ce8-ddwrt4ter

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 !

In einer Kaskaden_Konfiguration z.B. mit einem NAT Router VOR der pfSense Firewall dürfen also die RFC 1918 Netze NICHT geblockt sein:

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:
L2TP VPN Mit Mikrotik
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 IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Praxistutorial Wireguard:
Merkzettel: VPN Installation mit Wireguard

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 123285

Url: https://administrator.de/tutorial/openvpn-server-installieren-auf-pfsense-firewall-mikrotik-dd-wrt-oder-gl-inet-router-123285.html

Ausgedruckt am: 22.12.2024 um 01:12 Uhr

160 Kommentare

Neuester Kommentar

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 ?

Ooopsa.... Danke für den Hinweis ! Du hast natürlich Recht. Der Fauxpas ist korrigiert oben.

Wichtig ist der "push "route 192.168.1.0 255.255.255.0" Befehl, denn der propagiert dein remotes lokales LAN hinter dem OpenVPN Server an den Client !
Dieses IP Netzwerk musst du unbedingt auf das von dir verwendete in der Konfig anpassen, das ist
klar !

Die virtuelle IP des Servers steht doch im Kommando "server 172.16.2.0 255.255.255.0" !!
Der Server nimmt sich immer selbst die niedrigste IP also die 172.16.2.1 !

Wenn du mit dem OpenVPN Client verbunden bist und in der Windows Eingabeaufforderung einmal ipconfig eingibst siehst du die IP Adressierung des VPN tun Adapters.
Die Eingabe von route print zeigt dir ob der push Befehl sauber am Client ausgeführt wurde, denn dort steht dann eine Route zu deinem remoten Netzwerk via OpenVPN tun Adapter !
Das hat den Riesenvorteil bei OpenVPN das man damit alle remoten Netze an den Client dynamisch propagieren kann, auch solche die am VPN Server Standort über Router oder L3 Switches getrennt sind.
Frickelei mit statischen Routen am Client entfällt so komplett bei OpenVPN !

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 ?

Mmmhhh, der Client "dahinter" hat ja vermutlich den OpenVPN Server Router als default Gateway eingetragen...oder ??
Eine statische Route ist dann da natürlich überflüssig, denn das Netz ist ja direkt an ihm sebst dran.
Dein Problem ist vermutlich (wie immer in diesen Fällen..) die Firewall dieses Clients.
Wie du ja weisst blockt diese alle Connect und Ping Versuche aus Fremdnetzen. Sie lässt lediglich Zugriffe aus dem lokalen Netzwerk zu !!
Du musst also in jedem Falle den Bereich dieser Firewall anpassen.
Außerdem solltest du checken ob Pingen überhaupt erlaubt ist an dem Client.
Dazu muss in den erweiterten Eigenschaften der Firewall der Haken bei " Auf eingehende Echoanforderungen antworten" in jedem Falle gesetzt sein !!

Außerdem solltest du unbedingt beachten, das dein remoter Client und das lokale Netz sowie das virtuelle Open VPN Server IP Netz in unterschiedlichen IP Netzen liegen, die sich nie überschneiden dürfen.
Es gelten die "goldenen VPN Regeln" wie du sie hier nachlesen kannst:
VPNs einrichten mit PPTP

Generell funktioniert dieses Design vollkommen problemlos. Mit den obigen Regeln sollte es auch bei dir so sein !!

Hallo,
Du warst schneller wie ich! Klar es war die lokale Firewall ICMP Anfragen werden geblockt, irgendwann sollte man mal Pause machen sonst sieht man den Wald vor Bäumen nciht mehr.
Super Danke für die Unterstützung !!

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

Mach die im Tutorial angesprochene SSH Verbindung auf den OpenWRT mit Putty, wechsel ins Verzeichnis /tmp/openvpn/ mit dem Kommando cd /tmp/openvpn/ und dann gibst du ein ls -l und checkst mal ob deine Datei key.pem dort im Verzeichnis steht.
Wenn sie da nicht steht ist die Fehlermeldung klar !! Dann musst du den Serverkey nochmal importieren. Die Datei key.pem muss dort im Verzeichnis stehen ! Möglich ist auch das du den falschen keyfile importiert hast, denn scheinbar stimmt auch das Passwort mit dem CA Key nicht überein. Ggf. müsstest du alle Keys gem. dem o.a. Tutorial nochmal sauber generieren !
Ggf. postest du mal den ls-l Output.

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

kann mir bitte jemandem helfen, ich bin ratlos

Tutorial ist um eine Schnellanleitung zum Key erzeugen unter Windows ergänzt !

Hey, erstmal Danke für die Anleitung!

jedoch wenn ich SPI deaktiviere, sind alle ports von ausen sichtbar....

Wie und wo muss der iptables Eintrag erfolgen, damit nur vpn erreichbar ist?

greetz
Marco

Du blockst mit einer Accessliste alles was nicht UDP 1194 (OpenVPN Standardport) ist von außen !
NAT ist aber immer noch aktiv, so das ein Zugriff auf dein internes LAN nicht möglich ist !

Hallo ,
ich verwende für die Zertifikate XCA zun erstellen. Den meinsten Beginnern fällt die Erstellung mit einer GUI am Anfang einfacher. Einfach danach ein Export und im Editor öffnen, drag and drop und im Router einfügen!

Stimmt, das ist ggf. für den einen oder anderen Anfänger eine Erleichterung. Das Programm gibt es hier zum Download:
http://sourceforge.net/projects/xca/
Ein paar Screenshots sieht man hier:
http://www.softpedia.com/progScreenshots/XCA-Screenshot-74141.html

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

Hast du die Dateirechte im Key Verzeichnis einmal gecheckt ??
Ansonsten musst du die Schlüssel als ASCII Text über das Web Interface importieren. Wenn du FTP oder SCP benutzt musst du aufpassen den Binary Mode zu benutzen !
Ansonsten kann nur was bei deiner Key Erzeugung schief gegangen sein. Hast du das normal über die Eingabeaufforderung des OpenVPNs unter Windows oder Linux gemacht ??

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.

Was dort stehen muss kannst du im Tutorial oben nachlesen es ist entsprechend aktualisiert !
Ein kurzer Test mit für dich generierten Schlüsseldateien verlief vollkommen problemlos !! Du hast also de facto etwas beim Generieren der Schlüssel oder deren Import in die Eingabemasken der DD-WRT Konfig falsch gemacht !
Hier sind für dich die Schlüssel zum ausprobieren, damit funktioniert es fehlerfrei !

Public Server Cert, ca.crt Datei:

Public Client Cert, server.crt Datei

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=DE, ST=Agu, L=Aguhausen, O=Private, CN=aguserver/emailAddress=agu96@agu96.de
        Validity
            Not Before: Apr  2 09:52:17 2010 GMT
            Not After : Mar 30 09:52:17 2020 GMT
        Subject: C=DE, ST=Agu, O=Private, CN=aguserver/emailAddress=agu96@agu96.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c1:41:12:09:9a:2e:38:0b:ba:c2:bc:fb:57:5b:
                    b5:e9:7b:40:ec:8c:20:cf:be:6b:04:08:ff:aa:c2:
                    03:f0:b3:88:65:18:c6:ad:f1:ad:64:2d:82:7d:53:
                    61:f8:11:64:b1:09:92:fc:d4:ab:64:75:c2:be:91:
                    27:a1:ef:25:dd:a0:b1:26:f4:86:32:f9:f8:f8:af:
                    97:1a:a1:e6:61:80:52:51:5a:8d:31:6f:de:9d:43:
                    2e:98:06:ef:d0:ae:60:72:cc:ca:36:32:a3:14:34:
                    04:b1:81:9c:39:18:b8:95:bf:cf:0e:e3:fb:eb:aa:
                    c9:29:6c:2a:b4:ab:3e:39:1b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            Netscape Comment: 
                OpenSSL Generated Server Certificate
            X509v3 Subject Key Identifier: 
                8F:C2:94:A1:E2:53:2D:C7:E0:22:BE:EE:5D:0A:41:CE:59:C5:CB:68
            X509v3 Authority Key Identifier: 
                keyid:6E:21:79:72:7D:17:E9:EC:C4:43:9B:EB:E3:05:AA:CA:CC:38:4A:31
                DirName:/C=DE/ST=Agu/L=Aguhausen/O=Private/CN=aguserver/emailAddress=agu96@agu96.de
                serial:D7:25:C0:75:01:7B:3E:B5

    Signature Algorithm: md5WithRSAEncryption
        16:33:6a:41:ef:17:36:fb:6b:83:23:f4:d1:c8:5a:2a:12:ec:
        29:a6:52:51:41:ff:31:f2:d0:0c:7e:8c:3f:08:79:d1:42:3e:
        bf:9c:90:61:32:bc:72:e9:59:d2:b6:a4:54:86:61:26:59:d2:
        d2:da:56:be:b9:02:91:45:7d:58:99:e1:85:48:2c:ed:29:8b:
        11:94:23:2e:69:81:22:aa:81:04:00:df:9b:eb:b1:7d:95:c3:
        28:8e:a9:1b:47:e8:72:ba:ed:21:29:75:11:4f:7d:5c:e6:0e:
        2a:11:76:fd:1e:6d:72:40:93:11:64:ca:8a:dd:e5:34:13:e9:
        02:fc
-----BEGIN CERTIFICATE-----
MIIDazCCAtSgAwIBAgIBATANBgkqhkiG9w0BAQQFADB0MQswCQYDVQQGEwJERTEM
MAoGA1UECBMDQWd1MRIwEAYDVQQHEwlBZ3VoYXVzZW4xEDAOBgNVBAoTB1ByaXZh
dGUxEjAQBgNVBAMTCWFndXNlcnZlcjEdMBsGCSqGSIb3DQEJARYOYWd1OTZAYWd1
OTYuZGUwHhcNMTAwNDAyMDk1MjE3WhcNMjAwMzMwMDk1MjE3WjBgMQswCQYDVQQG
EwJERTEMMAoGA1UECBMDQWd1MRAwDgYDVQQKEwdQcml2YXRlMRIwEAYDVQQDEwlh
Z3VzZXJ2ZXIxHTAbBgkqhkiG9w0BCQEWDmFndTk2QGFndTk2LmRlMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDBQRIJmi44C7rCvPtXW7Xpe0DsjCDPvmsECP+q
wgPws4hlGMat8a1kLYJ9U2H4EWSxCZL81KtkdcK+kSeh7yXdoLEm9IYy+fj4r5ca
oeZhgFJRWo0xb96dQy6YBu/QrmByzMo2MqMUNASxgZw5GLiVv88O4/vrqskpbCq0
qz45GwIDAQABo4IBHzCCARswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAw
MwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIFNlcnZlciBDZXJ0aWZp
Y2F0ZTAdBgNVHQ4EFgQUj8KUoeJTLcfgIr7uXQpBzlnFy2gwgaYGA1UdIwSBnjCB
m4AUbiF5cn0X6ezEQ5vr4wWqysw4SjGheKR2MHQxCzAJBgNVBAYTAkRFMQwwCgYD
VQQIEwNBZ3UxEjAQBgNVBAcTCUFndWhhdXNlbjEQMA4GA1UEChMHUHJpdmF0ZTES
MBAGA1UEAxMJYWd1c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5hZ3U5NkBhZ3U5Ni5k
ZYIJANclwHUBez61MA0GCSqGSIb3DQEBBAUAA4GBABYzakHvFzb7a4Mj9NHIWioS
7CmmUlFB/zHy0Ax+jD8IedFCPr+ckGEyvHLpWdK2pFSGYSZZ0tLaVr65ApFFfViZ
4YVILO0pixGUIy5pgSKqgQQA35vrsX2VwyiOqRtH6HK67SEpdRFPfVzmDioRdv0e
bXJAkxFkyord5TQT6QL8
-----END CERTIFICATE-----

Private Client Key, server.key Datei

DH PEM, dh1024.pem Datei

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP1rvTSiJeCzmGqexXkslR8qRq05H+fl553r9epOgLW/Ecog8J1V2was
hpzVb4wa0XMcyrowHmIeC7Lxfzldm0R1sUsaj1SKlIfLDXZ790zB4Z591H6gvcym
W8n5fTB77anwkICPoAH9nXIf3pIKztUXchv8lNrkidtzcLwp6tqrAgEC
-----END DH PARAMETERS-----

Server Konfigurations Datei. DD-WRT Router hier mit 192.168.1.1 als LAN IP Adresse:

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.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

Damit funktioniert die Initialisierung einwandfrei und ohne Fehler ! Du kannst diese Daten einfach per cut and paste nutzen
Den gesamten Schlüsselsatz inklusive 3er Client Schlüssel zum Testen kannst du dir HIER runterladen !
Die dazu passende Client Konfig für einen Windows OpenVPN Client ist hier:

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server (DD-WRT Router WAN IP).
# You can have multiple remote entries
# to load balance between the servers.
remote 192.168.100.161 1194
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to 
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use 
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt
cert C:/Programme/OpenVPN/easy-rsa/keys/aguclient1.crt
key C:/Programme/OpenVPN/easy-rsa/keys/aguclient1.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an 
# important precaution to protect against
# a potential attack discussed here:
#  http:{{comment_single_line_double_slash:0}}
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server  
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also  
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

Achtung: Bedenke aber bitte das dieser Key für den späteren Betrieb nun unbrauchbar ist, da er jetzt öffentlich ist. Du musst also die Schlüsselgenerierung nochmal neu anstoßen um einen für dich einzigartigen Schlüssel zu bekommen !!

Wenn du mit dem Client erfolgreich eine Verbindung aufgebaut hast, dann kannst du mit ipconfig am Client die Server IP Adresse des OpenVPN Servers sehen !
Ein route print zeigt dir die propagierte Route zum 192.168.1.0er Netzwerk (Client darf dazu natürlich NICHT auch im 192.168.1.0er Netz sein !!!)
Ein Ping auf die 192.168.1.1 also die LAN IP Adresse des DD-WRT Routers sollte dir dann eine Antwort bringen und zeigen das der OpenVPN Tunnel aktiv ist !!

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

Hallo aqui,
gibt es die Möglichkeit bei DD-Wrt mit pkcs12 Dateien zu arbeiten, sprich nicht die Zertifikate aso. in das Webfrontend zu kopieren, sowie die anderen Files ?
Wenn ja, wie ?

Danke für Deine Hilfe

Gruß schöne Ostern !

Eigentlich sollte das auch problemlos klappen, denn es ist ja ein Standard OpenVPN was auf den Routern arbeitet ! Vermutlich muss man die entsprechenden pkcs Dateien dann nur einfach mit SCP sprich WinSCP usw. manuell auf den Router übertragen, denn in der Standardkonfig im Menü gibt es dafür keine Felder, was aber ja kein Hinderungsgrund ist.
Technisch spricht nichts dagegen....wäre in der Tat mal einen Test wert !
Wenns klappt wird das Tutorial ergänzt... !

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.

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ß

Mmmhhh, WO hast du denn dieses Zertifikat hinkopiert ??
Normalerweise gehören sie unter /tmp/openvpn Es ist aber möglich das dieses Verzeichnis bei einem Klick auf den SAVE Button unter DD-WRT nicht mit im Flash gesichert wird sondern sich diese Zertifikate und Conf Dateien in einem mit Flash gesicherten anderen Datei Bereich befinden und dann beim Systemstart mit cp ins Verzeichnis /tmp/openvpn/ temporär kopiert werden, wie es bei OpenWRT der Fall ist Siehe #comment-toc7 hier.
Das sollte sich ja mit einem find / -name <datei> schnell finden lassen. Ggf. solltest du die OpenVPN init Start Dateien unter /etc/rc.d/ einmal checken.
Es ist auch möglich das die Daten unter /tmp/openvpn erst mit einem Klick auf Save in der DD-WRT Oberfläche gesichert werden im Flash und du das nur schlicht und einfach vergessen hast...
Gut aber zu wissen, das der PKCS12 Support generell sauber funktioniert !! Danke für den Test !

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>

Mmmhhh, dann bleibt also nur basteln:
http://www.dd-wrt.com/wiki/index.php/Tutorial:_Hinzuf%C3%BCgen_eines_SD ...
oder immer wieder manuell die Datei zu übertragen was allerdings nicht sehr betriebssicher ist..klar.
Danke fürs Feedback ! Bleibt dann also mehr oder weniger bei den Zertifikaten sofern man nicht wie oben beschrieben die SD Karte nachrüstet was ja nicht besonders schwer klingt zumal der SD/MMC support schon per default in den aktuellen Images enthalten ist...
Hast du dir mal Pfsense angesehen ?? Ist es dort ggf. anders gelöst ?? Sollte eigentlich. Das wäre ja dann die Alternative für PKCS12 !

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.

@christianW
Dann mal her mit dem HowTo ! Ggf. können wir das ins Tutorial oben einfügen sofern du zustimmst !

So, eben zusätzlich mal kurz den Lötkolben geschwungen und eine SD_Kartenfassung zur Hand genommen und sie nach Anleitung in den WRT54GL eingelötet.
Man sollte unbedingt der englischen Anleitung folgen denn die bezieht sich auf das aktuelle Platinenlayout:
http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54G-TM_SD/MMC_mod

Eingeschaltet und die SD Karte (Transcend 2GB) im Setup aktiviert, die dann schon sofort auf Anhieb erkannt wurde:

Dann den Router kaltgestartet daraufhin flackert die SES LED vorne und nach ca.1 Minute ist die Karte automatisch formatiert et voila...

Ein kurzes "dmesg" bzw. "df" an der Konsole zeigen das sie auch aktiv ist:

[INF] mmc: Version: 2.0.1 Parms: major=0 din=2 dout=4 clk=3 cs=7 maxsec=32 rahead=2
[INF] mmc: SD Card detected & initialized
[INF] mmc: Assigned dynamic major number 254
Partition check:
mmca: p1
[INF] mmc: Module loaded
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

root@DD-WRT:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2816 2816 0 100% /
/dev/mmc/disc0/part1 1898464 14 1801988 0% /mmc
root@DD-WRT:/#

Ebenso unter der Status Anzeige im Web Setup:

Hier ein paar Bilder vom Einbau:
An die GPIO Ports und Stromversorgung angelötete Kabel:

SD zu Micro SD Adapter vor dem Einlöten: (Sorry für die Unschärfe)

Mutige können hier die SD Karte auch direkt einlöten ! Die Karte ist robust genug das sie das aushält.

Fertige SD Karte im Gehäuse mit Heisskleber fixiert: (Nochmal sorry für die Unschärfe)

OpenVPN Dateien und auch die PKCS12 Zertifikate lassen sich problemlos dahinkopieren und auch davon benutzen !!
Bei entsprechender HW kann man die SD Karte sogar per CIFS als Share im netz freigeben und bequem vom Rechner beschreiben.

Fazit: Mit der englischen Anleitung zur Integration einer SD Karte ist diese in ca. 30 Minuten ebenfalls im System installiert...mit ein bischen löten

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 ?

Was übrigens sehr gut geht ist ein SD zu micro_SD_Kartenadapter zu verwenden der immer zusammen kostenlos mit micro SD Karten mitgeliefert wird aber auch einzeln sehr preiswert erhältlich ist. Dort kannst du die Drähte problemlos direkt auflöten und hast somit gleichzeitig eine sichere Halterung und kannst bei Befarf den Speicher vergrößern.
Man erspart sich so den Kauf einer teuren SD Fassung (z.B. Reichelt) und kann die übrig gebliebenen SD zu micro SD Adapter prima recyceln !
Den Adapter kann man dann direkt mit Heisskleber ins Gehäuse kleben, micro SD Karte rein...fertig

Habe 3 WRTs jetzt so auf 2 GiG SD Karten umgerüstet und hat auf Anhieb geklappt mit der DD-WRT SW vom Februar (Siehe Tutorial) !

Die Konfig zu editieren ist ein Kinderspiel. DD-WRT hat den Klassiker aller Editoren, den vi Editor an Bord ! Ist zwar etwas gewöhnungsbedürftig der Editor aber zum Konfig Datei editieren reicht es vollkommen ! Anleitungen zur Bedienung des vi findet man zuhauf bei Dr. Google.
Einfach dann Zertifikate usw. ins Verzeichnis /mmc kopieren (Das ist die SD Karte !) und die Konfig Dateien unter /tmp/openvpn mit dem vi anpassen.
OpenVPN neu starten oder einfach Router rebooten...fertig !

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 ?

Mmmmhh, es ist möglich das der Startbefehl beim Booten mit einem Default überschrieben wird aus dem Flash. Hast du das mal nach dem Booten kontrolliert ?? Ist der Startbefehl noch so wie du ihn verändert hast.
Ggf. wird das JFFS Filesystem auch erst nach dem OpenVPN Start gemountet so das es deshalb fehlschlägt

Bitte die weitere Diskussion per PM weiterführen um das Tutorial hier nicht zu doll aufzublähen...

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)...

Antwort per PM gesendet.... Vermutlich falscher Modus in WinSCP eingestellt. Eine Übetragung sollte immer per cut and paste in das Web Interface des Routers gemacht werden !
Alle Key Dateien sind mit einem einfachen Editor wie z.B. dem Windows Word Pad (unter Zubehör) edierbar und dort kann man sie mit cut and paste aus übertragen.

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?

Wie sieht dein Netzdesign aus ?? So:

Hast du das "push" Kommando in der Konfig für das LAN-2 angegeben ??
Was sagt ein "route print" am Client bei aktiver VPN Verbindung ??

@ aqui

Nein, der OpenVPN Router hängt per LAN (nicht WAN) am Lan1 auch alle anderen Geräte.

Er soll so zusagen als reiner OpenVPN Server laufen.

Ist der Internetrouter auch gleichzeitg für die Rechner DHCP und/oder DNS Server?
Das würde bedeuten das alle Anfragen der Clients Gateway an den Internetrouter weitergereicht werden.
Ich denke dieser kennt allerdings die Route nicht zurück ins VPN Lan.
Static Route in den Internetrouter eingetragen ?

@ 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?

Nein, was christianW zu Recht meint ist eine statische Route auf dem Internet Router zum OpenVPN Server für das VPN Clientnetz ! Das ist ja ein anderes IP Netz als dein lokales ! Wenn du nun von einem VPN Client einen rechner in deinem lokalen netz anpingst "sieht" der als Absender IP Adresse aus deinem VPN Netz !
Diese lokalen Rechner haben aber alle den Internet Router als default gateway eingetragen, routen also das Antwortpaket an den Internet Router und dann ins Internet wo es auf Nimmerwiedersehen verschwindet !!! Es muss ja zum OpenVPN Server !!
Du ahnst die Lösung und christianWs richtigen Einwand mit der Route...oder ??
Statische Route aufs VPN Client Netz via Open VPN Server !
Angenommen dein lokales Netz ist die 172.16.1.0 /24, der VPN Server hat die 172.16.1.254 und dein VPN Clientnetz ist die 10.16.1.0 /24 dann muss auf deinem Internet Router eine statische Router ala:
Zielenetz: 10.16.1.0, Maske: 255.255.255.0, Gateway: 172.16.1.254
Damit routet der Internet Router das Antwort Paket dann an den OpenVPN Router und der packt es in den VPN Tunnel und schiebt es wieder zum Client und alles ist gut !!

Hallo DonJoe.
ja genau wie Dir das aqui beschrieben hat, meinte ich dies.

PS. aqui irgendwie namen verwechselt ;)

Ooops...sorry...schnell heimlich korrigiert

@ aqui

Jetzt habe ich wohl ein Problem, da meine EasyBox 802 keine statische Route unterstützt, zumindestens das was ich ergooglet habe.

dann leg sie auf einer Workstation an und test dann mit dieser Workstation. Wenns geht bleibt Dir die Möglichkeit, das auf jeder Workstation zu tun, allerdings auf Netzwerkressourcen wie Printserver kommst Du nicht, die benötigen eine Route und das geht nur mit einem Router

Ja, christianW liegt da richtig ! Das beste ist du schmeisst den Router weg und beschaffst dir was anständiges. Ansonsten hast du nur den mühsamen Workaround auf allen Endgeräten eine eigene statische Route ala:
route add <Zielnetz> mask <Maske> <Gateway_IP> -p
nachzutragen (Syntax für Windows Maschinen !).
Für Endgeräte die sowas nicht können fällt die VPN Verbindung dann flach !

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!

Ja, das klappt natürlich problemlos. Du annouced mit der o.a. Konfig für die Clients ja nur die beiden remoten Netze zur Zentrale, mehr nicht.
D.h. nur diese Netze sind in der Zentrale bekannt und aus Sicht der remoten netze ist denen nur das Zentral netz bekannt NICHT aber das jeweils andere remote Netz.
Folglich ist ein Routing der beiden remoten Netze untereinander technisch nicht möglich. Erst mit einer zusätzlichen statischen Route im Zentralrouter wäre ein Routing zwischen den remoten Netzen möglich. Ohne diese Route ist es wie gesagt nicht möglich.
DHCP Requests in einem VPN zu forwarden ist eigentlich Unsinn, denn damit zwingst du die remoten Netze in eine zentrale Abhängigkeit von Servern in der Zentrale und machst sie zudem Abhängig von der 100%igen Verfügbarkeit der WAN Verbindung.
Generell ein sehr schlechtes VPN Design, denn die remoten Lokationen sollten ja möglichst auch bei Ausfall zentraler Komponenten autark weiterarbeiten könne. Mit z.B. einem zentralisierten DHCP Konzept ist das abe rnicht gegeben. Davon sollte man also tunlichst die Finger lassen wenn möglich !
Dennoch kann man aber mit der server.conf Datei auch solche Pakete forwarden wenn man es denn unbedingt muss.

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

Das Log sieht OK aus ! Dort ist keine Error Meldung zu sehen. Vermutlich ist die beim cut and Paste verlorengegangen. Sende deine Client und Server Konfig Datei einmal per PM um das Tutorial hier nicht so aufzublasen !
<edit>
Der Falke hatte FB und DD-WRT Router falsch zusammengesteckt. Nun ist alles richtig und es funktioniert wie es soll !
Das Tutorial wird auf ein Kapitel erweitert wenn der VPN Router hinter einem bestehenden Router betrieben wird um weitere Fragen für so ein Szenario zu beantworten !
</edit>

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?

Ja das geht problemlos. Du musst nichtmal die Route statisch eintragen, sondern kannst sie mit einem weiteren
push "route 192.168.1.0 255.255.255.0"
Kommando in der Server Konf. Datei automatisch an den Client weitergeben.
Wenn du bei eingewähltem (Windows) Client dann ein route print eingibst siehst du beide Routen zum jeweils 172.16.2er und 192.168.1er Netz via OpenVPN Tunnel in der Routing Tabelle !
Vorsicht ist allerdings geboten am WAN Interface. Dort wird in der Regel NAT gemacht und Antwortpakete von Endgeräten aus dem 192.168.1er Netz bleiben bei aktivem NAT an der WAN-Port NAT Firewall hängen.
Bei DD-WRT klickt man dann im System Setup einfach den "Router Modus" an um das NAT auszuschalten und transparent zu routen. Bei pFsense richtet man eine statische NAT 1:1 Translation ein und gut ist.
Damit lässt sich das problemlos auf beiden Plattformen umsetzen !

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

Der Tip ist technisch richtig, allerdings sehr umständlich, denn dieser Floppystecker ist viel zu dick und zu klobig und damit sehr unpraktisch im Gehäuse unterzubringen..
Einfacher und besser ist für ängstliche Löter einen mini SD auf SD Konverter zu nehmen und den einzulöten und dann eine mini SD einzustecken.
Nötig ist das aber nicht. Die SD Karte verträgt es auch ohne Probleme wenn man die Kabel direkt an sie anlötet.
Das ist einfacher, kostet nicht so viel Platz und ergibt später einen sicheren Dauerbetrieb ohne Wackelkontakte durch Steckverbindungen !

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 ^^.

OK, Dank für den Hinweis. Sollen die User dieser o.a. Lösung halt selbst entscheiden

Jetzt habe ich es endlich geschafft. Danke für die tolle Anleitung.

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

Hallo zusammen

Aqui danke für das How-To! auf dem Client-Rechner sollten doch die ca.crt, client.crt und client.key vom Server in den OpenVPN Ordner kopiert werden. Leider aber weiss ich nicht wo ich die client.crt finde?

kann mir da jemand helfen?

Danke im voraus

Für PF Sense: Unter System > Cert Manager > Certificates kannst du dir für einen Client ein Zertifikat machen. Wenn du es erstellt hast, kannst du dir das Zertifikat und den Key exportieren.

Einen DD-WRT Router hab ich jetzt keinen bei der Hand.

@Jon
DD-WRT hat keinen Key Generator an Bord, dort muss man dies extern machen wie im Turorial beschrieben.
Hast du dein TLS Auth Problem von oben gelöst ? Du musst da auch nur diesen Key exportieren.

@shadow1
Wenn du das o.a. Tutorial aufmerksam liest findest du unter der "Installation auf pfSense" dort oben unter Punkt 3 und 4 bei der Installation der Keys die Info das das über die Export Buttons ganz rechts im Key Menü exportiert werden kann.
Springt einem auch gleich ins Auge. Bewege einfach den Mauszeiger über die Buttons dann erkennst du den Export Button im Handumdrehen über sein automarisches Kontext Menü

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

Doch, das Tutorial beschreibt auch wie man die Client Zertifikate im Certificate Manager einrichtet und exportiert. (Schritt 2 und 3 der pfSense Installation !)
Du kannst das auch immer mit der OVPN Client SW direkt machen oder mit dem XCA Programm wie es oben im Abschnitt "Zertifikate und Schlüssel" ja detailiert beschrieben ist ! Im onboard Certificate Manager ist es aber einfacher, da dort weniger Fehler bei der Erzeugung passieren !
Dein Problem ist der TLS Key den du nicht exportiert hast.
Bitte schicke weitere Infos per PM um das Tutorial hier nicht weiter aufzublähen. Wir posten dann die Lösung !

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

Leider ist deine Schilderung WAS du genau vorhast hier sehr konfus so das eine zielgerichtete Hilfe schwer ist

Hier nochmal genau die Fakten:

Der OpenVPN Server auf dem Router ist ein eigenständiger VPN Server !
Die interne IP Adresse des VPN Servers (im Konfig File oben: server 172.16.2.0 255.255.255.0 ) darf NICHT im weiteren Netzwerk vergeben sein. IP Adressen müssen im Netz einzigartig sein !
Der Client bekommt am VPN Interface auch diese IP also muss sie clientseitig auch einzigartig sein und es gelten die Regeln für das IP Adressdesign im letzten Kapitel des o.a. Tutorials ! Bitte lesen !!

So das vorweg...
Du schreibst nun:
...VPN eine Verbindung aufbauen von meinem Rechner zu einem Server in einem anderen Netz.
OK das würde dem obigen Vorschlag widersprechen, das dein VPN Server eben NICHT auf einem Router integriert ist sondern ein dedizierter Server irgendwo in einem anderen Netzwerk Segment ?! Leider keine detailierte Info von dir dazu...

...der Router(Linksys) zeigt mir die WAN IP: 192.168.115.250 an.
Das wäre einen private RFC 1918 IP und spricht dafür das dein WAN Port dieses Routers entweder in ein lokales Netzwerk integriert ist oder hinter einem bestehenden Internet Router steht.
Desweiteren sagt es nichts darüber aus ob dieser Router NAT (Adress Translation) macht oder nicht.
Desweiteren nicht ob dieser Router der VPN Router ist oder ob du diesen nur überwinden musst mit Port Forwarding (NAT) um den VPN Server zu erreichen den du oben ansprichst. Also auch verwirrend hier was du vorhast bzw. WIE dein VPN Design aussieht ?!

...Habe es so verstanden das der "Server" des DD-WRT Routers eine andere addresse bekommt
Ja, das ist generell so richtig. Der OVPN Server benutzt für den VPN Tunnel eine eigene IP die NICHT anderswo im Netz vorkommt. Das Kommando server 172.16.2.0 255.255.255.0 bestimmt diese IP in der Server Konfig Datei wie es oben auch explizit im Tutorial beschrieben ist (bitte lesen !!).
Bei dir wäre das dann entsprechend server 192.168.201.0 255.255.255.0. Die .1 ist keine netzwerk Adresse sondern eine Hostadresse wie du ja selber weisst, deshalb ist die .1 Blödsinn in der Konfig !

Da du nicht präzise beschreibst WIE dein VPN Design aussieht ist die Antwort auf deine Frage ob du einen Denkfehler machst nicht einfach. Die Vermutung sagt JA
Deine Router Settings sind soweit OK und passen. Eine Beispiel Server Konfig Datei für deinen Router sähe z.B. so aus:
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 192.168.201.0 255.255.255.0
push "route 192.168.200.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Der Knackpunkt ist die RFC 1918 IP am WAN Port deines Routers. Das zeigt das dort eben nicht das Internet dran ist sondern noch was davor hängt.
Insofern macht es also Sinn wenn du den Begriff "...großes LAN" einmal etwas präzisierst hier !

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

Nein, da ist ein schlimmer Fehler !! Bitte das Tutorial GENAU lesen Thema "Client Installation" !!
Mit "realer IP" ist immer die physische Port IP des Routers gemeint !
...Im Client der auf den OVPN Server connecten soll steht "remote 192.168.201.1 1194" !
Das ist natürlich Blödsinn wenn man das Tutorial mal richtig liest. Das .201er Netz ist das Tunnel interne Netz was du ja von außen gar nicht verbinden kannst. Der Client "sieht" doch logischerweise nur die erreichbaren physischen IP Netze also muss er sich auf die 192.168.115.250 verbinden, denn DAS ist doch die für ihn erreichbare VPN Server IP.
Folglich muss dort logischerweise remote 192.168.115.250 1194 stehen.
Stelle also sicher das du von den Clients also den Server mit dem OVPN Client den du verbinden willst diese IP anpingen kannst oder erreichen kannst (Achtung: dd-wrt lässt in den Security Settings per Default kein Ping zu wenn du das nicht testweise mal aktivierst !)
Da der Server ja im gleichen IP Netz wie der WAN Port ist wie du beschreibst sollte das kein Problem sein. Fragt sich dann allerdings was dann der tiefere Sinn eines VPNs in so einem Konstrikt sein soll, denn über öffentliche und unsichere Netze gehst du dann ja gar nicht ?! Na ja egal erstmal...
Der Rest sieht gut und richtig aus !
Check mal die Logs im Client und auch im Server (dd-wrt Router) dort siehst du entsprechende Meldungen wenn der SSL Tunnel aufgebaut wird !

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 ??
<Zitat>
...ich habe einen Router an einem großen LAN Netzwerk der Router(Linksys) zeigt mir die WAN IP: 192.168.115.250 an.
</Zitat>
Das schreibst du also selber !! Die WAN IP ist doch genau die, die der VPN Client "sieht" und auch erreichen kann !!

Fix also erstmal dein ca.crt Problem !! Ohne das geht eh gar nix...
Nochmals: Bitte halte dich an die Troubleshooting Anweisung oben im Tutorial die unter der Rubrik: Ist der OpenVPN Server aktiv ?! steht !!

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.

Hallo Fronbot
OK, danke für die Klarstellung. Damit ist das Design ja aber dann ein klassisches VPN Design um OpenVPN auf dem DD-WRT zu testen und sollte, wenn man dem obigen Tutorial folgt, auch ohne Probleme von chaotize zum Fliegen zu bekommen sein. Das obige .115er Test IP Netz simuliert sozusagen dann das öffentliche Netz !
Das klassische Testszenario in dem oben beschriebenen Umfeld sähe dann so aus:

Was die ca.crt Problematik anbetrifft ist es möglich das ggf. beim Cut and Pasten ins WebGUI ein Fehler passiert ist oder das Zertifikat vorher mit einem Windows Editor angesehen wurde der zusätzliche Zeichen dort reingebracht hat.
Es ist aber auch ganz einfach den ca.crt File ohne das GUI auf den Router zu bringen, was auch oben im Tutorial genau beschrieben ist.
Dazu schaltest du einfach den SSH Zugang auf den Router frei so das man auch z.B. mit PUTTY auf die Konsole des Routers zugreifen kann.
Analog kann man dann auch mit WinSCP:
http://winscp.net/eng/docs/lang:de
genau so auf den Router zugreifen und damit dann einfach per Drag and Drop den ca.crt File auf den Router kopieren ! Generell kann man so mit dem WinSCP Tool jegliche Dateien auf einen SSH Unix Rechner kopieren.
Das ist eine Sache von 3 Minuten. Mit ls -l kann man sich das dann am Unix Kommandoprompt schnell ansehen und chaotize lernt noch etwas Unix nebenbei und muss nicht als Winblows Knecht enden

So funktioniert es auch ohne GUI ganz sicher.
Wie eine zielgerichtete Fehlersuche funktioniert ist oben ja auch beschrieben.
Einen eigenen Thread aufzumachen macht aber Sinn, denn das bläht dieseAnleitung dann nicht so auf.
Wir werden ihm dann schon zu einem bestens funktionierenden OVPN Server auf dem DD-WRT verhelfen !!
Wie man den dann fehlenden DD-WRT Router im Gäste WLAN ersetzt kannst du hier nachlesen

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

Musst du dich nicht für entschuldigen. Wenn dein Spezialgebiet Sportangeln ist, ist das doch verständlich... und für solche Fragen ist ein Forum ja da.
Wenn du noch Fragen zu dem Thema haben solltest per PM oder mach einfach einen Thread auf.

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

Ganz klar ist deine Fragestellung nicht. Was meinst du mit dem "Client" Screenshot, diesen hier:

Letztlich hast du nicht ganz Unrecht, denn die Frage remote Access oder P2P ist Client Access und Lan2Lan und definiert die weitere Vorgehensweise sofern man das Setup Menü benutzt.
Man kann es aber auch "zu Fuß" machen gerade wenn man die Einstellungen customized.
Bitte nichttechnische Fragen per PM, da wir sonst das Tutorial unnötig aufblähen.

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.

OK, ich check das. Aktuell ist die Version 2.0.2 und wenn dort Menüpunkte verändert sind dann pass ich das Tutorial an.
"Client to Client" bedeutet hier das bei einem remote Dialin VPN auch die Clients untereinander kommunizieren können. Will man das nicht muss man den Haken entfernen.
Was die IP Adressen betrifft ist das OK. OVPN nutzt PPP Verbindungen mit einer 32 Bit Maske (ffffffff) für jede einzelne Client Connection. Daher kommen diese Multiplen IP Adressen. Man kann das aber umkonfigurieren wenn man will sollte man aber nicht da das ggf. Nachteile nach sich ziehen kann.

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.

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 !
Dank auch für den XCA Hinweis. Ich passe das Tutorial an !
Frage 2:
Ja, natürlich siehe:
http://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Das Kommando "push redirect-gateway..." Ist hier dein Freund !

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.

Zitat von @aqui:

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

Ob du als Client alles tunnelst kannst du mit den Route Kommandos entscheiden. Allerdings ist das sher knifflig, denn wenn du ein default Gateway im Tunnel hast muss zwangsläufig der Server das ja auch wissen. Wie sollte das sonst IP seitig gehen dann hättest du inkonsistente Routen auf beiden Seiten.
Hier fehlt dir wohl etwas Wissen vom IP Routing, kann das sein ?

Thema remoter Share Zugriff:
OK, wenn du den Computer im remoten Netzwerk nicht anpingen kannst ist es ja vollkommen logisch das es nicht geht ! Dann fehlt dir die gesamte IP Connectivity per se !
Ein beliebter Fehler ist der das dieser Rechner den du anpingst und auf dessen Share du zugreifen willst ein Gateway eingetragen hat das NICHT der OpenVPN Server ist !!
Damit kennt dieses Gateway dann die gesamten remoten Routen nicht und würde die VPN Netzwerke ins Internet routen !
Vermutlich ist genau DAS bei dir der Fall wenn der OVPN Server nicht auf dem Internet Router rennt sondern auf einem anderen Gerät im Netz ?!
Die Lösung ist dann kinderleicht, denn du musst dann lediglich auf diesem Router den der Rechner den du pingst und das Share hat als Gateway hat eine statische Route eintragen.
Da du rein gar nix zu deiner Netz Infrastruktur beschrieben hast kann man hier leider nur im freien Fall raten

Aber vermutlich ist das der Fehler wie immer hier.
Traceroute (tracert) und Pathping sind hier wie immer deine Freunde ! Da wo's kneift ist der Routing Fehler !
Ansätze sind in den User Threads hier ganz unten beschrieben:
OpenWRT Low Cost Router für LAN bzw. VLAN Routing inklusive OpenVPN Server

Hallo,

so habe das Problem gerade selber gelöst... es lag an meinen VLAN Routings, dass er den Weg zurück nicht mehr gefunden hat.

Vielen Dank trotzdem für eure Hilfe ;)

Siehste... ! Wieder den richtigen Riecher gehabt !
..alles wird gut

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:

# 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:

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 Spirit. Das ist falsch das die SPI deaktiviert werden muss. Ein Fehler im Tutorial das korrigiert ist. Mit deinem Einverständnis poste ich da die iptables Regeln.
Es funktioniert auch fehlerfrei mit aktivierter SPI Firewall.
Das Problem der Statusabfrage OVPN ist bekannt. Da scheint es einen Bug in der DD-WRT Firmware zu geben, denn das klappt hier auch nicht.

Du hast übrigens noch einen Kardinalsfehler in deiner OVPN Konfig ! Die Tunnel MTU darf niemals 1500 Byte betragen !
Daten werden in einen SSL Tunnel transportiert, der eine gewissen Overhead hat. Wenn nun auch noch dieser Tunnel über DSL übertragen wird kommt dort wieder ein Encapsulation Verfahren zu was die MTU weiter verkleinert.
Belässt du das auf 1500 Byte kann ein OVPN Paket nicht mehr sauber encapsuliert werden da die MTU dann größer werden würde als 1500 Byte was dann gegen den Ethernet Stzandard verstossen würde.
Ein Router oder OVPN Server würde solche fehlerhaften Pakete sofort droppen sprich löschen.
Damit erleidest du massive Retransmissions und große Performanceeinbrüche im VPN Tunnel.
Das solltest du also schnellstens korrigieren ! Die sollte 1492 keinesfalls überschreiten !! Siehe hier:
http://www.pronix.de/pronix-938.html

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

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:

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..???

Du mischst hier jetzt vermutlich aus Unwissenheit die Begriffe "Route" und "DNS" im freien Fall durcheinander !!
Das sind 2 unterschiedliche Baustellen, also bitte auch getrennt betrachten.

Eigentlich ist zu dem Thema alles im obigen Abschnitt "DNS Domain Integration" erklärt !
Generell kann auch der DNS Server mit Aktivieren der VPN Verbindung auf den Client gepusht werden:
http://openvpn.net/index.php/open-source/documentation/howto.html#dhcp

Das hat dann aber zur Folge das dieser Server dann der aktive DNS Server im Client ist wenn und solange die VPN Verbindung aktiv ist !
Generell ist das nicht falsch oder verkehrt, solange dieser DNS Server dann auch Internet Domain Namen auflösen kann, sprich eine lokale Weiterleitung hat dort wo er ist und Internet Domains auflösen kann.
Damit nutzt du dann zwar deinen lokalen DNS am Client nicht mehr, was aber nicht weiter schlimm ist, denn der VPN DNS Server gibt dir ja dann auch die korrekten Ziel IP Adressen zurück und das Routing geschieht dann wieder lokal.
Sprich also der Internet Traffic geht über deinen lokalen Link und nicht über den VPN Tunnel, denn das Client IP Gateway zeigt ja weiterhin auf den lokalen Router.
Natürlich nur wenn du nicht push "redirect-gateway def1" in der Server Konfig hast, also alles über den Tunnel schicken würdest, sondern dort nur dein lokales VPN Netz gepusht wird.
Die Funktionen nslookup und Traceroute auf dem Client sind hier wie immer deine besten Freunde !

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

So habe es nun über diesen Weg gemacht:

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.

Steht ja genau so auch in der Doku !

Den zusätzlichen DNS Traffic kann man wohl in bezug auf den gesamten Traffic leicht vernachlässigen. Wichtig ist eben das der remote DNS Server auch Internet Domains auflösen kann und nicht nur lokale !
Gut wenns nun so klappt wie es soll....!

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.

8.8.8.8 ist in der Regel unüblich für dynamische DNS Zuweisungen von Routern oder DHCP. Dort werden immer lokale DNS Server der Provider verwendet was ja auch Sinn macht und niemals der Google DNS Rootserver. Google selber ist zudem kein Provider gibt diese IP also nirgendwo dynamisch raus.
Fazit: Irgendwo hast DU selber diese IP statisch zugewiesen haben und von dort kommt es auch ! Dort musst du also graben und suchen, den der Google DNS gehört eigentlich nirgendwo hin, sondern immer der DNS des Hosters oder Providers.

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.

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.

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

Na ja bis auf Groß- Kleinschrift im letzen Satz ist doch alles OK...

Zurück zum Thema....
Soweit beschreibst du die Situation ganz richtig. Dein Problem ist lediglich eine fehlende Route...mehr nicht. Wenn du die einrichtest kommt auch die Kommunikation sofort zum Fliegen.
Das Problem bei dir ist das die Lokation B und auch die Lokation C die Lokation A routingtechnisch kennen aber B kennt nicht C und C auch nicht B weil die Routen dahin fehlen.
Folglich routen sie solche Pakete statt in den OVPN Tunnel zum Provider.
Was du ganz einfach machen musst ist den Clients bzw. am Server in der Konfig diese Routen zu konfigurieren. Damit "wissen" die Standorte B und C dann das sie das jeweils andere netz auch in den Tunnel routen müssen.
Wie das umzusetzen ist erklärt dieses OVPN Tutorial ganz genau:
http://community.openvpn.net/openvpn/wiki/RoutedLans
Damit sollte das dann problemlos funktionieren mit dem any zu any Routing !

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?

Muss diese mit Zielnetz übereinstimmen oder ist dies nur ein Logisches Netz?

Nein, das ist nur ein logisches IP Netz was im VPN Tunnel zw. VPN Client und VPN Server benutzt wird. Es darf nirgendwo sonst mehr im Netz auftauchen, MUSS also einzigartig sein wie die anderen IP Netze im gesamten Design auch !

Allerdings ist das 192.168.178.0 Netz trotz Push nicht erreichbar

Was sagt ein "route print" oder "netstat -r" auf dem VPN Client ?? Wird das Netz dort in der Routing Tabelle des Clients angezeigt ? Das müsste es wenn der Push Befehl richtig ausgeführt wird !! Das .179er Netz müsste dort ja auch stehen und es wäre unlogisch wenn das in der Tabelle wäre das .178er aber nicht, da beide Kommandos ja identisch sind ?!

Alternativ hatte ich auch schon den Router per WAN-Port verbunden

Das wäre aber der richtige Weg wenn du eine Router Kaskade betreibst wie im Tutorial im Kapitel VPN Router hinter NAT Router betreiben beschrieben ist !

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.

Du musst den ganz einfach in eins der Autostart Skripte bringen dann startet OVPN auch problemlos beim Booten ohne manuellen Eingriff !
Such einfach mal im DD-WRT Wiki oder bei Dr. Google es gibt tonnenweise Lösungen dafür wie z.B. diese hier:
https://www.tolaris.com/2009/02/04/openvpn-on-dd-wrt-v24-sp1-doesnt-star ...

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?!

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).

Hallo,
ist es möglich die bestehnde Konfiguration und Zertifikate von einem DDWRT OpenVpn-Server, auf die pfSense zu übernehmen, ansonsten müsste ich ja jeden Client ebenfalls ändern ?

Gruß

Ja, das ist problemlos möglich und in 3 Minuten erledigt !
Die Zertifikate sind einfache ASCII Texte, du kannst sie also entweder ganz simpel per cut an Paste einzeln aus dem GUI kopieren.

Sicherer ist es aber im DD-WRT Setup den SSH Zugriff zu aktivieren und dann ganz einfach z.B. mit WinSCP http://winscp.net/eng/docs/lang:de die Zertifikat Dateien mit Drag and Drop aus dem OVPN Verzeichnis des DD-WRT kopieren.

Entweder kopierst du die Datein dann genauso wieder über die SSH Shell in die pfSense oder öffnest die Dateien mit einem simplen texteditor und cut and pastest sie wieder in das pfSense GUI.

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ß

Nein komplett nicht. du musst die einzelnen Zertifikate per Drag and Drop kopieren.
Viel einfacher ist es aber wenn du per SCP bzw. WinSCP die Zertifikatsdateien einfach kopierst vom DD-WRT zum pfSense.
Da machst du alles in einem Rutsch.
Außerdem: Irgendwo hast du ja noch die Zertifikatsdateien. Das sind reine Textdateien die du im Editor aufmachen kannst und dann einfach nur per cut and paste in die Eingabefelder kopieren kannst.
Beide Wege sind eigentlich schnell und unkompliziert.

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 ?

allerdings kann ich kein Ping auf den OpenVPN-Server abgeben, geschweige denn auf das interne-Lan.

Das liegt wie immer an den Firewall Regeln !
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.

Weiterhin hat die FW-Rule am WAN Port keine Auswirkung ?

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).
Die Firewall kann logischerweise durch das Verschlüsseln im Tunnel nicht den Traffic dort ansehen und folglich bewirken auch Regeln die auf IP Kommunikation IM VPN Tunnel selber wirken sollen natürlich rein gar nix...das ist klar !
Der Traffic wird am virtuellen Tunnel Interface terminiert und erst da ist er entschlüsselt und kann mit Regeln bearbeitet werden. Sei es zum passieren oder blocken.
Etwas logisch nachdenken wie ein VPN funktioniert, dann kommt auch die Erkenntnis

Beachte genau den Punkt: Anpassen der pfSense Firewall und spez. Client Parameter im hiesigen Tutorial !!
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Dort stehen ganz genau die FW Regeln die am WAN Port UND am virtuellen Tunnel Interface definiert werden müssen damit es klappt !

Zitat von @aqui:

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ät

Hier haben wie wohl aneinander vorbei gesprochen, die VPN Topologie ist mir schon bewusst.
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 !

Allerdings konnte ich konnektieren obwohl ich die Rule am WAN-Port gänzlich gelöscht habe

Das ist zu erwarten. Die pfSense hat eine "Auto Rule Funktion" die automatisch beim Einrichten eine solche Ausnahme erstellt. Das kannst du auch sehen das dann UDP 1194 auf die WAN IP der pfSense erlaubt ist (Pass) in den WAN Port Regel Einstellungen.
Weitere Ausnahme ist wenn du einen kaskadierten Router VOR der pfSense hast und in den "General Setup" Settings das Blocken der RFC 1918 IP Netze deaktiviert hast (Haken). Dann kann alles aus diesen IPs zugreifen.
Bedenke auch hier immer die Reihenfolge der FW Regeln. First match wins !!

Ohne diese Regeln ist ein VPN Connect auf die WAN IP der pfSense technisch völlig unmöglich (oder du hast einen grundlegenden Bug entdeckt was aber sehr zu bezweifeln ist ?!)

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!

man muss den OVPN Client mit Admin-Rechten starten...

Das gilt aber nur für arme Winblows Knechte

Gut aber das du das nochmal angesprochen hast:
http://www.heise.de/ct/hotline/OpenVPN-ohne-Admin-Rechte-320656.html
und auch:
http://openvpn.net/index.php/open-source/faq/79-client/275-why-cant-i-r ...

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

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.

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.

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.

Kannst du vom Client den Zielhost denn anpingen und tracerouten aus dem VPN-Server Netz ?

Installier zusätzlich einen Wireshark Sniffer auf dem Zielhost und sniffer die eingehenden Pakete mit ! Kannst du dort eingehenden FTP Traffic (TCP 20 und TCP 21) von der Client IP sehen ?
Analog SMB Filesharing Traffic (Samba) auf TCP 445 oder UDP 137, 138 und TCP 137, 139 ?

Das ist zu 98% ein Firewall Problem irgendwo !

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.

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.

Stell das als reguläre frage statt es als Kommentar in die Anleitung zu schreiben. Dann wird Dir eher geholfen werden können.

lks

Options error: --dh fails with 'temp/openvpn/dh.pem' : No such file or directory.

Bedeutet ja das die dh.pem Datei niemals erzeugt wurde und auch gar nicht da ist ?! Wenn du in dem Verzeichnis mal ein ls -l machst kannst du die sehen ??
Lässt irgendwie die Vermutung zu das die Key Erzeugung niemals gelaufen ist vorher und gar keine Keys vorhanden sind ?!
Gehe strikt nach Anleitung vor, denn dann kann das nicht passieren. ls -l zeigt dir immer ob alle diese Dateien auch in dem Verzeichnis sind.
Klar das der OVPN nicht rennt wenn die Schlüsseldateien gar nicht da sind ?!

Es mag sein das die Bez. in aktuelleren Images etwas anders sind aber das ist eher kosmetischer Natur und hat mit der eigentlichen Funktion logischerweise nix zu tun.

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.

Bitte KEINE Doppelposts hier im Forum wenn sich das auf:
PfSense OpenVPN serven startet nicht - too many host addresses
bezieht ?!
Tip: Fehlermeldungen genau lesen

hab ich als 172.16.1.0/12 definiert. Damit haette ich meine 3 Netzwerke lokal 'optisch' getrennt.

IP adressierungstechnsich ist das unsinniger Kauderwelsch ! Was meinst du mit dieser kryptischen Aussage genau ?

aber vermutlich hab ich ja irgendwas falsch gemacht denn sonst wuerde es ja gehen.

Ja, denn du hast die interne IP Adressierung von OpenVPN vermütlich aus Unkenntniss völlig falsch verstanden und interpretiert...siehe oben ?!

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.

Ich habe wohl auf dem Cleint eine neuere Version Installiert und es vergessen, denn nach Anpassung der Config das auch andere Netzte auf den ftp zugreifen dürfen geht der ftp wieder. Ich bin immer noch erschrocken das ich vergessen habe das ich wohl den Client geupgradet habe. Sorry.

Kein Problem. Kann ja im Eifer des Gefechts mal passieren

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:

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.)

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.

Habe ich zusätzlich zu dieser Anleitung genutzt:

Auch eine sehr gute und hilfreiche Anleitung. Danke fürs Posting hier !

Zum einen heißt es oben...

Ja, das ist korrekt !

jedoch würde ich gerne auf den DSL (nicht SDSL) Router dort zugreifen.

Das ist ein weiterer Router in dem dortigen lokalen LAN 192.168.3.0 /24 ,richtig ??
Und du willst von einem anderen lokalen LAN das per OVPN angebunden ist darauf zugreifen, auch richtig ??

Wenn ich in der Zentrale die 192.168.3.1 vom PC aus eingebe, gelange ich auf den LTE-Router.

Mmmhhh, verwirrend.
Du bist als Client im lokalen Netz .3.0 und greifst lokal auf die .1 zu ?? OK, das wäre klar das das geht, denn dann befindest du dich ja selber im lokalen LAN wenn man das jetzt richtig versteht ?!

welche Route oder Firewallregel ich einstellen muss, um auf die 192.168.3.1 der Außenstelle zu gelangen, sofern das möglich ist.

Mmmmhh. Jetzt meinst du wenn du von remote via OVPN Tunnel drauf zugreifst und nicht lokal, richtig ??

OK, lokal muss man nicht erklären..klare Sache das das geht.
Wenn du von remote arbeitest und dein lokales LAN dort ist z.B. die 172.16.3.0 /24 (leider teilst du uns diese IP ja nicht mit) und du von dort mit dem remoten Client auf dden LTE Router mit der 192.168.3.1 zugreifst, muss dieser Zielrouter Router natürlich eine statische Route in das Client Netzwerk 172.16... haben...logisch.
Andernfalls würde er sein Default Gateway benutzen (Provider) und den 172.16er Traffic dahin schicken ins Nirwana.

Gesetzt den Fall also der LTE Router hat die 192.168.3.1 und der OVPN Tunnelrouter die 192.168.3.254 in dem LAN und du greifst mit der 172.16.2.111 als Client von remote zu, dann muss im LTE Router folgende statische Route im Menü "Routing" aktiviert sein:
Zielnetz: 172.16.3.0, Maske: 255.255.255.0, Gateway: 192.168.3.254 (OVPN Router)
Damit würde dann der LTE Router mit der .3.1 bei Zugriff alle Absender IPs aus dem 172.16er Netz statt ans Provider Default Gateway dann an den OVPN Router schicken und der dann wieder zum Client.
Eigentlich ganz einfach wenn man sich die Wegefindung mal vor Augen führt anhand der IP Adressen im Paket !!

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)

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/24

dazugehö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/24

dazugehöriges Interface der pfsense 192.168.200.254

OpenVPN Client (p2p) 10.200.0.0/30:1195 Tunnelnetzwerk

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?

Uuuhhh...ein recht verwirrendes Netzdesign. Wenn man es alles sortiert sollte es dann eigentlich so aussehen:

Bevor wir jetzt ins Eingemachte gehen 2 Kardinalspunkte:

Das VPN Adressdesign hat einen gravierenden Fehler der ein Routing und damit ein Funktionieren des Gesamtnetzes unmöglich macht: Dein Transfer Netzwerk in Zentrale UND Außenstelle ist GLEICH ! Das darf so in dem Konstrukt nicht sein und musst du zwingend ändern ! Netze müssen einzigartig sein für eine korrekte Layer 3 Wegefindung !! (Siehe auch hier !) Gleiches gilt im übrigen auch für die "unbekannten" Providernetze. Übrigens ein Unding !! Dein Provider muss dir zwingend die lokalen LAN IPs bzw. Subnetze mit Gateway und DNS mitteilen !!! Wie solltest du sonst deine IP Adressierung sauber planen ?!
Da du an der pfSense multiple WAN Ports hast ist es zwingend wichtig zu wissen WO die Default Gateways definiert sind und ob du ggf. ein Failover mit Multi WAN Ports auf der pfSense machst ?? https://doc.pfsense.org/index.php/Multi-WAN.

Ebenfalls die Frage wie die Routing Tabelle der einzelnen Router aussieht und wer hier NAT macht (Adress Translation) und wer nicht !
Leider ist deine Beschreibung da sehr rudimentär und man müsste raten was, wie immer, nicht hilft für eine zielführende Hilfe.

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.

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.

Das mit dem SDSL scheinst du missverstanden zu haben, schätze ich oder man versteht mich (mal wieder) nicht.

Dann wäre einen Topologie Zeichnung deinerseits hier erheblich hilfreicher für alle !

Die Daten, die in der pfsense eingetragen werden, sind vom ISP übermittelte Adressen, da es sich um öffentliche IP Adressen handelt

OK, bedeutet du bekommst am LAN Port des Provider Routers ein kleines öffentliches Subnetz, richtig ?

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).

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 !

hab ich eigentlich beim letzten Mal doch sichtbar gemacht, meine ich.

Fragt sich nur wo ? OK mit der Groupkonfig ist das nun klar...
Entspricht die Topo Zeichnung oben nun den aktuellen Gegebenheiten oder muss die noch korrigiert werden ?
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 ?

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.

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.

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.
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

gucken, ob ich ihn auf PPPoE Passthrough setzen kann

Das wäre das beste oder alternativ:
https://www.reichelt.de/?ARTICLE=112467&PROVID=2788&wt_mc=amc141 ...

Werden jetzt noch weitere Informationen benötigt?

Erstmal nicht. Soweit sieht das ja auch OK aus erstmal. Wo kneift es denn nun, bzw. was genau geht jetzt nicht ?

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 ...)

Der Grund dürfte in der Tat die fehlerhafte, doppelte IP Adressierung sein. Das ist ein gravierender Design Fehler, denn damit ist ein eindeutigews Routing zur Speedport 3.x Adresse technisch unmöglich.
Änder das oder ersetze den gleich durch ein reines nur Modem, dann wird das auch fehlerlos klappen

nicht dass vor mir irgendwer was sinnvoll dokumentiert oder abgelegt hätte

He he he ...der Klassiker

Kannst du aber auch im Kundenportal der Telekom nachsehen

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)

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

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).

Das sieht wirklich so aus als ober der SP die PPPoE Frames nicht durchreicht. Die pfSense bekommt ja keinerlei Antwort und nimmt den Link down.
Speedport auf dem aktuellsten Firmware Release ??
Vorsicht... in neueren SPs ist die Passthrough Funktion deaktiviert worden.
In der Tat ist es wirklich besser ein nur Modem zu verwenden was den Namen auch verdient

Der Speedport hat einen mehr als üblen Ruf.

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?

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

IPv4 *

LAN net

192.168.33.1

none

erstellen, obwohl es ja

IPv4 *

LAN net

none

gibt. Aber ich kam vor Ort vorher auch nicht vom 200er Netzwerk auf den Speedport.

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		*

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:

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.

dennoch komme ich von der Zentrale aus nicht zum Speedport der Außenstelle.

Da fehlen dir aber dann immer nich die richtigen Firewall Regeln.
Ein problem könnte auch sein das der SP ja keine statischen Routen supportet.
Kommt dort also ein Paket an mit einer Absender IP die nicht aus seinem lokalen (.33er

) Netz kommt, dann schmeisst er dieses Paket ganz einfach weg.
Könnte das ein Grund sein ?

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.

Ooopss... hast du den Route Eintrag dafür vergessen in der OVPN.conf ?

Wie mache ich der pfsense in der Zentrale nun klar, dass die diese Anfrage gefälligst in den Tunnel zur Außenstelle schiebt?

Mit einem OVPN route Kommando so das der Client beim Login eine entsprechende Route gesetzt bekommt für das Netzwerk.

Damit wandert es dann in den Tunnel. Bei Winblows OVPN Clients kann man das bei aktivem Client mit route print anzeigen lassen wie diese Route Table aussieht.

da es ja dann auch in der routing Tabelle auftaucht.

Ja, aber nicht beim Client ohne die OVPN Konfig !

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.

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.

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:

Akzeptiert eingehende Anfragen am Port UDP 1194.

iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT

Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfl&#-28;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&#-4;r LAN und WLAN).

iptables -I FORWARD -i br0 -o tun0 -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

mit einem ddr-wrt Router (im Switch-Modus)

Was bitte genau meinst du mit "Switch Modus" ?? Sowas gibt es bei einem Router eigentlich nicht !

iptables -I INPUT 1 -p udp --dport 1195 -j ACCEPT

Das ist eigentlich Unsinn, denn OpenVPN benutzt ausschliesslich nur UDP 1194 !!

Connection refused bedeutet das das Endgerät aktiv den Verbindungswunsch ablehnt weil es auf diesem Port keinen Dienst hat. Das ist auch völlig klar wenn du UDP 1195 nimmst, denn OVPN hört ja nur auf UDP 1194.
Ausnahme du hast das in der Server Konfig umgestellt ?!

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.

Mit Switch-Modus meinte ich das der WAN Port als LAN Port konfiguriert ist.

Was soll der tiefere Sinn davon sein ?
Hängt der OVPN Server nur einbeinig am Netz ?
Was sagt ein tcpdump ? Zeigt das eingehende UDP Pakets an ?

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.

Der Sinn dahinter ist das ich den WAN Port als LAN-Port nutzen kann und somit ein gemeinsames Netzwerk habe.

Eigentlich doch Quatsch. Warum steckst du ihn dann nicht nur einbeinig nur mit dem LAN Port auf ? Du hast da sogar noch einen 4 Port Switch. Ferner entfällt die Frickelei mit der Firewall.
Das o.a. Konstrukt und die IP Adressierung plus der Tatsache das da 2 separate OVPN Server werkeln ist echt verwirrend.
Vermutlich fehlen auch die statischen Routen zu den beiden internen OVPN Netzen im Internet Router:
Dringende Empfehlung:
Mache bitte einen separaten, neuen Thread dafür auf um das Tutorial hier nicht unnötig aufzublähen und verweise auf diesen Thread.
Daran attachest du eine Topologie Zeichnung die dein Netzwerk und die IP Adressierung etwas besser und verständlich veranschaulicht. Dann steigen wir mal in die Details ein.

Wenn man Open VPN als "VPN Split" haben möchte. Was muss muss man in die Config eintragen ?

Gruss
Rainer

Gar nichts !
Das macht OVPN im Default so. Es reicht das push route... Kommando in der Server konfig.
Du musst nur was einstellen wenn du explizit KEIN Split haben willst. Das ist dann das Gateway redirect Kommado was bewirkt das sämtlicher Traffic in den Tunnel geroutet wird.

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!

Danke für die Blumen !

Die Tücken von Router Kaskaden findet man hier:
Kopplung von 2 Routern am DSL Port
und besonders hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
auch nochmal im Detail.

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.

27d0eb2465629684a4cdec2f8831e9496e0fa469

Befinden sich denn überhaupt lokale Endgeräte im FritzBox LAN ?
Vermutlich doch wohl nicht, denn du hast ja eine simple Router Kaskade mit dem Asus Router. Sprich alle Clients sind ja sehr wahrscheinlich in desssen Subnetz. Der Asus "kennt" aber die Route ins 10.8.0.0 /16 VPN Netz !
Sind dort doch Clients drin, dann benötigst du eine statische Route auf der FB:
Ziel: 10.8.0.0, Maske: 255.255.0.0, Gateway: 192.168.178.33
Das ist aber nur sinnvoll wenn der Asus transparent routet und kein NAT (IP Adress Translation) macht an seinem WAN Port zur FB.
Mit aktivem NAT hätte man dort dann eine NAT Firewall die ein Routing aus dem FB Netz in Richtung Asus technisch unmöglich macht.
Vielleicht hilft dieses ähnliche Design zum "Routing" Verständnis !
OpenVPN - Erreiche Netzwerk hinter Client nicht

Zur VPN Nutzung über öffentliche VPN Provider besser kein Kommentar. Wie zweifelhaft und unsicher sowas ist weiss ja mittlerweile die ganze IT Welt.

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!