Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

OpenVPN Server installieren auf DD-WRT Router oder pfSense Firewall

Anleitung Netzwerke

Mitglied: aqui

aqui (Level 5) - Jetzt verbinden

23.08.2009, aktualisiert 22.09.2016, 195863 Aufrufe, 152 Kommentare, 13 Danke

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/Router Firmware ?
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.



Allgemeine Einleitung

Dieses Tutorial basiert auf den bei Administrator.de bereits bestehenden Tutorials von datasearch zum Einrichten eines OpenVPN Servers:
OpenVPN_Teil_1 und OpenVPN_Teil_2
Wobei hier der Schwerpunkt auf dem Teil 1 zur Erstellung der Schlüssel für Client und Server liegt.
Die Installation die der OpenVPN Teil 2 beschreibt ist, bedingt durch die andere Hardware eines DD-WRT Routers oder der pfSense Weboberfläche zum Konfigurieren folgerichtig etwas unterschiedlich zu einer PC basierten Installation.
Dadurch aber noch einfacher auch für Laien zu realisieren, da alles mit einer einfachen Weboberfläche konfiguriert wird !

Als Alternative zu einer Installation auf Windows oder Linux kommt hier die platzsparendere Variante direkt in einem Router mit DD-WRT Firmware oder der freien Firewall/Router Software pFsense zum Einsatz.
Die VPN Funktion ist somit nicht abhängig von Serverhardware sondern autark auf einer Netzwerkkomponente, was außer der Platz Ersparniss zudem erheblich kostengünstiger ist in der Unterhaltung und vom Hardwareaufwand.

OpenVPN ist eine sehr weit verbreitete freie VPN Lösung mit Client Software für nahezu alle gängigen Betriebssysteme.
Durch ihre Flexibilität erlaubt sie z.B. das wahlfreie Konfigurieren des Tunnel Ports so das dieser z.B. vom Standard UDP 1194 auch auf den gängigen SSL Port TCP 443 gelegt werden kann, um mit der VPN Verbindung problemlos Firewall und Accesslisten ohne einen zusätzlichen Eingriff zu überwinden.

Das Tutorial benutzt die Default Einstellungen von OpenVPN und auch DD-WRT. Anpassungen an vorhandene IP Netzwerk Adressierung ist dann individuell nach vorhandener IP Adressierung zu machen.

Eine Schemazeichnung für das Netzwerkdesign sieht so aus:

b3d4ab85fd51708473007faa1c7da21c-openvpn - Klicke auf das Bild, um es zu vergrößern

Bzw. mit der pFsense Variante dann analog:

dd3cd9d586a54d7bfffeff24ce75ac6e-openvpn1 - Klicke auf das Bild, um es zu vergrößern

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/Atom 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 HIER 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:
187f1f636dbe88c055fa93a602981b1b - Klicke auf das Bild, um es zu vergrößern
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

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

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=Bayern
set KEY_CITY=Muenchen
set KEY_ORG=Privat
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 "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 !!
  • Jetzt die Client Keys (Schlüssel für die remoten Benutzer) erzeugen mit "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", "build-key client3", "build-key client4" usw. "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 "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 oder Pfsense kopiert per cut and paste.
Die Inhalte sind mit dem Editor oder Wordpad editierbar.


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 9.3 hier verfügbar:
http://sourceforge.net/projects/xca/
Ein einfach zu verstehende Anleitung findet sich hier:
http://wiki.openvpn.eu/index.php/Schlüsselverwaltung_mit_XCA

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 !


Zertifikate und Schlüssel grafisch im pfSense GUI erzeugen
Eine andere und sehr bequeme Option ist bei der Verwendung von pfSense im OpenVPN Umfeld die Zerifikate und Keys direkt, ebenfalls per Mausklick gleich im pfSense GUI zu erzeugen.
pfSense hat dieses Tool im Menü System --> Cert Manager praktischerweise gleich mit an Bord. Hier kann man auch bestehende Zertifikate von Servern usw. importieren.
Noch schneller und einfacher geht es mit dem Zertifikats "Wizzard" im Open VPN Menü:
wizz - Klicke auf das Bild, um es zu vergrößern
Auch das erspart die Eingabeaufforderung und alle externen Programme und erleichtert die Zertifikatserzeugung erheblich da sie grafisch gemacht werden kann.
Der Wizzard fragt alle Zertifikats Parameter die man wie oben auch unter easy-rsa macht im GUI.
ovpn1 - Klicke auf das Bild, um es zu vergrößern
Wichtig ist hier die Adressierung des Tunnels selber:
ovpn3 - Klicke auf das Bild, um es zu vergrößern
Hier gelten analog die allgemeinen VPN Adressierungs_Regeln aus den anderen VPN Tutorials hier.
Diese Zertifikate und Keys können dann über das grafische Setup auch einfach per Mausklick auf die OVPN Clients exportiert werden.
Die genaue Vorgehensweise wird weiter unten im Abschnitt zur "pfSense Installation von OpenVPN" ganz genau beschrieben.


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

1d8f0b6da08869a45299499d19b9bce0-ddwrt1 - Klicke auf das Bild, um es zu vergrößern

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

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

2ee10dfc233a472f8d5c62a032773d5c-ddwrt2 - Klicke auf das Bild, um es zu vergrößern

Zum Schluss sichert dann ein Klick auf SAVE und Apply Settings die Konfig !
Der OpenVPN Client bleibt ausgeschaltet (disable) !!

8f739c4a5db322f897c61a37d0c38608-ddwrt3 - Klicke auf das Bild, um es zu vergrößern

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:
01.
# Akzeptiert eingehende Anfragen am Port UDP 1194. 
02.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT 
03.
 
04.
# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc) 
05.
iptables -I INPUT 3 -i tun0 -j ACCEPT 
06.
 
07.
# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist. 
08.
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT 
09.
 
10.
# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN). 
11.
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT 
12.
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 - Klicke auf das Bild, um es zu vergrößern

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.



OVPN Installation auf der kostenfreien Firewall pfSense

Die kostenfreie Firewall pfSense besitzt im Gegensatz zu seinem Ursprungsprojekt MOnOwall einen OpenVPN Server und Client gleich mit an Bord. Die pfSense SW ist vollkommen kompatibel zur M0n0wall SW und wird genau so installiert sei es auf einer PC Plattform oder einem standalone Minimainboard (ALIX).
PfSense supportet ebenfalls VLAN Tagging was sie damit auch für VDSL Anschlüsse befähigt. Dieses Heise_Tutorial beschreibt wie es problemlos einzurichten ist am VDSL.
Details zur Installation von PC oder ALIX Mini Mainbord Version findet man in weiteren detailierten Tutorials bei Administrator.de wie z.B. HIER !
Pfsense bietet erheblich mehr Firewall Features als die schlankere Monowall. Wer also etwas mehr Wert auf Firewall Funktionen wie Redundanz, Performance Monitoring usw. legt, sollte sich für pfsense entscheiden. Wer eher eine einfache und schlanke Firewall ohne Schnickschnack will, bleibt bei der Monowall.
Mit der aktuellen Version 2.0 der pFSense Firmware ist ein externes Erzeugen alle Schlüssel für Server und Client nicht mehr erforderlich und kann bequem mit ein paar Mausklicks direkt auf dem pfSense Setup GUI gemacht werden.
Wer allerdings 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: ALIX Bord Nutzer sollten vorher im System Setup unter Advanced -> Miscellaneous den Hardware Krypto Chip auf der Geode CPU aktivieren mit einem Haken bei Use glxsb ! Das steigert die Kryptoperformance massiv.
Zum Erstellen der Zertifikate und Keys geht man nun folgendermaßen vor:
1.) Als erstes wird eine interne CA angelegt im Menü System --> Cert Manager --> Karteireiter CAs:

