12
Open-VPN zwischen pfSense-Server und DD-WRT-Client
Hi Profi´s,
nachdem ich mit Hilfe von Aqui´s Tutorial erfolgreich ein Alix 2D13 zum pfSense WLAN-Router mit DMZ und VPN-Funktion "umfunktioniert" habe, bin ich jetzt dabei eine Open-VPN-Verbindung zu einem Linksys WRT54GL mit DD-WRT als VPN-Client aufzubauen.
Die Zertifikats- und Keyerstellung erfolgte mit pfSense vor der Einrichtung des Open-VPN-Servers.
Zertifikate und Key habe ich per copie and paste in den DD-WRT-GUI verfrachtet.
Leider funktioniert das Ganze nicht so wie geplant. Mit den zu kopierenden Zertifikate bzw. Key´s bin ich mir nicht so richtig sicher.
Das wird wahrscheinlich auch die Ursache sein, Änderungen brachten leider keinen Erfolg.
Hier mal die Open-VPN-Log´s....
Leider ist der WRT54GL einige Kilometer weg und ich habe nicht die Möglichkeit das ganze erst mal ohne Internet zu testen.
Sorry, ein kleiner Nachtrag zur Fehlereingrenzung....
client
dev tun
proto udp
remote xxxxxxx.dyndns-xxxx.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tun-mtu 1492
tun-mtu-extra 32
mssfix 1450
ca /tmp/openvpncl/ca.crt
cert /tmp/openvpncl/client.crt
ns-cert-type server
key /tmp/openvpncl/client.key
comp-lzo
die dd-wrt openvpn.conf des Clients.
Gruß orcape
nachdem ich mit Hilfe von Aqui´s Tutorial erfolgreich ein Alix 2D13 zum pfSense WLAN-Router mit DMZ und VPN-Funktion "umfunktioniert" habe, bin ich jetzt dabei eine Open-VPN-Verbindung zu einem Linksys WRT54GL mit DD-WRT als VPN-Client aufzubauen.
Die Zertifikats- und Keyerstellung erfolgte mit pfSense vor der Einrichtung des Open-VPN-Servers.
Zertifikate und Key habe ich per copie and paste in den DD-WRT-GUI verfrachtet.
Leider funktioniert das Ganze nicht so wie geplant. Mit den zu kopierenden Zertifikate bzw. Key´s bin ich mir nicht so richtig sicher.
Das wird wahrscheinlich auch die Ursache sein, Änderungen brachten leider keinen Erfolg.
Hier mal die Open-VPN-Log´s....
Leider ist der WRT54GL einige Kilometer weg und ich habe nicht die Möglichkeit das ganze erst mal ohne Internet zu testen.
Sorry, ein kleiner Nachtrag zur Fehlereingrenzung....
client
dev tun
proto udp
remote xxxxxxx.dyndns-xxxx.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tun-mtu 1492
tun-mtu-extra 32
mssfix 1450
ca /tmp/openvpncl/ca.crt
cert /tmp/openvpncl/client.crt
ns-cert-type server
key /tmp/openvpncl/client.key
comp-lzo
die dd-wrt openvpn.conf des Clients.
Gruß orcape
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179344
Url: https://administrator.de/forum/open-vpn-zwischen-pfsense-server-und-dd-wrt-client-179344.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
12 Kommentare
Neuester Kommentar
Sehr wichtig wäre das OpenVPN Log zu sehen auf dem pfSense wenn sich der Client (dd-wrt) einwählt. Oder auch das OpenVPN Client Log auf dem dd-wrt Router wenn du dort einen SSH Zugang hast ! Ggf. dort erstmal den OpenVPN Tunnel manuell starten wie im Tutorial beschrieben ! Anhand dessen Outputs siehst du dann auch sofort was los ist !
Dort kannst du immer sofort sehen wo es kneift. Dein Screenshot oben ist wenig hilfreich, denn er zeigt nur das der OpenVPN Server sauber gestartet ist auf dem pfSense.
Nur mal dumm nachgefragt:
Am pfSense hast du am WAN Port den Zugriff in den Firewall Regeln für UDP 1194 generell von überall erlaubt ??
Ansonsten wird das geblockt und keine OpenVPN Pakete kommen da jemals an...
Hast du vor der pfSense ein Modem oder ein Router. Bei Router dann ggf. die RFC 1918 Globalregel entfernen !
Dort kannst du immer sofort sehen wo es kneift. Dein Screenshot oben ist wenig hilfreich, denn er zeigt nur das der OpenVPN Server sauber gestartet ist auf dem pfSense.
Nur mal dumm nachgefragt:
Am pfSense hast du am WAN Port den Zugriff in den Firewall Regeln für UDP 1194 generell von überall erlaubt ??
Ansonsten wird das geblockt und keine OpenVPN Pakete kommen da jemals an...
Hast du vor der pfSense ein Modem oder ein Router. Bei Router dann ggf. die RFC 1918 Globalregel entfernen !
Hi Aqui,
ssh-Zugang habe ich, werde mich mal um die Logs bemühen.
Hab ich aus dem Tutorial so übertragen.
Modem
Wäre sicher einfacher gewesen einen pfSense auf der Gegenstelle zu haben....
Aber da lernt man ja nischt.
Gruß orcape
ssh-Zugang habe ich, werde mich mal um die Logs bemühen.
Nur mal dumm nachgefragt: (gibts nicht ! gibt nur dumme Antworten )
Am pfSense hast du am WAN Port den Zugriff in den Firewall Regeln für UDP 1194 generell von überall erlaubt ??
Ansonsten wird das geblockt und keine OpenVPN Pakete kommen da jemals an...
)Am pfSense hast du am WAN Port den Zugriff in den Firewall Regeln für UDP 1194 generell von überall erlaubt ??
Ansonsten wird das geblockt und keine OpenVPN Pakete kommen da jemals an...
Hab ich aus dem Tutorial so übertragen.
Hast du vor der pfSense ein Modem oder ein Router. Bei Router dann ggf. die RFC 1918 Globalregel entfernen !
Modem
Wäre sicher einfacher gewesen einen pfSense auf der Gegenstelle zu haben....
Aber da lernt man ja nischt.
Gruß orcape
Nöö einfacher ist das nicht...ist ja das gleiche Spielchen. Funktionieren tut beides auch im Mischbetrieb problemlos ist ja die gleiche SW !
Paste mal die Logs hier beim Verbindungsaufbau dann sehen wir auch was los ist !
Paste mal die Logs hier beim Verbindungsaufbau dann sehen wir auch was los ist !
Hi Aqui,
hier nun mal die Ausgabe der Logs des DD-WRT beim OVPN-Client Start....
beim openvpncl-start erhalte ich dann TLS-Fehlermeldungen auch auf dem Server......
Zur Client-Konfiguration des DD-WRT...
Public Server Cert = CA root crt
Public Client Cert = client crt
Private Client Key = client key # alles per cut and paste aus pfSense in den DD-WRT kopiert
Wohin kommt der TLS-Key ? In den Daemon sicher nicht, habe ich mit in den "privat Client Key" kopiert.
Im DD-WRT findet sich ja auch im client.key wieder.
SPI Firewall des DD-WRT war während der Tests deaktiviert..
Gruß orcape
hier nun mal die Ausgabe der Logs des DD-WRT beim OVPN-Client Start....
root@winnie:~# openvpn /tmp/openvpncl/openvpn.conf
Tue Jan 24 14:28:17 2012 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Tue Jan 24 14:28:17 2012 LZO compression initialized
Tue Jan 24 14:28:17 2012 UDPv4 link local: [undef]
Tue Jan 24 14:28:17 2012 UDPv4 link remote: 78.55.163.6:1194
Tue Jan 24 14:29:17 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 24 14:29:17 2012 TLS Error: TLS handshake failed
Tue Jan 24 14:29:17 2012 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 24 14:29:19 2012 Re-using SSL/TLS context
Tue Jan 24 14:29:19 2012 LZO compression initialized
Tue Jan 24 14:29:19 2012 UDPv4 link local: [undef]
Tue Jan 24 14:29:19 2012 UDPv4 link remote: 78.55.163.6:1194
Tue Jan 24 14:28:17 2012 OpenVPN 2.1_rc20 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Oct 10 2009
Tue Jan 24 14:28:17 2012 LZO compression initialized
Tue Jan 24 14:28:17 2012 UDPv4 link local: [undef]
Tue Jan 24 14:28:17 2012 UDPv4 link remote: 78.55.163.6:1194
Tue Jan 24 14:29:17 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 24 14:29:17 2012 TLS Error: TLS handshake failed
Tue Jan 24 14:29:17 2012 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 24 14:29:19 2012 Re-using SSL/TLS context
Tue Jan 24 14:29:19 2012 LZO compression initialized
Tue Jan 24 14:29:19 2012 UDPv4 link local: [undef]
Tue Jan 24 14:29:19 2012 UDPv4 link remote: 78.55.163.6:1194
beim openvpncl-start erhalte ich dann TLS-Fehlermeldungen auch auf dem Server......
Zur Client-Konfiguration des DD-WRT...
Public Server Cert = CA root crt
Public Client Cert = client crt
Private Client Key = client key # alles per cut and paste aus pfSense in den DD-WRT kopiert
Wohin kommt der TLS-Key ? In den Daemon sicher nicht, habe ich mit in den "privat Client Key" kopiert.
Im DD-WRT findet sich ja auch im client.key wieder.
root@winnie:/tmp/openvpncl# ls
ca.crt client.crt client.key openvpn.conf route-down.sh route-up.sh
ca.crt client.crt client.key openvpn.conf route-down.sh route-up.sh
SPI Firewall des DD-WRT war während der Tests deaktiviert..
Gruß orcape
TLS ist nur das Schlüsselverfahren was OpenVPN nutzt.
Der Fehler: Error: TLS key negotiation failed to occur within 60 seconds ist aber eindeutig !
Du hast entweder beim Key generieren einen Fehler gemacht oder die falschen Keys konfiguriert.
Wenn du das mit Winblows gemacht hast musst du etwas aufpassen, denn dort kommt häufig mal ein cr lf mit in den Text. Siehe auch die Threads in der Folge des Tutorials !!
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da musst du wohl nochmal ran und die Keys diesmal richtig generieren !
Ggf. nimmst du die vom Windows OpenVPN Client als Text wie es im Tutorial beschrieben ist. Der Fehler ist aber klar ein falscher oder fehlerhafter Key !
Der Fehler: Error: TLS key negotiation failed to occur within 60 seconds ist aber eindeutig !
Du hast entweder beim Key generieren einen Fehler gemacht oder die falschen Keys konfiguriert.
Wenn du das mit Winblows gemacht hast musst du etwas aufpassen, denn dort kommt häufig mal ein cr lf mit in den Text. Siehe auch die Threads in der Folge des Tutorials !!
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da musst du wohl nochmal ran und die Keys diesmal richtig generieren !
Ggf. nimmst du die vom Windows OpenVPN Client als Text wie es im Tutorial beschrieben ist. Der Fehler ist aber klar ein falscher oder fehlerhafter Key !
Hi,
ja ich weiß, ich bin wieder dran.....
nach dem ich mindestens das (.....reden wir nicht mehr drüber) x.te mal mit pfSense, XCA und TinyCA
(nicht unter Winblows) Zertifikate & Key´s generiert und kopiert, anschließend Open-VPN Server und Client wieder
frisch Aufgesetzt habe, bin ich mir fast sicher das ich das jetzt einigermaßen kann.
Außer das ich in dieser Zeit auch noch von einem Netgear Switch geärgert wurde, der mir sporadisch die Verbindung
vom PC zum pfSense kappte, ist mir zumindest eines klar geworden, das diese Marke in meinem Hause in Zukunft
keine Verwendung mehr findet.
So als "Abfallprodukt" habe ich was DD-WRT angeht auch noch ein bischen in Sachen vi dazulernen müssen, denn da gibts
keinen mc oder Nano.
Aber nun zum eigentlichen Problem.
Ich bin über die Fehlermeldung hinaus nicht weitergekommen.
DD-WRT meldet mir....
Will der Client ein Passwort oder wie soll ich das interpretieren.
Außer dem Client.key (pem) befindet sich der kopierte TLS-Key aus der Serverkonfiguration in der Datei und
wieso steht in den server.logs folgende IP Port ? IP stimmt, Port nicht !
Der DD-WRT Client zeigt mir zumindest den eingestellten Port 1194.
Das Tutorial bin ich mehrmals durchgegangen, leider ohne irgeneinen Hinweis
Gruß orcape
ja ich weiß, ich bin wieder dran.....
nach dem ich mindestens das (.....reden wir nicht mehr drüber) x.te mal mit pfSense, XCA und TinyCA
(nicht unter Winblows) Zertifikate & Key´s generiert und kopiert, anschließend Open-VPN Server und Client wieder
frisch Aufgesetzt habe, bin ich mir fast sicher das ich das jetzt einigermaßen kann.
Außer das ich in dieser Zeit auch noch von einem Netgear Switch geärgert wurde, der mir sporadisch die Verbindung
vom PC zum pfSense kappte, ist mir zumindest eines klar geworden, das diese Marke in meinem Hause in Zukunft
keine Verwendung mehr findet.
So als "Abfallprodukt" habe ich was DD-WRT angeht auch noch ein bischen in Sachen vi dazulernen müssen, denn da gibts
keinen mc oder Nano.
Aber nun zum eigentlichen Problem.
Ich bin über die Fehlermeldung hinaus nicht weitergekommen.
DD-WRT meldet mir....
root@winnie:~# ncat /var/log/messages | grep openvpn
Jan 28 10:48:33 winnie daemon.warn openvpn[16883]: Cannot load private key file /tmp/openvpncl/client.key
: error:0906D06C:lib(9):func(109):reason(108): error:140B0009:lib(20):func(176):reason(9)
Jan 28 10:48:33 winnie daemon.err openvpn[16883]: Error: private key password verification failed
Jan 28 10:48:33 winnie daemon.warn openvpn[16883]: Cannot load private key file /tmp/openvpncl/client.key
: error:0906D06C:lib(9):func(109):reason(108): error:140B0009:lib(20):func(176):reason(9)
Jan 28 10:48:33 winnie daemon.err openvpn[16883]: Error: private key password verification failed
Will der Client ein Passwort oder wie soll ich das interpretieren.
Außer dem Client.key (pem) befindet sich der kopierte TLS-Key aus der Serverkonfiguration in der Datei und
wieso steht in den server.logs folgende IP Port ? IP stimmt, Port nicht !
Jan 28 14:37:48 openvpn[4520]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]92.225.226.153:2060
Der DD-WRT Client zeigt mir zumindest den eingestellten Port 1194.
Das Tutorial bin ich mehrmals durchgegangen, leider ohne irgeneinen Hinweis
Gruß orcape
Es liegt de facto am Key !
Du solltest dich nicht auf die Webeingabe verlassen sondern mit dem SSH Zugang die Key Dateien im Verzeicnis nochmal genau checken ob die identisch sind und die Dateirechte stimmen. chmod und chown
Zur Not mit rm alles wirklich sauber lschen, Router rebooten und nochmal sauber installieren bzw. Mit WinSCP reinkopieren.
Irgendwas ist de facto mit dem Transfer der Keydateien fehl gelaufen.
Eine Laborinstallation funktioniert hier absolut fehlerlos ...wie ja auch im Tutorial zusehen was eine Kopplung DD-WRT auf Monowall/pfSense beschreibt.
Du solltest dich nicht auf die Webeingabe verlassen sondern mit dem SSH Zugang die Key Dateien im Verzeicnis nochmal genau checken ob die identisch sind und die Dateirechte stimmen. chmod und chown
Zur Not mit rm alles wirklich sauber lschen, Router rebooten und nochmal sauber installieren bzw. Mit WinSCP reinkopieren.
Irgendwas ist de facto mit dem Transfer der Keydateien fehl gelaufen.
Eine Laborinstallation funktioniert hier absolut fehlerlos ...wie ja auch im Tutorial zusehen was eine Kopplung DD-WRT auf Monowall/pfSense beschreibt.
Hi,
also erst mal "Asche auf mein Haupt".
Wohl dem, der das was er liest, auch noch begreift.
Zitat aus dem Tutorial....
Also einfach mal in den DD-WRT-GUI kopieren, so wie ich mir das anfangs gedacht hatte, wäre wohl zu einfach.
Bei mir ist der WRT54 eine Linux-Variante und die betreffenden Dateien für den VPN-Client befinden sich in
Habe ich jetzt noch zusätzlich die Datei "ta.key" erstellt, deren Rechte angepaßt, den "TLS-Key" hineinkopiert
und die "openvpn.conf" entsprechend angepaßt und gespeichert.
Anschließend einen reboot des Routers und schon war die Arbeit wieder pfutsch.
Also alles noch mal, gegoogelt und....
... ist wieder alles weg. ?
Wie kriege ich die Änderungen dauerhaft im nvram gespeichert ?
Gruß orcape
also erst mal "Asche auf mein Haupt".
Wohl dem, der das was er liest, auch noch begreift.
Zitat aus dem Tutorial....
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 !
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 !
Also einfach mal in den DD-WRT-GUI kopieren, so wie ich mir das anfangs gedacht hatte, wäre wohl zu einfach.
Bei mir ist der WRT54 eine Linux-Variante und die betreffenden Dateien für den VPN-Client befinden sich in
/tmp/openvpncl
root@winnie:/tmp/openvpncl# ls
ca.crt client.crt client.key openvpn.conf route-down.sh route-up.sh
root@winnie:/tmp/openvpncl# ls
ca.crt client.crt client.key openvpn.conf route-down.sh route-up.sh
Habe ich jetzt noch zusätzlich die Datei "ta.key" erstellt, deren Rechte angepaßt, den "TLS-Key" hineinkopiert
und die "openvpn.conf" entsprechend angepaßt und gespeichert.
Anschließend einen reboot des Routers und schon war die Arbeit wieder pfutsch.
Also alles noch mal, gegoogelt und....
nvram commit
dann noch malnvram commit ta.key
nvram commit openvpn.conf
nvram commit openvpn.conf
... ist wieder alles weg. ?
Wie kriege ich die Änderungen dauerhaft im nvram gespeichert ?
Gruß orcape
Mmmhhh hab ich jetzt grad nicht auf der Pfanne aber ich meine es war "Flash save" oder sowas...müsst ich mal eben in der DD-WRT Doku nachsehen. Ich check das mal auf der Labor Kiste hier.
Hi Aqui,
ich habe hier mal beim googlen nach einer Lösung folgenden Lösungsansatz gefunden.
Hier mal der Link....
http://www.winteltosh.de/2008/12/site-to-site-openvpn-mit-linksys-wrt54 ...
Ganz so einfach ist die Sache mit dem NVRAM dann doch nicht.
Vielleicht lässt sich auf die Art das Problem in den Griff kriegen.
Gruß orcape
ich habe hier mal beim googlen nach einer Lösung folgenden Lösungsansatz gefunden.
Hier mal der Link....
http://www.winteltosh.de/2008/12/site-to-site-openvpn-mit-linksys-wrt54 ...
Ganz so einfach ist die Sache mit dem NVRAM dann doch nicht.
Vielleicht lässt sich auf die Art das Problem in den Griff kriegen.
Gruß orcape
Hi Aqui,
habe jetzt testweise einen funktionierenden Tunnel, DD-WRT -Server ------> pfSense-Client und auch pfSense-Server -------> DD-WRT-Client.
So wie DD-WRT-Server im Tutorial beschrieben war ......
Das heißt, der Tunnel funktioniert in beide Richtungen, jeweils Ping möglich.
So bald ich pfSense----> Sever TLS-Auth. aktiviere, bricht der Tunnel ab, ist aber auch logisch, weil ja im DD-WRT-Client noch nichts aktiviert ist.
TLS-Aktivierung im DD-WRT-Server funktioniert im pfSense-Client aber auch nicht ?
Es fehlt mir also nur noch die NVRAM-Lösung.
Kleiner Nachtrag......
Ohne TLS-Authentifikation läuft der Tunnel ohne Fehlermeldung, wie geplant......
pfSense-Server -------> DD-WRT-Client
nachdem ich den Encrypt Algorythmus des pfSense-Servers auf....
BF-CBC (128 Bit)
geändert habe.
Ich weiß zwar nicht welche Sicherheitseinschränkungen das mit sich bringt, aber ich denke, ich kann damit leben.
Nun fehlt mir nur noch der Zugriff aufs Remote-LAN, der trotz abgeschalteter FW des DD-WRT nicht will.
Gruß orcape
habe jetzt testweise einen funktionierenden Tunnel, DD-WRT -Server ------> pfSense-Client und auch pfSense-Server -------> DD-WRT-Client.
So wie DD-WRT-Server im Tutorial beschrieben war ......
OpenVPN TLS Auth ==>> bleibt leer !!
Einziges Manko, keine TLS-Auth. möglich.Das heißt, der Tunnel funktioniert in beide Richtungen, jeweils Ping möglich.
So bald ich pfSense----> Sever TLS-Auth. aktiviere, bricht der Tunnel ab, ist aber auch logisch, weil ja im DD-WRT-Client noch nichts aktiviert ist.
TLS-Aktivierung im DD-WRT-Server funktioniert im pfSense-Client aber auch nicht ?
Es fehlt mir also nur noch die NVRAM-Lösung.
Kleiner Nachtrag......
Ohne TLS-Authentifikation läuft der Tunnel ohne Fehlermeldung, wie geplant......
pfSense-Server -------> DD-WRT-Client
nachdem ich den Encrypt Algorythmus des pfSense-Servers auf....
BF-CBC (128 Bit)
geändert habe.
Ich weiß zwar nicht welche Sicherheitseinschränkungen das mit sich bringt, aber ich denke, ich kann damit leben.
Nun fehlt mir nur noch der Zugriff aufs Remote-LAN, der trotz abgeschalteter FW des DD-WRT nicht will.
Gruß orcape
Hi,
also Tunnel steht, Problem gelöst.
Danke noch mal an Aqui für seine Unterstützung.
Gruß orcape
also Tunnel steht, Problem gelöst.
Danke noch mal an Aqui für seine Unterstützung.
Gruß orcape
