1. Was ist DD-WRT?
DD-WRT ist eine alternative Firmware für Router, die den Funktionsumfang um sehr viele nützliche Dinge erweitert. Eine Liste der unterstützten Geräte findet ihr hier. Die Featurelist ist hier einzusehen. Ich gehe davon aus, dass jeder hier seinen Router auf die Werkseinstellungen setzen kann und die Basics wie IP Adresse, PPPoE Einwahl usw. selbst einrichten kann. Ansonsten ist dieses Tutorial eher nichts für euch. 
Ich nutze diese Firmware auf meinem Linksys WRT54G (v3.1). Zuerst solltet ihr euch die Firmware aus dem Downloadbereich der dd-wrt Site besorgen. Aktuell verwende ich die dd-wrt.v23 SP2. Der Hauptgrund, warum ich diese Fimrware einsetze ist die Möglichkeit sich via OpenVPN Client auf dem Router einzuwählen, um dann von unterwegs aus Zugriff zu meinem System zu haben. Dazu habe ich die DD-WRT Firmwareversion dd-wrt.v23_sp2_vpn.zip genommen. Besorgt euch auch gleich den OpenVPN Client mit GUI für Windows auf dieser Site oder das Programm Tunnelblick, wenn ihr den Tunnel von einem OS X aus aufbauen wollt.
2. Installation der DD-WRT Firmware
Bevor man nun die neue Firmware in den Router einspielt, sollte man über die alte Firmware den Router auf die Werkseinstellungen zurücksetzen. Ist dies getan, kann man über das Webinterface die neue Firmware einspielen. Dies sollte auf jedenfall nicht über eine HTTPS Verbindung stattfinden! Bitte nur eine HTTP Verbindung zum Router verwenden. Auch sollte man dies nur über eine Kabelverbindung machen, da das WLAN unter Umständen Probleme macht und man so seinen Router zerschiesst. Für spezielle Flashanweisungen bei bestimmten Modellen sollte man sich auch noch diese Liste hier anschauen. Ist der Flashvorgang beendet (auf gar keinen Fall den Router vom Strom trennen oder das Kabel entfernen – der Vorgang kann bis zu fünf Minuten dauern) sollte man nochmals auf die Werkseinstellungen zurücksetzen. Dies kann man über das Menü ‘Administration/Factory Defaults’ erledigen. Der neue Benutzername bei dieser Firmware lautet ‘root’ und das Passwort ist ‘admin’. Nun kann man ersteinmal seine Basiskonfiguration in das Webinterface eingeben, damit man Zugang zum Internet bekommt usw. Dies ist hier ähnlich wie bei den meisten Routern zu konfigurieren.
3. OpenVPN Server mit statischem Key
Die einfachste Methode einen OpenVPN Server aufzusetzen ist, einen statischen Key zu verwenden. Diesen kann man über das OpenVPN Paket generieren. Unter Windows findet man das Tool unter ‘Startmenü/Programme/OpenVPN/Generate a static OpenVPN key’. Es wird eine key.txt Datei erzeugt, die unter ‘C:\Programme\OpenVPN\config’ liegt. Diese Datei solltet ihr gleich mal in static.key umbenennen.
Nutzt ihr euer OS X um den statischen Key zu erzeugen, so könnt ihr nach der Installation vom Tunnelblick Paket folgendes im Terminal (Programme/Dienstprogramme/Terminal) folgendes eingeben:
openvpn ––genkey ––secret static.key
Zur Konfiguration des OpenVPN Servers im Router geht ihr über ‘Administration/Commands’ und tragt dort im Textfeld folgendes ein und klickt danach auf ‘Save firewall’:
iptables -I INPUT 1 -p tcp ––dport 443 -j ACCEPT
Diese Regel wird dann mit in die Firewall mit aufgenommen und besagt einfach, dass wir Verbindungen auf Port 443 erlauben wollen. Ich nutze hier den Port 443 und nicht den Standard OpenVPN Port 1197, weil der Port 443 gewöhnlich überall (Firma/Internetcafe,Hotel) geöffnet ist, da man ihn für HTTPS Verbindungen nutzt. Beim Port 1197 gibt es dort mit Sicherheit mehr Probleme.
Nun tragt ihr in die gleiche Textbox folgendes ein und klickt dann auf ‘Safe Startup’:
openvpn ––mktun ––dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up
echo ”
–––––BEGIN OpenVPN Static key V1–––––
…STATISCHEN KEY HIER EINF??GEN…
–––––END OpenVPN Static key V1–––––
” > /tmp/static.key
ln -s /usr/sbin/openvpn /tmp/myvpn
/tmp/myvpn ––dev tap0 ––secret /tmp/static.key ––comp-lzo ––port 443 ––cipher AES-256-CBC ––proto tcp-server ––verb 3 ––daemon
Den Bereich ‘…STATISCHEN KEY HIER EINF??GEN…’ ersetzt ihr durch den vorhin erstellten statischen Key ‘static.key’. Dazu könnt ihr die Datei einfach in einem Editor eurer Wahl öffnen und dann das Zahlengewitter eben dort einfügen.
4. OpenVPN Clientkonfiguration
Nun legt euch eine Textdatei mit einem sprechenden Namen ala MyHome.ovpn (Windows) oder MyHome.conf (OS X) an und füllt diese mit folgendem Inhalt:
tls-client
dev tap
secret static.key
proto tcp-client
remote lepthien.homelinux.net 443
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
comp-lzo
verb 3
Als remote könnt ihr nun eine feste IP eintragen, welche die meisten von uns wohl kaum zu Hause haben werden. Dafür gibt es aber eine Lösung. Ihr könnt euch über DynDNS einen Namen registrieren, über den ihr euren Router immer erreichen könnt, egal welche IP dieser im Moment zugewiesen bekommen hat. Hat man sich so einen Namen registriert, kann man im Webinterface des Routers seine DynDNS Daten im Bereich DDNS eingeben, damit der Router den Dienst immer von IP ??nderungen benachrichtigt.
Solltest hier mit dem Client hinter einem Proxy hängen könnt ihr noch folgende Befehle an die Konfiguration anhängen (OS X):
http-proxy-retry
http-proxy IP/NAME_DES_PROXIES PORTNUMMER
Nutzt ihr den OpenVPN Client unter Windows könnt ihr den Proxy über einen Rechtsklick auf das OpenVPN Icon im Systemtray aktivieren.
Die Konfigurationsdatei und den statischen Key kopiert ihr nun in das Verzeichnis C:\Programme\OpnVPN\config\ (Windows) oder aber nach ~/Library/openvpn/ (OS X). Nutzt ihr Tunnelblick für OS X müsst ihr noch einen Trick anwenden, damit alles funktioniert. Legt dazu eine Datei ‘vpn-up.sh’ mit folgendem Inhalt an und speichert diese nach ~/Library/openvpn/:
#!/bin/bash
ipconfig set tap0 DHCP
Dann noch die Datei ausfürbar machen. Das geht im Terminal mit dem Befehl:
chmod a+x Library/openvpn/vpn-up.sh
Nun noch eure OpenVPN Konfigurationsdatei um den Eintrag ‘up “./vpn-up.sh”‘ ergänzen und schon sollte es keine Probleme mehr geben! Das Script erzwingt dann nur eine dynamische IP Adresszuweisung.
Mit dieser Konfiguration werden nur Pakete für euer Netzwerk in den Tunnel geleitet. Iht könnt also noch nebenbei weiterarbeiten oder auch surfen.
Dem Connecten sollte nun nichts mehr im Wege stehen und ihr könnt auf euren Mac/PC zugreifen. Dazu könnt ihr z.B. RDP (Windows) oder VNC (Windows,Mac) verwenden. Es müssen bei einer OpenVPN Variante auch keinerlei Ports weitergeleitet werden, da ihr euch ja direkt im LAN befindet.
Hallo Jimmy.
Danke für die Anleitung; ich habe damit mein VPN auf dem Linksys eingerichtet. Ich mu
Oh, wie peinlich, dass ich die AES Option vergessen habe
Ich möchte beim Client ja aber garnicht, dass alles in den Tunnel geleitet wird. Nutzt du auch Tunnelblick für OS X als Client, dann solltest du auch dieses Scripp, welches ich oben erwähne, anlegen, dann klappt das auch mit dem DHCP. Das ist aber nur unter OS X notwendig.
Danke für dein Feedback
Hallo Jimmy.
Ich wollte das halt so – wegen Surfen an irgendwelchen Hotspots.
Ich nutze OpenVPN unter Kubuntu. Obwohl beides letztlich denselben “Unterbau” hat, hat Deine ifconfig-Anweisung nicht funktioniert. Wahrscheinlich hätte es dhclient getan, aber bei einem einzigen Client konnte ich mir ja stre
Hi, super anleitung. allerdings fehlt bei dem Client die Angabe für den Port. Soblad diese da ist funktioniert es bei mir ohne Probleme.
Gru
Hallo Lukas. Der Port steht doch hinter dem DynDNS Namen? Da steht doch 443, da brauche ich kein weiteres Port Statement
Hi Jimmy, danke für die tolle und übersichtliche Anleitung!
Zwei ganz kurze Fragen habe ich. Vielen Dank schon mal für Deine Zeit!
::1::
Wie würden a) Firewall, b) Server und c) Client-Skript aussehen, wenn man UDP anstatt TCP verwenden möchte?
Sind diese
Hi magnum80,
ja, das sollte so gehen, wie von dir vorgeschlagen. UDP wird natürlich als noch sicherer angesehen, als wenn du hier mit TCP arbeitest. Jedoch wird es dann wohl auch mit dem Port 443 in Hotels und Co Probleme geben, da man für HTTPS Verbindungen eben nur 443TCP benötigt und das eine vernünftige Firewall dann auch nicht durchlässt.
Wenn du also auf der sicheren Seite sein willst, empfehle ich dir den Server auf TCP laufen zu lassen.
Danke Jimmy für Deine schnelle Antwort. Ich fasse mal kurz zusammen.
::UDP vs TCP::
UDP: Laut Kommentaren im Web ist es schneller und sicherer
TCP: wenn in Verbindung mit z.B. Port 443 kann es weniger Firewall Probleme machen von unterwegs, weil TCP 443 oft erlaubt ist. Aber vielleicht gibt es ja auch “gute” UDP Ports…
Was Dein Tutorial an geht, es ist der Hammer! Ich habe die oben genannten UDP
Danke für die Blumen
Danke für die Info, wenn du auf UDP umstellst. Zur Sicherheit kann ich nur sagen, dass es kaum ins Gewicht fällt, da wir ja auch schon eine 256Bit AES Verschlüsselung nehmen.
Es könnte sein, dass der DNS Port 53 offen ist, dann könnte man den als UDP Port verwenden. Da man aber meist auch noch vor nem Proxy hängt wird das auch wieder nicht gehen, denn dann brauchen die Clients ja kein DNS, das macht der Proxy.
Ich bleib bei TCP 443, das funktioniert mit der OpenVPN GUI auch schön über einen Proxy, der auf einen ganz anderen Port arbeitet
Also: Zuerst mal Lob: Super Anleitung!
Aber leider bekomme ich keine Verbindung zu Stande. Ich hab einen WRT54GL testweise mit der WAN Schnittstelle ins lokale Netz gehängt und versuche nun darauf per OpenVPN zuzugreifen (um mal zu testen). Die per DHCP an den Router zugewiesene IP Adresse habe ich natürlich in die config übernommen. Jetzt bekomme ich in OpenVPN die Fehlermeldung: “Options error: specify only one of –tls-server, –tls-client, or –secret…” Ist das ein Fehler in der config Datei von OpenVPN?
Hi Siegi,
ja, das hört sich so an als wenn du mehrere Statements von “
Hallo Jimmy!
OK; ich bin einen Schritt weiter denke ich: Die beschriebene Fehlermeldung kommt nicht mehr. Ich habe schon zuerst die config 1:1 übernommen aber jetzt sieht sie so aus:
dev tap
secret static.key
proto tcp-client
remote X.X.X.X 443
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
comp-lzo
verb 3
Das hei
Das Problem mit dem Copy Paste hatte ich auch (Zeichen wie ” und — wurden falsch erkannt). Habe diese beiden Zeichen dann manuell verbessert.
tls-client musste ich bei mir auch rausnehmen, weil ich ja schon secret static.key drinnen hatte. Schon mal versucht den port in eine einzelne Zeile zu schreiben “port 443″ anstatt direkt hinter dem remote Eintrag? Bei mir musste ich das so machen.
Also bei mir hat das wie oben von mir beschrieben auf einem Windows System sofort geklappt. Die Configs habe ich 1:1 kopiert und hier eingefügt.
Du kannst dir sonst auch nochmal das HOWTO auf der offiziellen Site anschauen: http://openvpn.net/howto.html
Ich bin jetzt erstmal eine Woche in London. Kann mich danach erst wieder melden
Also: lange nichts mehr hören lassen von mir, – aber die Entbündelung für den Anschluss wo ich das Gerät schlussendlich installiert habe war ein Abenteuer!
Nun. Ich habe es noch immer nicht voll zum laufen gebracht, – aber ich bin einen Schritt weiter: Ich habe immer OpenVPN2.1_Beta verwendet. Das funktioniert nicht ordentlich beim Handshake der Zertifikate hab ich dann mal wo zufällig gelesen. Auf with OpenVPN 2.0.9 geändert und dann:
Mon Nov 19 22:43:38 2007 TCP connection established with XXX.XXX.XXX.XXX:443
Mon Nov 19 22:43:38 2007 TCPv4_CLIENT link local: [undef]
Mon Nov 19 22:43:38 2007 TCPv4_CLIENT link remote: XXX.XXX.XXX.XXX:443
Allerdings geht es dann nicht weiter… (Es wird keine dynamische IP Adresse zugewiesen?)
Gibt es Erfahrungen welche Datenrate so eine VPN Verbindung auf dem WRT54 schafft?
Kann nicht nachvollziehen, warum es bei dir nicht geht. Haben ja doch schon einige die Anleitung durchgearbeitet und dort funktioniert es ja auch. Grosse Meisterleistungen kannst du von dem WRT nicht erwarten, ist halt ein Homegerät. Ich meine da mal was von 3Mbit/s gelesen zu haben.
PPTP ist unsicher. Sollte man lassen…
Deine Anleitung liest sich gut. Ich habe mich strikt an sie gehalten doch bekomme von
OpenVPN (2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006) leider immer wieder nur ein:
Options error: specify only one of –tls-server, –tls-client, or –secret
Use –help for more information
Hi!
Dann hast du in den Optionen irgendwo mehr als nur eine der genannten Schalter aktiv….
Vielen Dank für die schnelle Reaktion auch wenn es mir noch unklar ist,
denn oben, unter Punkt 4 (in der MyHome.ovpn) ,beschreibst du selbst zwei Schalter:
tls-client <—- Schalter 1
dev tap
secret static.key <—- Schalter 2
proto tcp-client
remote lepthien.homelinux.net 443
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
comp-lzo
verb 3
Ja, aber du musst ja definitiv den Schalter für den Key angeben, sonst wird es nicht gehen. Teste mal statt des tls-client einfach nur client. Hier sind noch ein Paar Beispielkonfigurationen:
http://openvpn.net/howto.html#examples
Nachdem ich wieder viele Stunden in das Problem investiert
Allerdings scheint es noch
habe bin ich einen Schritt weiter. Inzwischen reden Server und
Client wenigstens miteinander.
Meinungsverschiedenheiten bei den Beiden zu geben. Ich
hänge mal die relevanten Daten an und hoffe auf eure Hilfe.
(Hoffentlich sprengt das nicht das Blog).
Router (dd-WRT)-configuration:
==============================
openvpn –mktun –dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up
echo ”
—–BEGIN OpenVPN Static key V1—–
xxx
xxx
xxx
—–END OpenVPN Static key V1—–
” > /tmp/static.key
ln -s /usr/sbin/openvpn /tmp/myvpn
/tmp/myvpn –dev tap0 –secret /tmp/static.key –comp-lzo –port 443 –cipher AES-256-CBC –proto tcp-server –verb 3 –daemon
Router Firewall Regel:
======================
iptables -I INPUT 1 -p tcp –dport 443 -j ACCEPT
zuhause.ovpn des Client
=======================
# Aktiviert Client-Modus.
# client
# Device: Ethernet Bridging
dev tap
# Verweis auf Schlüssel
secret static.key
# Wählt das Protokoll
proto tcp-client
# Hostname oder die IP-Adresse der Gegenstelle (optional Port)
remote xx.xx.xxx.xx 443
# Auflösen des Hostnames des Servers
# (wegen nicht permanent mit dem Internet verbundenen Rechnern)
resolv-retry infinite
# Lakalen Port festlegen oder freigeben
nobind
# Verbindung immer gleich halten
persist-key
persist-tun
# Verschlüsselung wählen
cipher AES-256-CBC
#Komprimierung
comp-lzo
# Fehlerausgabe (Debuglevel 0-11)
verb 3
Client Logfile:
===============
Thu Dec 06 00:19:49 2007 OpenVPN 2.1_rc4 Win32-MinGW [SSL] [LZO2] built on Apr 25 2007
Thu Dec 06 00:19:49 2007 Static Encrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
Thu Dec 06 00:19:49 2007 Static Encrypt: Using 160 bit message hash ‘SHA1′ for HMAC authentication
Thu Dec 06 00:19:49 2007 Static Decrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
Thu Dec 06 00:19:49 2007 Static Decrypt: Using 160 bit message hash ‘SHA1′ for HMAC authentication
Thu Dec 06 00:19:49 2007 LZO compression initialized
Thu Dec 06 00:19:49 2007 TAP-WIN32 device [openVPN-Verbindung] opened: \\.\Global\{B88C0612-7F59-4C46-9636-5F86CB544978}.tap
Thu Dec 06 00:19:49 2007 TAP-Win32 Driver Version 9.3
Thu Dec 06 00:19:49 2007 TAP-Win32 MTU=1500
Thu Dec 06 00:19:49 2007 Successful ARP Flush on interface [262149] {B88C0612-7F59-4C46-9636-5F86CB544978}
—————————————————————————————————–
Thu Dec 06 00:19:49 2007 Data Channel MTU parms [ L:1595 D:1450 EF:63 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Dec 06 00:19:49 2007 Local Options hash (VER=V4): ‘d53e55ea’
Thu Dec 06 00:19:49 2007 Expected Remote Options hash (VER=V4): ‘cd655ee8′
Thu Dec 06 00:19:49 2007 Attempting to establish TCP connection with xx.xx.xxx.xxx:443
Thu Dec 06 00:19:49 2007 TCP connection established with xx.xx.xxx.xxx:443
Thu Dec 06 00:19:49 2007 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 06 00:19:49 2007 TCPv4_CLIENT link local: [undef]
Thu Dec 06 00:19:49 2007 TCPv4_CLIENT link remote: xx.xx.xxx.xxx:443
Thu Dec 06 00:19:53 2007 Connection reset, restarting [0]
Thu Dec 06 00:19:53 2007 TCP/UDP: Closing socket
Thu Dec 06 00:19:53 2007 SIGUSR1[soft,connection-reset] received, process restarting
Thu Dec 06 00:19:53 2007 Restart pause, 5 second(s)
—————————————————————————————————–
Thu Dec 06 00:23:46 2007 Re-using pre-shared static key
Thu Dec 06 00:23:46 2007 LZO compression initialized
Thu Dec 06 00:23:46 2007 Preserving previous TUN/TAP instance: openVPN-Verbindung
—————————————————————————————————–
Thu Dec 06 00:23:46 2007 Data Channel MTU parms [ L:1595 D:1450 EF:63 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Dec 06 00:23:46 2007 Local Options hash (VER=V4): ‘d53e55ea’
Thu Dec 06 00:23:46 2007 Expected Remote Options hash (VER=V4): ‘cd655ee8′
Thu Dec 06 00:23:46 2007 Attempting to establish TCP connection with xx.xx.xxx.xxx:443
Thu Dec 06 00:23:46 2007 TCP connection established with xx.xx.xxx.xxx:443
Thu Dec 06 00:23:46 2007 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 06 00:23:46 2007 TCPv4_CLIENT link local: [undef]
Thu Dec 06 00:23:46 2007 TCPv4_CLIENT link remote: xx.xx.xxx.xxx:443
Thu Dec 06 00:23:46 2007 Connection reset, restarting [0]
Thu Dec 06 00:23:46 2007 TCP/UDP: Closing socket
Thu Dec 06 00:23:46 2007 SIGUSR1[soft,connection-reset] received, process restarting
Thu Dec 06 00:23:46 2007 Restart pause, 5 second(s)
—————————————————————————————————–
Thu Dec 06 00:24:56 2007 Re-using pre-shared static key
Thu Dec 06 00:24:56 2007 LZO compression initialized
Thu Dec 06 00:24:56 2007 Preserving previous TUN/TAP instance: openVPN-Verbindung
Thu Dec 06 00:24:56 2007 Data Channel MTU parms [ L:1595 D:1450 EF:63 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Dec 06 00:24:56 2007 Local Options hash (VER=V4): ‘d53e55ea’
Thu Dec 06 00:24:56 2007 Expected Remote Options hash (VER=V4): ‘cd655ee8′
Thu Dec 06 00:24:56 2007 Attempting to establish TCP connection with xx.xx.xxx.xxx:443
—————————————————————————————————–
Thu Dec 06 00:24:56 2007 TCP/UDP: Closing socket
Thu Dec 06 00:24:56 2007 Closing TUN/TAP interface
Thu Dec 06 00:24:56 2007 SIGTERM[hard,init_instance] received, process exiting
So: Es geht jetzt bei mir! Die Ursache war tatsächlich der 443 Port, welcher bei aktivierter HTTPS Konfiguration über WAN Interface gemapt wird(obwohl man Port 8080 einstellt). Eigentlich keine saubere Sache
, – aber ist nun mal so. Nach Umstellen der Portnummer auf z.b. 555 (im Startup, Firewall und Client) ging es dann auch! 
Freut mich, dass es jetzt klappt! Dumm, dass dein Router das so schlecht umsetzt!
Hi Jimmy,
also ich bekomme eine verbindung, nur gehen keine Daten durch den Tunnel.
Welche IP Adressen darf ich verwenden?
VPN_Server Subnet hat 192.168.1.x
Subnet von dem ich mich einwähle hat auch 192.168.1.x
ich bekomme von dem VPN Server eine IP-Adresse zugewiesen nur leider gehen keine Daten durch den Tunnel. Ich kann die andere Seite nicht einmal pingen.
Stimmt da was mit den IP Adressen nicht? Irgendwelche tipps?
Danke Daniel
Hi Daniel,
klar darfst du im VPN nicht das selbe Subnetz wählen wie du es im LAN bereits hast. Dann schickt der Router ja nichts mehr zurück in den Tunnel, sondern denkt immer das die Pakete ja lokal bleiben sollen…
Im RFC 1918 (http://www.ietf.org/rfc/rfc1918.txt) ist ja beschrieben, welche IP Adressen man im lokalen Netz verwenden darf. Die stehen da ganz oben drin…
Nimm am besten etwas ganz anderes, so z.B. 192.168.254.0/24 für deine VPN Clients. Oder aber gleich was im Bereich 10.0.254.0/24 oder was auch immer. Aber nicht das selbe Netz wie intern.
Hi Jimmy,
ja aber dann muss ich doch das ganze Subnet in dem der VPN Server läuft ändern, oder?
Und wie kann ich dann gewährleisten das keines der LANs aus denen ich mich verbinde wieder die selbe IP hat.
Ist es möglich den VPN Clients eine andere IP zuzuweisen als jene die in dem LAN verwendet werden in dem der Server betrieben wird?
Gru
Hat wirklich keiner eine Idee was mein Router für ein Problem hat
(siehe oben)? Es sind schon Monate vergangen und ich habe mich
immer mal wieder damit beschäftigt aber drehe mich irgendwie im Kreis.
Heiho an alle Windows-gepeinigten, mit openvpn und static key hats bei mir als .ovpn so geklappt (die ovpn von jimmy hat leider bei mir nicht auf anhieb funktioniert):
remote server.domain
port 1194 #hab ich genommen weil ich den 443 als https port zur fernadmin von ddwrt nutzen will
dev tap
secret static.key
proto tcp-client
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
comp-lzo
verb 3
klappt wunderbar, rechner kriegt ip über dhcp aus dem heimnetz, überlege aber wirklich ob ich da nicht in ein 10.0.x.x netz wechseln sollte, in eins das wirklich niemand nimmt (irgendwo am hinteren ende der mitte oder so).
was für andere noch hilfreich sein könnte: text nicht direkt copy-pasten von hier in die konfiguration vom router sondern vor allem auf bindestriche und anführungszeichen achten, am besten durchgehen und neu eintippen. vielleicht hat deshalb mein zertifikatsbasiertes (open)vpn auch nicht so geklappt wie gedacht.
p.s. bei mir läuft ein asus w500p mit der ddwrt v23 SP2
vielleicht klappts
p.s. an ilian: probier mal andere anführungszeichen “”