bffc46d88ebc4df9bf0d50984d25e999 - Klicke auf das Bild, um es zu vergrößern
Hier als Beispiel der fiktiven "Fa. Meyer". Die Daten sind entsprechend den eigenen Daten anzupassen
2.) Im Zweiten Schritt legt man die Zertifikate für den Server und die remoten Clients an --> Karteireiter Certificates:

d78ea1a642334a82e3b5ff36cbef31d6 - Klicke auf das Bild, um es zu vergrößern
3.) Hier legt man auch gleich die Zertifikate für seine remoten User an, die man entsprechen durchnummeriert oder mit ihren Namen ersetzt um die Identifikation leichter zu machen:

a6f73a2296193ae4264271d9c335dd12 - Klicke auf das Bild, um es zu vergrößern
Über die Export Buttons kann man diese Zertifikate und Keys in Dateien sichern und auf den Clientrechner in das Keyverzeichnis kopieren.
4.) Sinnvoll ist es auch gleich eine sog. Revocation Liste anzulegen mit der man Zertifikate für ungültig erklären kann, sollten z.B. remote User die Firma verlassen oder wenn der Laptop gestohlen wird.

ed327fdec8c406032be58d2bf7fa821c - Klicke auf das Bild, um es zu vergrößern
Fertig...Damit sind alle Zertifikate generiert und im nächsten Schritt...

5.) ...aktiviert man nun den Open VPN Server im Menü VPN --OpenVPN --> Karteireiter Server:
Generelle Einstellungen:

71c7129f8604d71ccf7f9e0e55dfa760 - Klicke auf das Bild, um es zu vergrößern
(Bei einer Standort Vernetzung mit einem OpenVPN Router wählt man hier "Peer to Peer")
Verschlüsselungs Einstellungen:
ac1f0a9c9a61c42ebc1914fbaed550b4 - Klicke auf das Bild, um es zu vergrößern
Tip: ALIX Board Nutzer sollten unbedingt hier vorher im Menü System --> Advanced --> Misc den Hardware Verschlüsselungssupport mit einem Haken bei "Use glxsb" aktivieren und die HW Crypto auf BSD cryptodev engine setzen !
Wichtig: Hier unbedingt die vorher erzeugte CA auswählen wie das erzeugte Server Zertifikat und die Revocation Liste !!
Tunnel Einstellungen:
2df8b87d61df9bf1c4ec3b2b4961b57d - Klicke auf das Bild, um es zu vergrößern
Hier sind mehrere Punkte wichtig:
  • Das Tunnel IP Netzwerk ist ein separates Netz und sollte keine 192.168er banal IP sein. Es gelten wie immer diese_Design_Richtlinien !
  • Lokale LAN Netzwerk IP eintragen. Wer zusätzliche Interfaces (DMZ usw.) erreichen will kann unten im "Advanced" Feld weitere IP Netze mit der "push" Option an die Clients automatisch propagieren !
  • Anzahl der maximalen Anzahl von gleichzeitigen VPN Verbindungen einstellen
  • LZO Kompression aktivieren
Client Einstellungen
dc658d97c308ac01e5d706d8ce7a4fb8 - Klicke auf das Bild, um es zu vergrößern
Hier kann man nun diverse individuelle Einstellungen für die Clients vornehmen wie DNS Server und ob man z.B. NetBios Broadcast durch den Tunnel lassen möchte ide von den jeweiligen Anforderungen abhängig sind !
Mit einem finalen Klick auf "Save" ist der Server fertig eingerichtet und sofort aktiv

Anpassen der pfSense Firewall Regeln f. VPN und spez. Client Parameter

GANZ WICHTIG: Die Firewall pfSense benötigt unbedingt eine Firewall Regel am WAN Port und virtuellen VPN Port um OpenVPN Pakete von außen auf ihrem WAN Port zuzulassen UND auch auf dem virtuellen Tunnel Interface um dort den VPN Traffic ins lokale LAN zuzulassen !!
Ohne diese Regel ist ein Zugriff von außen, wie bei einer Firewall logischerweise üblich, geblockt !
Ein OpenVPN Client könnte sonst die pfSense Firewall ohne diese Regel nicht erreichen auf dem WAN/Internet Interface un dlokalen LAN.

Dies ist also essentiell wichtig zu beachten um späteren Frust und Nachfragen gleich vorzubeugen !!
Unter Firewall -> Rules ist diese folgende Regel dann zuerst für den WAN Port zu definieren um OpenVPN Client Zugriff zu erlauben:

6be51abea4c978121927cf4d2830a4f6 - Klicke auf das Bild, um es zu vergrößern
Diese Einstellungen geht von den Standard OpenVPN Ports UDP 1194 aus !
Werden andere Port benutzt wie z.B. TCP 443 muss diese Regel natürlich entsprechend angepasst werden auf diese Ports !
Mit SAVE sichern und Apply aktivieren....

Nicht vergessen: Nun die Regel auf dem internen VPN Tunnel Interface:

a36e0bbcdbabc96a1ff9412f75396c72 - Klicke auf das Bild, um es zu vergrößern
Diese Regel oben lässt erstmal alles zu um Ping Checks usw. zum lokalen LAN machen zu können. Bei Bedarf kann diese auf entsprechende Protokolle eingeschränkt werden um nur bestimmte Dienste oder Zugriff auf einzelne Hosts, Server etc. z.B. zuzulassen.

Für den Zugriff auf die obige Standard pfSense Server Einrichting sind abweichend zur beschriebenen Client Installation unten noch ein paar Anpassungen zu machen:
Der automatisch generierte TA Key des Servers bei der Einrichtung muss per cut and paste aus dem GUI in eine Text Datei kopiert werden und ins Keyverzeichnis des Clients kopiert werden:

f452c644abca3dd019948ec9980d195d - Klicke auf das Bild, um es zu vergrößern

In der Client Konfig Datei sind dann die folgenden Anpassungen zu machen:

ca C:/Programme/OpenVPN/easy-rsa/clientkeys/CAMeyer.crt
cert C:/Programme/OpenVPN/easy-rsa/clientkeys/OVPN-Client1.crt
key C:/Programme/OpenVPN/easy-rsa/clientkeys/OVPN-Client1.key
;ns-cert-type server
--> Mit Semikolon ; auskommentieren !
tls-auth C:/Programme/OpenVPN/easy-rsa/clientkeys/ta.key 1
--> Verweist auf den oben kopierten TA Key !
cipher AES-128-CBC


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 mit OpenVPN Client geschehen.
Damit lässt sich schnell und einfach lokal das OpenVPN VPN auf korrekte Funktion testen bevor man es ans Internet hängt für den Fernzugriff.


OpenVPN hinter einem bestehenden NAT Router betreiben

Oft hat man schon einen bestehenden NAT (DSL) Router im Netzwerk und möchte dieses Netz mit dem o.a. OpenVPN Server auf einer DD-WRT oder pfSende Plattform erweitern für den VPN Zugriff.
Dies ist ebenso möglich alllerdings muss man dann einige Dinge zusätzlich beachten, da der VPN Tunnel erst durch den vorgeschalteten Router hindurch muss !
Die folgende Abbildung zeigt so ein klassisches Design:

b56744023410245680531041b93236ce - Klicke auf das Bild, um es zu vergrößern

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

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 !


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 schnel 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. Wie man das schnell und problemlos in den Griff bekommt wird u.a. [Raspberry Pi als OpenVPN Server: hier] beschrieben.

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 Clinet LAN nutzen müssen nicht.
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 Monowall, 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 !)


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:

59824f37cd5c33e6b37b335350940f27 - Klicke auf das Bild, um es zu vergrößern
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:

5f542cce28a8f32c9570e274dd8cfd1e - Klicke auf das Bild, um es zu vergrößern
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 )

d488e6196d0237ff26d119e44f7b0851 - Klicke auf das Bild, um es zu vergrößern
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.:

403552ee8f4b6e8f8508c2316c2b17b5 - Klicke auf das Bild, um es zu vergrößern
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.

dc1f9587d0d56448d3cb81c9275c0dee - Klicke auf das Bild, um es zu vergrößern
Damit ist dann auch die Domain Integration der Standorte im Handumdrehen erledigt.



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 !

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:
http://www.administrator.de/index.php?content=115798

Weiterführende Links:


Die Windows 7 / 8 Firewall bändigen beim OpenVPN Client:
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 ...

Raspberry Pi als OpenVPN Server:
http://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
http://www.administrator.de/contentid/191718

OVPN Grundlagen Tutorials hier im Forum:
http://www.administrator.de/wissen/openvpn-teil-1-installation-konfigur ...
und
http://www.administrator.de/wissen/openvpn-teil-2-openvpn-konfiguration ...
und Details für die Client Einrichtung:
https://www.administrator.de/wissen/openvpn-delegationen-315793.html

L2TP VPN mit Mikrotik Router:
http://www.administrator.de/contentid/217628

Praxistutorial IPsec VPNs:
http://www.administrator.de/contentid/115798
152 Kommentare
Mitglied: christianW
09.09.2009 um 19:17 Uhr
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 ?
Bitte warten ..
Mitglied: aqui
09.09.2009 um 23:42 Uhr
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 !
Bitte warten ..
Mitglied: christianW
12.09.2009 um 22:22 Uhr
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 ?
Bitte warten ..
Mitglied: aqui
13.09.2009, aktualisiert 18.10.2012
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:
http://www.administrator.de/wissen/vpns-einrichten-mit-pptp-117700.html ...

Generell funktioniert dieses Design vollkommen problemlos. Mit den obigen Regeln sollte es auch bei dir so sein !!
Bitte warten ..
Mitglied: christianW
14.09.2009 um 17:52 Uhr
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 !!
Bitte warten ..
Mitglied: amine2067
28.01.2010 um 16:11 Uhr
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
Bitte warten ..
Mitglied: aqui
28.01.2010 um 20:00 Uhr
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.
Bitte warten ..
Mitglied: amine2067
29.01.2010 um 10:26 Uhr
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
Bitte warten ..
Mitglied: amine2067
01.02.2010 um 09:10 Uhr
kann mir bitte jemandem helfen, ich bin ratlos
Bitte warten ..
Mitglied: aqui
08.02.2010 um 19:17 Uhr
Tutorial ist um eine Schnellanleitung zum Key erzeugen unter Windows ergänzt !
Bitte warten ..
Mitglied: Marco123
03.03.2010 um 21:42 Uhr
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
Bitte warten ..
Mitglied: aqui
07.03.2010 um 10:03 Uhr
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 !
Bitte warten ..
Mitglied: christianW
07.03.2010 um 22:33 Uhr
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!
Bitte warten ..
Mitglied: aqui
08.03.2010 um 09:29 Uhr
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
Bitte warten ..
Mitglied: agu96
01.04.2010 um 09:46 Uhr
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
Bitte warten ..
Mitglied: aqui
01.04.2010 um 11:03 Uhr
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 ??
Bitte warten ..
Mitglied: agu96
01.04.2010 um 11:22 Uhr
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.
Bitte warten ..
Mitglied: aqui
02.04.2010 um 13:22 Uhr
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:
01.
-----BEGIN CERTIFICATE----- 
02.
MIIDQDCCAqmgAwIBAgIJANclwHUBez61MA0GCSqGSIb3DQEBBAUAMHQxCzAJBgNV 
03.
BAYTAkRFMQwwCgYDVQQIEwNBZ3UxEjAQBgNVBAcTCUFndWhhdXNlbjEQMA4GA1UE 
04.
ChMHUHJpdmF0ZTESMBAGA1UEAxMJYWd1c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5h 
05.
Z3U5NkBhZ3U5Ni5kZTAeFw0xMDA0MDIwOTUxMTlaFw0yMDAzMzAwOTUxMTlaMHQx 
06.
CzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNBZ3UxEjAQBgNVBAcTCUFndWhhdXNlbjEQ 
07.
MA4GA1UEChMHUHJpdmF0ZTESMBAGA1UEAxMJYWd1c2VydmVyMR0wGwYJKoZIhvcN 
08.
AQkBFg5hZ3U5NkBhZ3U5Ni5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 
09.
wVwWoa0KuszkOnQLD9GTegvLnxSP/Db1LqPlknsVVBvpelLFO3id4aH27hIEaybF 
10.
Xb5RGSULvjPJ+zIakXTCqu/sVvILQrvySF2LoBiwqB8q+IF8vRE2CQTLH27pibVD 
11.
m7nSDBrmGe8IpcV61YyF0lb2VX5VE0Ffm5Sfgeti+20CAwEAAaOB2TCB1jAdBgNV 
12.
HQ4EFgQUbiF5cn0X6ezEQ5vr4wWqysw4SjEwgaYGA1UdIwSBnjCBm4AUbiF5cn0X 
13.
6ezEQ5vr4wWqysw4SjGheKR2MHQxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNBZ3Ux 
14.
EjAQBgNVBAcTCUFndWhhdXNlbjEQMA4GA1UEChMHUHJpdmF0ZTESMBAGA1UEAxMJ 
15.
YWd1c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5hZ3U5NkBhZ3U5Ni5kZYIJANclwHUB 
16.
ez61MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAjvErFVHVYZ6mwTap 
17.
6BgqQ7a/t2QaE7hCrNpdykI3PEi+WKhfNQ7pY2mnrYebbz81straSBb+XmajRKDn 
18.
kEheUekzr6RJyJs/SthlHv0DSdbQyi4cuRu45alAP+B0JfvFA2BvAJQfFFy5dkpX 
19.
VxaRK7LoZ5YLkp3mkd3vn/eptkg= 
20.
-----END CERTIFICATE-----
Public Client Cert, server.crt Datei
01.
Certificate: 
02.
    Data: 
03.
        Version: 3 (0x2) 
04.
        Serial Number: 1 (0x1) 
05.
        Signature Algorithm: md5WithRSAEncryption 
06.
        Issuer: C=DE, ST=Agu, L=Aguhausen, O=Private, CN=aguserver/emailAddress=agu96@agu96.de 
07.
        Validity 
08.
            Not Before: Apr  2 09:52:17 2010 GMT 
09.
            Not After : Mar 30 09:52:17 2020 GMT 
10.
        Subject: C=DE, ST=Agu, O=Private, CN=aguserver/emailAddress=agu96@agu96.de 
11.
        Subject Public Key Info: 
12.
            Public Key Algorithm: rsaEncryption 
13.
            RSA Public Key: (1024 bit) 
14.
                Modulus (1024 bit): 
15.
                    00:c1:41:12:09:9a:2e:38:0b:ba:c2:bc:fb:57:5b: 
16.
                    b5:e9:7b:40:ec:8c:20:cf:be:6b:04:08:ff:aa:c2: 
17.
                    03:f0:b3:88:65:18:c6:ad:f1:ad:64:2d:82:7d:53: 
18.
                    61:f8:11:64:b1:09:92:fc:d4:ab:64:75:c2:be:91: 
19.
                    27:a1:ef:25:dd:a0:b1:26:f4:86:32:f9:f8:f8:af: 
20.
                    97:1a:a1:e6:61:80:52:51:5a:8d:31:6f:de:9d:43: 
21.
                    2e:98:06:ef:d0:ae:60:72:cc:ca:36:32:a3:14:34: 
22.
                    04:b1:81:9c:39:18:b8:95:bf:cf:0e:e3:fb:eb:aa: 
23.
                    c9:29:6c:2a:b4:ab:3e:39:1b 
24.
                Exponent: 65537 (0x10001) 
25.
        X509v3 extensions: 
26.
            X509v3 Basic Constraints:  
27.
                CA:FALSE 
28.
            Netscape Cert Type:  
29.
                SSL Server 
30.
            Netscape Comment:  
31.
                OpenSSL Generated Server Certificate 
32.
            X509v3 Subject Key Identifier:  
33.
                8F:C2:94:A1:E2:53:2D:C7:E0:22:BE:EE:5D:0A:41:CE:59:C5:CB:68 
34.
            X509v3 Authority Key Identifier:  
35.
                keyid:6E:21:79:72:7D:17:E9:EC:C4:43:9B:EB:E3:05:AA:CA:CC:38:4A:31 
36.
                DirName:/C=DE/ST=Agu/L=Aguhausen/O=Private/CN=aguserver/emailAddress=agu96@agu96.de 
37.
                serial:D7:25:C0:75:01:7B:3E:B5 
38.
 
39.
    Signature Algorithm: md5WithRSAEncryption 
40.
        16:33:6a:41:ef:17:36:fb:6b:83:23:f4:d1:c8:5a:2a:12:ec: 
41.
        29:a6:52:51:41:ff:31:f2:d0:0c:7e:8c:3f:08:79:d1:42:3e: 
42.
        bf:9c:90:61:32:bc:72:e9:59:d2:b6:a4:54:86:61:26:59:d2: 
43.
        d2:da:56:be:b9:02:91:45:7d:58:99:e1:85:48:2c:ed:29:8b: 
44.
        11:94:23:2e:69:81:22:aa:81:04:00:df:9b:eb:b1:7d:95:c3: 
45.
        28:8e:a9:1b:47:e8:72:ba:ed:21:29:75:11:4f:7d:5c:e6:0e: 
46.
        2a:11:76:fd:1e:6d:72:40:93:11:64:ca:8a:dd:e5:34:13:e9: 
47.
        02:fc 
48.
-----BEGIN CERTIFICATE----- 
49.
MIIDazCCAtSgAwIBAgIBATANBgkqhkiG9w0BAQQFADB0MQswCQYDVQQGEwJERTEM 
50.
MAoGA1UECBMDQWd1MRIwEAYDVQQHEwlBZ3VoYXVzZW4xEDAOBgNVBAoTB1ByaXZh 
51.
dGUxEjAQBgNVBAMTCWFndXNlcnZlcjEdMBsGCSqGSIb3DQEJARYOYWd1OTZAYWd1 
52.
OTYuZGUwHhcNMTAwNDAyMDk1MjE3WhcNMjAwMzMwMDk1MjE3WjBgMQswCQYDVQQG 
53.
EwJERTEMMAoGA1UECBMDQWd1MRAwDgYDVQQKEwdQcml2YXRlMRIwEAYDVQQDEwlh 
54.
Z3VzZXJ2ZXIxHTAbBgkqhkiG9w0BCQEWDmFndTk2QGFndTk2LmRlMIGfMA0GCSqG 
55.
SIb3DQEBAQUAA4GNADCBiQKBgQDBQRIJmi44C7rCvPtXW7Xpe0DsjCDPvmsECP+q 
56.
wgPws4hlGMat8a1kLYJ9U2H4EWSxCZL81KtkdcK+kSeh7yXdoLEm9IYy+fj4r5ca 
57.
oeZhgFJRWo0xb96dQy6YBu/QrmByzMo2MqMUNASxgZw5GLiVv88O4/vrqskpbCq0 
58.
qz45GwIDAQABo4IBHzCCARswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAw 
59.
MwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIFNlcnZlciBDZXJ0aWZp 
60.
Y2F0ZTAdBgNVHQ4EFgQUj8KUoeJTLcfgIr7uXQpBzlnFy2gwgaYGA1UdIwSBnjCB 
61.
m4AUbiF5cn0X6ezEQ5vr4wWqysw4SjGheKR2MHQxCzAJBgNVBAYTAkRFMQwwCgYD 
62.
VQQIEwNBZ3UxEjAQBgNVBAcTCUFndWhhdXNlbjEQMA4GA1UEChMHUHJpdmF0ZTES 
63.
MBAGA1UEAxMJYWd1c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5hZ3U5NkBhZ3U5Ni5k 
64.
ZYIJANclwHUBez61MA0GCSqGSIb3DQEBBAUAA4GBABYzakHvFzb7a4Mj9NHIWioS 
65.
7CmmUlFB/zHy0Ax+jD8IedFCPr+ckGEyvHLpWdK2pFSGYSZZ0tLaVr65ApFFfViZ 
66.
4YVILO0pixGUIy5pgSKqgQQA35vrsX2VwyiOqRtH6HK67SEpdRFPfVzmDioRdv0e 
67.
bXJAkxFkyord5TQT6QL8 
68.
-----END CERTIFICATE-----
Private Client Key, server.key Datei
01.
-----BEGIN RSA PRIVATE KEY----- 
02.
MIICXQIBAAKBgQDBQRIJmi44C7rCvPtXW7Xpe0DsjCDPvmsECP+qwgPws4hlGMat 
03.
8a1kLYJ9U2H4EWSxCZL81KtkdcK+kSeh7yXdoLEm9IYy+fj4r5caoeZhgFJRWo0x 
04.
b96dQy6YBu/QrmByzMo2MqMUNASxgZw5GLiVv88O4/vrqskpbCq0qz45GwIDAQAB 
05.
AoGBALZ//sq2oaMn4Iz67tjGsPn2/Y7lni7RgjpjTR4y7omm4c2nIikuLDKIj8xO 
06.
rBwaQN63TeoZ5GmQlAJnDehs8XG/ZBq1yWCztpXA/YoJ7FrP+v8ejNlkIx9CjTe2 
07.
sHppeOlbA6vzp4NGlH+Xin5XZ0hQGlIFbYa4EwsE0wZsxJhBAkEA8I+LIcZ7swGj 
08.
7oNXJfsb0VxyhPNdEn3eftNPF4tNijs9hSt52nGCNUAjw2l/AF9zaNwhuM2YtNWf 
09.
mV4xuXsD0QJBAM2oRZ8o4qFQ0cxnz3cYKlL35IlCmhy/xtN17Ap38L0aVZXLELqw 
10.
7OEPsbzMuXme4f8uSGjn3279pKTrBkRJhSsCQAc3ZycWOzO9gttu2ThsdgMr0Muo 
11.
OUyKthf74s2EAkl5SXkrOraQ3SUXzXrZOVQbiOzGXcSbdk9GcUk6iCdWR2ECQQDD 
12.
GQtTPhohJuagnyq1tHsSUpC/litVcqlQGeJe3AHJo53liMrKEOXnbFgU37JkqlGD 
13.
H4kZ3D6esIjs2vkK9yQZAkAoNPcp74eVmw1gwpsyDEHNzTQHMBR+AzKbQbjxpuRK 
14.
2t0mSfj7QgJuicPgLPURRs4l2W9KByalYujsmg9clgW4 
15.
-----END RSA PRIVATE KEY-----
DH PEM, dh1024.pem Datei
01.
-----BEGIN DH PARAMETERS----- 
02.
MIGHAoGBAP1rvTSiJeCzmGqexXkslR8qRq05H+fl553r9epOgLW/Ecog8J1V2was 
03.
hpzVb4wa0XMcyrowHmIeC7Lxfzldm0R1sUsaj1SKlIfLDXZ790zB4Z591H6gvcym 
04.
W8n5fTB77anwkICPoAH9nXIf3pIKztUXchv8lNrkidtzcLwp6tqrAgEC 
05.
-----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:
01.
############################################## 
02.
# Sample client-side OpenVPN 2.0 config file # 
03.
# for connecting to multi-client server.     # 
04.
#                                            # 
05.
# This configuration can be used by multiple # 
06.
# clients, however each client should have   # 
07.
# its own cert and key files.                # 
08.
#                                            # 
09.
# On Windows, you might want to rename this  # 
10.
# file so it has a .ovpn extension           # 
11.
############################################## 
12.
 
13.
# Specify that we are a client and that we 
14.
# will be pulling certain config file directives 
15.
# from the server. 
16.
client 
17.
 
18.
# Use the same setting as you are using on 
19.
# the server. 
20.
# On most systems, the VPN will not function 
21.
# unless you partially or fully disable 
22.
# the firewall for the TUN/TAP interface. 
23.
;dev tap 
24.
dev tun 
25.
 
26.
# Windows needs the TAP-Win32 adapter name 
27.
# from the Network Connections panel 
28.
# if you have more than one.  On XP SP2, 
29.
# you may need to disable the firewall 
30.
# for the TAP adapter. 
31.
;dev-node MyTap 
32.
 
33.
# Are we connecting to a TCP or 
34.
# UDP server?  Use the same setting as 
35.
# on the server. 
36.
;proto tcp 
37.
proto udp 
38.
 
39.
# The hostname/IP and port of the server (DD-WRT Router WAN IP). 
40.
# You can have multiple remote entries 
41.
# to load balance between the servers. 
42.
remote 192.168.100.161 1194 
43.
;remote my-server-2 1194 
44.
 
45.
# Choose a random host from the remote 
46.
# list for load-balancing.  Otherwise 
47.
# try hosts in the order specified. 
48.
;remote-random 
49.
 
50.
# Keep trying indefinitely to resolve the 
51.
# host name of the OpenVPN server.  Very useful 
52.
# on machines which are not permanently connected 
53.
# to the internet such as laptops. 
54.
resolv-retry infinite 
55.
 
56.
# Most clients don't need to bind to 
57.
# a specific local port number. 
58.
nobind 
59.
 
60.
# Downgrade privileges after initialization (non-Windows only) 
61.
;user nobody 
62.
;group nobody 
63.
 
64.
# Try to preserve some state across restarts. 
65.
persist-key 
66.
persist-tun 
67.
 
68.
# If you are connecting through an 
69.
# HTTP proxy to reach the actual OpenVPN 
70.
# server, put the proxy server/IP and 
71.
# port number here.  See the man page 
72.
# if your proxy server requires 
73.
# authentication. 
74.
;http-proxy-retry # retry on connection failures 
75.
;http-proxy [proxy server] [proxy port #] 
76.
 
77.
# Wireless networks often produce a lot 
78.
# of duplicate packets.  Set this flag 
79.
# to silence duplicate packet warnings. 
80.
;mute-replay-warnings 
81.
 
82.
# SSL/TLS parms. 
83.
# See the server config file for more 
84.
# description.  It's best to use 
85.
# a separate .crt/.key file pair 
86.
# for each client.  A single ca 
87.
# file can be used for all clients. 
88.
ca C:/Programme/OpenVPN/easy-rsa/keys/ca.crt 
89.
cert C:/Programme/OpenVPN/easy-rsa/keys/aguclient1.crt 
90.
key C:/Programme/OpenVPN/easy-rsa/keys/aguclient1.key 
91.
 
92.
# Verify server certificate by checking 
93.
# that the certicate has the nsCertType 
94.
# field set to "server".  This is an 
95.
# important precaution to protect against 
96.
# a potential attack discussed here: 
97.
#  http://openvpn.net/howto.html#mitm 
98.
99.
# To use this feature, you will need to generate 
100.
# your server certificates with the nsCertType 
101.
# field set to "server".  The build-key-server 
102.
# script in the easy-rsa folder will do this. 
103.
ns-cert-type server 
104.
 
105.
# If a tls-auth key is used on the server 
106.
# then every client must also have the key. 
107.
;tls-auth ta.key 1 
108.
 
109.
# Select a cryptographic cipher. 
110.
# If the cipher option is used on the server 
111.
# then you must also specify it here. 
112.
;cipher x 
113.
 
114.
# Enable compression on the VPN link. 
115.
# Don't enable this unless it is also 
116.
# enabled in the server config file. 
117.
comp-lzo 
118.
 
119.
# Set log file verbosity. 
120.
verb 3 
121.
 
122.
# Silence repeating messages 
123.
;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 !!
Bitte warten ..
Mitglied: agu96
02.04.2010 um 20:31 Uhr
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
Bitte warten ..
Mitglied: christianW
03.04.2010 um 22:27 Uhr
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 !
Bitte warten ..
Mitglied: aqui
04.04.2010 um 10:24 Uhr
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... !
Bitte warten ..
Mitglied: christianW
04.04.2010 um 18:50 Uhr
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.
Bitte warten ..
Mitglied: christianW
04.04.2010 um 22:40 Uhr
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ß
Bitte warten ..
Mitglied: aqui
05.04.2010, aktualisiert 18.10.2012
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 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 !
Bitte warten ..
Mitglied: christianW
05.04.2010 um 15:52 Uhr
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>
Bitte warten ..
Mitglied: aqui
05.04.2010 um 16:19 Uhr
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 !
Bitte warten ..
Mitglied: christianW
05.04.2010 um 16:33 Uhr
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.
Bitte warten ..
Mitglied: aqui
05.04.2010 um 16:40 Uhr
@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:
85d9f521ab4b6620429a04623192be15 - Klicke auf das Bild, um es zu vergrößern
Dann den Router kaltgestartet daraufhin flackert die SES LED vorne und nach ca.1 Minute ist die Karte automatisch formatiert et voila...
8704e3264e8826592bc693d0a65748c9 - Klicke auf das Bild, um es zu vergrößern
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:
14dce416bf2ff37040e7eb22ee885d94 - Klicke auf das Bild, um es zu vergrößern

Hier ein paar Bilder vom Einbau:
An die GPIO Ports und Stromversorgung angelötete Kabel:
4c264aab4a6fc07424fa88403b6f6857 - Klicke auf das Bild, um es zu vergrößern

SD zu Micro SD Adapter vor dem Einlöten: (Sorry für die Unschärfe)
a96f91e569ae93bd571891e0c0849fe7 - Klicke auf das Bild, um es zu vergrößern
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)
33818e1f277198733eb947e230b032b5 - Klicke auf das Bild, um es zu vergrößern
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
Bitte warten ..
Mitglied: christianW
10.04.2010 um 21:26 Uhr
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 ?
Bitte warten ..
Mitglied: aqui
11.04.2010 um 11:26 Uhr
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 !
Bitte warten ..
Mitglied: christianW
11.04.2010 um 17:25 Uhr
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 ?
Bitte warten ..
Mitglied: aqui
11.04.2010 um 18:53 Uhr
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...
Bitte warten ..
Mitglied: agu96
12.04.2010 um 11:07 Uhr
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)...
Bitte warten ..
Mitglied: aqui
12.04.2010 um 13:25 Uhr
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.
Bitte warten ..
Mitglied: DonJoe
28.05.2010 um 10:10 Uhr
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?
Bitte warten ..
Mitglied: aqui
28.05.2010 um 17:01 Uhr
Wie sieht dein Netzdesign aus ?? So:

aa11d64b08c6776faa88e1a75eb99b5f - Klicke auf das Bild, um es zu vergrößern

  • 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 ??
Bitte warten ..
Mitglied: DonJoe
28.05.2010 um 23:30 Uhr
@ 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.
Bitte warten ..
Mitglied: christianW
28.05.2010 um 23:46 Uhr
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 ?
Bitte warten ..
Mitglied: DonJoe
29.05.2010 um 17:00 Uhr
@ 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?
Bitte warten ..
Mitglied: aqui
29.05.2010 um 18:21 Uhr
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 !!
Bitte warten ..
Mitglied: christianW
29.05.2010 um 19:22 Uhr
Hallo DonJoe.
ja genau wie Dir das aqui beschrieben hat, meinte ich dies.

PS. aqui irgendwie namen verwechselt ;)
Bitte warten ..
Mitglied: aqui
29.05.2010 um 21:14 Uhr
Ooops...sorry...schnell heimlich korrigiert
Bitte warten ..
Mitglied: DonJoe
30.05.2010 um 15:19 Uhr
@ aqui

Jetzt habe ich wohl ein Problem, da meine EasyBox 802 keine statische Route unterstützt, zumindestens das was ich ergooglet habe.
Bitte warten ..
Mitglied: christianW
30.05.2010 um 19:07 Uhr
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
Bitte warten ..
Mitglied: aqui
31.05.2010 um 11:53 Uhr
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 !
Bitte warten ..
Mitglied: bitbuerster
02.07.2010 um 12:33 Uhr
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!
Bitte warten ..
Mitglied: aqui
04.07.2010 um 12:39 Uhr
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.
Bitte warten ..
Mitglied: Hawk999
16.09.2010 um 18:46 Uhr
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
Bitte warten ..
Mitglied: aqui
17.09.2010 um 10:09 Uhr
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>
Bitte warten ..
Mitglied: DonJoe
06.11.2010 um 22:29 Uhr
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?
Bitte warten ..
Mitglied: aqui
08.11.2010 um 11:34 Uhr
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 !
Bitte warten ..
Mitglied: Digger81
20.12.2010 um 09:06 Uhr
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
Bitte warten ..
Mitglied: aqui
20.12.2010 um 10:43 Uhr
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 !
Bitte warten ..
Mitglied: Digger81
20.12.2010 um 12:12 Uhr
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 ^^.
Bitte warten ..
Mitglied: aqui
21.12.2010 um 16:54 Uhr
OK, Dank für den Hinweis. Sollen die User dieser o.a. Lösung halt selbst entscheiden
Bitte warten ..
Mitglied: dasarne
05.06.2011 um 21:26 Uhr
Jetzt habe ich es endlich geschafft. Danke für die tolle Anleitung.
Bitte warten ..
Mitglied: Jon
12.06.2012 um 18:46 Uhr
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
Bitte warten ..
Mitglied: shadow01
03.08.2012 um 19:37 Uhr
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
Bitte warten ..
Mitglied: Jon
03.08.2012 um 20:09 Uhr
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.
Bitte warten ..
Mitglied: aqui
03.08.2012, aktualisiert um 21:26 Uhr
@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ü
Bitte warten ..
Mitglied: shadow01
03.08.2012 um 22:06 Uhr
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
Bitte warten ..
Mitglied: aqui
04.08.2012, aktualisiert um 12:58 Uhr
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 !
Bitte warten ..
Mitglied: chaotize
28.08.2012, aktualisiert um 10:17 Uhr
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..

Mit freundlichen Grüßen Chaotize
Bitte warten ..
Mitglied: aqui
28.08.2012, aktualisiert um 11:11 Uhr
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 !
Bitte warten ..
Mitglied: chaotize
28.08.2012, aktualisiert um 13:32 Uhr
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..

Mit freundlichen Grüßen Chaotize
Bitte warten ..
Mitglied: aqui
28.08.2012, aktualisiert um 14:29 Uhr
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 !
Bitte warten ..
Mitglied: chaotize
28.08.2012, aktualisiert um 15:49 Uhr
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 ...
Bitte warten ..
Mitglied: aqui
28.08.2012, aktualisiert um 16:01 Uhr
. 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 !!
Bitte warten ..
Mitglied: 108172
28.08.2012 um 19:23 Uhr
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.
Bitte warten ..
Mitglied: aqui
29.08.2012, aktualisiert um 10:27 Uhr
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:

d13765586a79384472aa85d5c04d1d2c - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: chaotize
29.08.2012 um 12:36 Uhr
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
Bitte warten ..
Mitglied: aqui
29.08.2012, aktualisiert um 12:42 Uhr
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.
Bitte warten ..
Mitglied: Kaioshin
08.01.2013, aktualisiert um 22:55 Uhr
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
Bitte warten ..
Mitglied: aqui
08.01.2013, aktualisiert um 22:38 Uhr
Ganz klar ist deine Fragestellung nicht. Was meinst du mit dem "Client" Screenshot, diesen hier:
dc658d97c308ac01e5d706d8ce7a4fb8 - Klicke auf das Bild, um es zu vergrößern
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.
Bitte warten ..
Mitglied: Kaioshin
08.01.2013, aktualisiert 09.01.2013
Hallo aqui

Ich meinte dieses Bild hier:
b5845fb271e2c171330ad04ebeb2d01f - Klicke auf das Bild, um es zu vergrößern

Wobei ich das nun gefunden habe (meine ich zumindest):
be2d2cc0c2514aa280a008a0a650851e - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: aqui
09.01.2013 um 18:03 Uhr
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.
Bitte warten ..
Mitglied: Spirit
20.05.2013 um 01:32 Uhr
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.
Bitte warten ..
Mitglied: aqui
20.05.2013, aktualisiert um 11:53 Uhr
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 !
Bitte warten ..
Mitglied: Spirit
20.05.2013 um 13:27 Uhr
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.
Bitte warten ..
Mitglied: Spirit
20.05.2013, aktualisiert um 14:07 Uhr
Zitat von aqui:
Dein Problem bei der Freigabe ist die lokale Firewall auf dem Rechner der das Share freigibt. Der lässt nur lokale IPs zu !
Du aber kommst via VPN ja mit einer fremden IP dort an und wirst folglich geblockt !
Änder also die FW Einstellungen für die Datei- und Druckerfreigabe, dann klappt das auch sofort !


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
Bitte warten ..
Mitglied: aqui
20.05.2013, aktualisiert um 16:39 Uhr
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:
http://www.administrator.de/wissen/openwrt-low-cost-router-für-lan ...
Bitte warten ..
Mitglied: Spirit
20.05.2013, aktualisiert um 20:34 Uhr
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 ;)
Bitte warten ..
Mitglied: aqui
21.05.2013, aktualisiert um 11:27 Uhr
Siehste... ! Wieder den richtigen Riecher gehabt !
..alles wird gut
Bitte warten ..
Mitglied: Spirit
30.05.2013, aktualisiert um 23:30 Uhr
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:

01.
# Akzeptiert eingehende Anfragen am Port 1194. 
02.
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT 
03.
 
04.
# Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfläche, SSH etc) 
05.
iptables -I INPUT 3 -i tun0 -j ACCEPT 
06.
 
07.
# Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist. 
08.
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT 
09.
 
10.
# Erlaubt Verbindungen vom lokalen Netz ins VPN Netz und umgekehrt (br0 steht für LAN und WLAN). 
11.
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT 
12.
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.
Bitte warten ..
Mitglied: Spirit
30.05.2013, aktualisiert um 23:33 Uhr
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:

01.
dev tun0 
02.
proto udp 
03.
port 1194 
04.
server 172.16.40.0 255.255.255.0 
05.
push "route 172.16.10.0 255.255.255.0" 
06.
push "route 172.16.20.0 255.255.255.0" 
07.
push "route 172.16.30.0 255.255.255.0" 
08.
keepalive 10 120 
09.
tun-mtu 1500 
10.
tun-mtu-extra 32 
11.
management localhost 5001 
12.
verb 3 
13.
cipher AES-256-CBC 
14.
comp-lzo 
15.
persist-key 
16.
persist-tun
Bitte warten ..
Mitglied: aqui
31.05.2013, aktualisiert um 10:38 Uhr
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
Bitte warten ..
Mitglied: Spirit
31.05.2013, aktualisiert um 12:58 Uhr
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

01.
Public Server Cert  ==>> Master Zertifikat, ca.crt Datei 
02.
Certificate revoke list ==>> bleibt leer !! 
03.
Public Client cert  ==>> Server Zertifikat, server.crt Datei 
04.
Private Client key  ==>> Server Key, server.key 
05.
DH pem  ==>> DH Parameter, dh1024.pem Datei 
06.
OpenVPN config  OpenVPN Konfig Datei, z.B. Beispiel unten 
07.
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.

01.
CA CERT => CA.crt (Master Zertifikat) 
02.
Public Server CERT => Server.crt (Server Zertifikat) 
03.
Private Server Key => Server.pem (Server Key) 
04.
DH PEM => dhxxxx.pem (DH Parameter) 
05.
 
06.
Additional Config => Server Konfig 
07.
TLS Auth Key => bleibt leer 
08.
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.
Bitte warten ..
Mitglied: Spirit
31.05.2013, aktualisiert um 13:01 Uhr
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:

01.
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
Bitte warten ..
Mitglied: Spirit
04.10.2013 um 15:41 Uhr
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..???
Bitte warten ..
Mitglied: aqui
04.10.2013, aktualisiert um 17:58 Uhr
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 !
Bitte warten ..
Mitglied: Spirit
04.10.2013 um 23:25 Uhr
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
Bitte warten ..
Mitglied: Spirit
05.10.2013, aktualisiert um 01:21 Uhr
So habe es nun über diesen Weg gemacht:

Ich habe folgende Zeile in der OpenVPN Konfig eingefügt:
01.
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:

01.
interface=tun0  
02.
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.
Bitte warten ..
Mitglied: aqui
05.10.2013 um 10:41 Uhr
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....!
Bitte warten ..
Mitglied: RicoPausB
06.12.2013 um 16:11 Uhr
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.
Bitte warten ..
Mitglied: aqui
06.12.2013, aktualisiert um 16:23 Uhr
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.
Bitte warten ..
Mitglied: RicoPausB
06.12.2013 um 16:49 Uhr
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.
Bitte warten ..
Mitglied: RicoPausB
08.12.2013 um 19:38 Uhr
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.
Bitte warten ..
Mitglied: Rufnec
05.02.2014 um 14:45 Uhr
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
Bitte warten ..
Mitglied: aqui
05.02.2014, aktualisiert um 17:02 Uhr
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 !
Bitte warten ..
Mitglied: DonJoe
20.03.2014 um 10:59 Uhr
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?
Bitte warten ..
Mitglied: aqui
21.03.2014, aktualisiert um 19:32 Uhr
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 !
Bitte warten ..
Mitglied: DonJoe
26.03.2014 um 15:42 Uhr
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.
Bitte warten ..
Mitglied: aqui
27.03.2014 um 12:50 Uhr
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 ...
Bitte warten ..
Mitglied: DonJoe
28.03.2014 um 16:48 Uhr
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
  1. start openvpn again if failed
(sleep 30 && (ps | grep openvpn | grep -v grep || openvpn --daemon --config /tmp/openvpn/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down /tmp/openvpncl/route-down.sh --daemon))&

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?!
Bitte warten ..
Mitglied: DonJoe
31.03.2014 um 14:53 Uhr
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).
Bitte warten ..
Mitglied: christianW
22.04.2014 um 22:59 Uhr
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ß
Bitte warten ..
Mitglied: aqui
24.04.2014 um 17:57 Uhr
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.
Bitte warten ..
Mitglied: christianW
24.04.2014 um 21:06 Uhr
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ß
Bitte warten ..
Mitglied: aqui
25.04.2014 um 20:54 Uhr
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.
Bitte warten ..
Mitglied: christianW
25.04.2014, aktualisiert um 23:00 Uhr
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:
ce6c346dc61987b54cc8abe55a8e62b2 - Klicke auf das Bild, um es zu vergrößern

Firewall WAN-Interface:
f9176d5b534ce36e81f82de3d0dac46a - Klicke auf das Bild, um es zu vergrößern

Firewall OpenVPN-Interface:
f9176d5b534ce36e81f82de3d0dac46a - Klicke auf das Bild, um es zu vergrößern

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 ?
Bitte warten ..
Mitglied: aqui
26.04.2014, aktualisiert um 11:20 Uhr
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 !!
http://www.administrator.de/contentid/123285
Dort stehen ganz genau die FW Regeln die am WAN Port UND am virtuellen Tunnel Interface definiert werden müssen damit es klappt !
Bitte warten ..
Mitglied: christianW
26.04.2014 um 20:30 Uhr
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


Ahem, das ist ja auch klar und logisch !! Hier kommt ja dein im Tunnel verschlüsselter Traffic rein. Es muss also nur eine
Regel eingestellt werden die Eingehenden Traffic auf UDP 1194 erlaubt (OVPN Tunnel).
Etwas logisch nachdenken wie ein VPN funktioniert, dann kommt auch die Erkenntnis

Hier haben wie wohl aneinander vorbei gesprochen, die VPN Topologie ist mir schon bewusst.
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 !
Bitte warten ..
Mitglied: aqui
26.04.2014, aktualisiert um 22:31 Uhr
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 ?!)
Bitte warten ..
Mitglied: wisebeer
15.09.2014 um 22:00 Uhr
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!
Bitte warten ..
Mitglied: aqui
17.09.2014 um 11:25 Uhr
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 ...
Bitte warten ..
Mitglied: DonJoe
24.04.2015 um 09:23 Uhr
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
Bitte warten ..
Mitglied: aqui
24.04.2015 um 18:07 Uhr
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.
Bitte warten ..
Mitglied: DonJoe
15.06.2015 um 23:25 Uhr
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.
Bitte warten ..
Mitglied: aqui
16.06.2015, aktualisiert um 09:12 Uhr
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 !
Bitte warten ..
Mitglied: marcel90
04.07.2015 um 14:47 Uhr
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.
Bitte warten ..
Mitglied: Lochkartenstanzer
04.07.2015 um 15:11 Uhr
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
Bitte warten ..
Mitglied: aqui
04.07.2015, aktualisiert um 15:44 Uhr
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.
Bitte warten ..
Mitglied: kiwiana
22.07.2015 um 01:55 Uhr
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 warten ..
Mitglied: aqui
22.07.2015, aktualisiert um 12:02 Uhr
Bitte KEINE Doppelposts hier im Forum wenn sich das auf:
http://www.administrator.de/frage/pfsense-openvpn-serven-startet-too-ma ...
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 ?!
Bitte warten ..
Mitglied: DonJoe
27.09.2015 um 18:55 Uhr
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.
Bitte warten ..
Mitglied: DonJoe
27.09.2015 um 18:59 Uhr
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.
Bitte warten ..
Mitglied: aqui
27.09.2015 um 20:55 Uhr
Kein Problem. Kann ja im Eifer des Gefechts mal passieren
Bitte warten ..
Mitglied: Skyemugen
20.05.2016 um 14:03 Uhr
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.
Bitte warten ..
Mitglied: aqui
20.05.2016, aktualisiert um 18:07 Uhr
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 !!
Bitte warten ..
Mitglied: Skyemugen
21.05.2016 um 19:54 Uhr
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?
Bitte warten ..
Mitglied: aqui
22.05.2016, aktualisiert um 13:48 Uhr
Uuuhhh...ein recht verwirrendes Netzdesign. Wenn man es alles sortiert sollte es dann eigentlich so aussehen:

ovpn2 - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: Skyemugen
22.05.2016, aktualisiert um 15:09 Uhr
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.
ovpn - Klicke auf das Bild, um es zu vergrößern
p2p - Klicke auf das Bild, um es zu vergrößern

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.
gatewaygroups - Klicke auf das Bild, um es zu vergrößern
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
wan_rules - Klicke auf das Bild, um es zu vergrößern
sdsl_rules - Klicke auf das Bild, um es zu vergrößern
nat_prtfwd - Klicke auf das Bild, um es zu vergrößern

Ich hoffe, das ist hilfreich für dich, mir ist nur das mit dem Transfernetzwerk nicht klar.
Bitte warten ..
Mitglied: aqui
23.05.2016, aktualisiert um 11:59 Uhr
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 ?
Bitte warten ..
Mitglied: Skyemugen
23.05.2016 um 15:24 Uhr
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.
Deshalb auch die berechtigte Frage WO die Default Gateways der pfSense hinzeigen bzw. WIE deren Routing Tabellen aussehen !!!
Da du mehrere WAN Ports hier betreibst ist das für den Traffic Flow essentiell wichtig zu wissen.
Sowas wie "DMZ" gibt es an einen Speedport Schrottrouter nicht. Vergiss den Quatsch. Was du hier machst ist ein sog. exposed Host. Sprich der Speedport schaufelt alle TCP/UDP Ports von inbound Traffic die er nicht selber kennt an die pfSense. Mit DMZ hat sowas rein gar nichts zu tun !
Richtig, Exposed Host nennt sich das beim LTE-Router [fiel mir nicht mehr ein, bin DMZ so gewohnt], der Speedport hat das nicht mal, soweit ich in den Einstellungen sehen konnte.
Zentrale
routes - Klicke auf das Bild, um es zu vergrößern
gateways - Klicke auf das Bild, um es zu vergrößern
Außenstelle
routesfw - Klicke auf das Bild, um es zu vergrößern
routesfw - Klicke auf das Bild, um es zu vergrößern
gwgroupsfw - Klicke auf das Bild, um es zu vergrößern
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
gwfw - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
23.05.2016 um 16:57 Uhr
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 ?
Bitte warten ..
Mitglied: Skyemugen
23.05.2016 um 17:15 Uhr
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 ...)
Bitte warten ..
Mitglied: aqui
23.05.2016 um 19:38 Uhr
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
Bitte warten ..
Mitglied: Skyemugen
25.05.2016, aktualisiert um 14:43 Uhr
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)
01.
May 25 12:28:47 	ppp: [wan_link0] LCP: Down event 
02.
May 25 12:28:47 	ppp: [wan_link0] Link: reconnection attempt 3 in 4 seconds 
03.
May 25 12:28:51 	ppp: [wan_link0] Link: reconnection attempt 3 
04.
May 25 12:28:51 	ppp: [wan_link0] PPPoE: Connecting to '' 
05.
May 25 12:29:00 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds 
06.
May 25 12:29:00 	ppp: [wan_link0] Link: DOWN event 
07.
May 25 12:29:00 	ppp: [wan_link0] LCP: Down event 
08.
May 25 12:29:00 	ppp: [wan_link0] Link: reconnection attempt 4 in 2 seconds 
09.
May 25 12:29:02 	ppp: [wan_link0] Link: reconnection attempt 4 
10.
May 25 12:29:02 	ppp: [wan_link0] PPPoE: Connecting to '' 
11.
May 25 12:29:11 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds 
12.
May 25 12:29:11 	ppp: [wan_link0] Link: DOWN event 
13.
May 25 12:29:11 	ppp: [wan_link0] LCP: Down event 
14.
May 25 12:29:11 	ppp: [wan_link0] Link: reconnection attempt 5 in 3 seconds 
15.
May 25 12:29:14 	ppp: [wan_link0] Link: reconnection attempt 5 
16.
May 25 12:29:14 	ppp: [wan_link0] PPPoE: Connecting to '' 
17.
May 25 12:29:23 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds 
18.
May 25 12:29:23 	ppp: [wan_link0] Link: DOWN event 
19.
May 25 12:29:23 	ppp: [wan_link0] LCP: Down event 
20.
May 25 12:29:23 	ppp: [wan_link0] Link: reconnection attempt 6 in 1 seconds 
21.
May 25 12:29:24 	ppp: [wan_link0] Link: reconnection attempt 6 
22.
May 25 12:29:24 	ppp: [wan_link0] PPPoE: Connecting to '' 
23.
May 25 12:29:33 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds 
24.
May 25 12:29:33 	ppp: [wan_link0] Link: DOWN event 
25.
May 25 12:29:33 	ppp: [wan_link0] LCP: Down event 
26.
May 25 12:29:33 	ppp: [wan_link0] Link: reconnection attempt 7 in 3 seconds 
27.
May 25 12:29:36 	ppp: [wan_link0] Link: reconnection attempt 7 
28.
May 25 12:29:36 	ppp: [wan_link0] PPPoE: Connecting to '' 
29.
May 25 12:29:45 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds 
30.
May 25 12:29:45 	ppp: [wan_link0] Link: DOWN event 
31.
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 scheiß Speedport liegt oder kann ich da jetzt noch was an der pfsense testen?

Nachtrag: Scheiß 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).
Bitte warten ..
Mitglied: aqui
25.05.2016 um 16:16 Uhr
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.
Bitte warten ..
Mitglied: Skyemugen
25.05.2016 um 21:02 Uhr
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?
Bitte warten ..
Mitglied: Skyemugen
27.05.2016 um 11:53 Uhr
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.
Bitte warten ..
Mitglied: aqui
30.05.2016 um 11:05 Uhr
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 ?
Bitte warten ..
Mitglied: Skyemugen
30.05.2016 um 16:02 Uhr
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.

tracert - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: aqui
31.05.2016 um 13:20 Uhr
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 !
Bitte warten ..
Mitglied: Skyemugen
31.05.2016 um 14:29 Uhr
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.
Bitte warten ..
Mitglied: Skyemugen
31.05.2016, aktualisiert 01.06.2016
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.
01.
Routenverfolgung zu 192.168.33.253 über maximal 30 Abschnitte 
02.
 
03.
  1    <1 ms    <1 ms    <1 ms  pfsense.wpt-berlin.zz [192.168.100.254] 
04.
  2     9 ms     8 ms     9 ms  192.168.33.253 
05.
 
06.
Ablaufverfolgung beendet. 
07.
 
08.
 
09.
Routenverfolgung zu 192.168.33.1 über maximal 30 Abschnitte 
10.
 
11.
  1    <1 ms    <1 ms    <1 ms  pfsense.wpt-berlin.zz [192.168.100.254] 
12.
  2     9 ms     8 ms     8 ms  10.244.200.2 
13.
  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.
Bitte warten ..
Mitglied: DonJoe
25.11.2016 um 20:31 Uhr
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:
  1. 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

  1. Erlaubt den VPN Clients den Zugriff auf routerinterne Prozesse (Weboberfl&#-28;che, SSH etc)
iptables -I INPUT 3 -i tun0 -j ACCEPT

  1. Erlaubt Verbindungen zwischen VPN Clients sofern "Client-to-Client" bei OpenVPN aktiviert ist.
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT

  1. 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
Bitte warten ..
Mitglied: aqui
26.11.2016 um 09:41 Uhr
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 ?!
Bitte warten ..
Mitglied: DonJoe
26.11.2016 um 11:44 Uhr
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.
Bitte warten ..
Mitglied: aqui
27.11.2016, aktualisiert um 00:22 Uhr
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 ?
Bitte warten ..
Mitglied: DonJoe
29.11.2016 um 11:24 Uhr
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.
Bitte warten ..
Mitglied: aqui
29.11.2016 um 11:49 Uhr
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.
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Netzwerkmanagement
VPN Server über FritzBox oder über DD-WRT Router (1)

Frage von ValdoAddams zum Thema Netzwerkmanagement ...

Peripheriegeräte
WRT3200ACM: Linksys kündigt neuen OpenWRT- und DD-WRT-Router an

Link von runasservice zum Thema Peripheriegeräte ...

Netzwerkprotokolle
DD-WRT Router: Frage zum Routing (13)

Frage von D46505Pl zum Thema Netzwerkprotokolle ...

Linux Netzwerk
VLAN WRT54GL (DD-WRT) und pfSense

Frage von dietzi zum Thema Linux Netzwerk ...

Heiß diskutierte Inhalte
Router & Routing
gelöst Ipv4 mieten (22)

Frage von homermg zum Thema Router & Routing ...

Windows Server
DHCP Server switchen (20)

Frage von M.Marz zum Thema Windows Server ...

Exchange Server
gelöst Exchange 2010 Berechtigungen wiederherstellen (20)

Frage von semperf1delis zum Thema Exchange Server ...

Hardware
gelöst Negative Erfahrungen LAN-Karten (19)

Frage von MegaGiga zum Thema Hardware ...