OpenVPN Server auf DDWRT startet nicht
Hallo Community,
ich habe nach Anleitungen aus diesem Forum einen Linksys Router mit der DDWRT Firmenware geflasht und anschließend OpenVPN Schlüssel erstellt und in diesem eingebunden. Wenn ich den Serverstatus mithilfe von Putti abfrage wird der OpenVPN Diesnt/Prozes nicht angezeigt.
Was nun tun ?
Das Netz:
Ich habe ein Modem welches die Internetverbindung herstellt und dahinter den DDWRT der den VPN Server beherbergen soll, dahinter ist dann das eigentliche Netz mit Clienten, Server und Drucker:
Mit RealTimeViewer habe ich diesen Logeintrag gefunden: (Der gesammte Log steht Unten)
19/08/20011 15:57:43 Daemon Error 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Cannot open /tmp/openvpn/dh1024.pem for DH parameters:
Den Schlüssel habe ich nochmal eingefügt und auch das Feld auf richtigkeit überprüft, leider half das nicht,
Kann es sein, dass meine Server Conf falsch ist?
Server Config
port 1197
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/Name-OpenVPN.crt
key /tmp/openvpn/Name-OpenVPN.key
dh /tmp/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.128.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Ich bin für jeden Ratschlag dankbar!
Gruß Meho
RealTimeViewer Log
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth0 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device vlan0 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth1 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth1 entered promiscuous mode
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:07 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:07 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:38 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:38 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:39 User Info 192.168.128.254 Jan 1 00:00:09 syslog: wland : WLAN daemon successfully started
19/08/20011 15:57:39 User Info 192.168.128.254 Jan 1 00:00:09 syslog: cron : cron daemon successfully started
19/08/20011 15:57:39 Cron Info 192.168.128.254 Jan 1 00:00:10 cron[258]: (CRON) STARTUP (fork ok)
19/08/20011 15:57:39 Cron Info 192.168.128.254 Jan 1 00:00:10 cron[258]: (crontabs) ORPHAN (no passwd entry)
19/08/20011 15:57:41 System0 Info 192.168.128.254 Jan 1 00:00:11 dropbear[264]: Running in background
19/08/20011 15:57:43 Daemon Notice 192.168.128.254 Jan 1 00:00:13 openvpn[263]: OpenVPN 2.1_rc7 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Jul 27 2008
19/08/20011 15:57:43 Daemon Error 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Cannot open /tmp/openvpn/dh1024.pem for DH parameters: error:02001002:lib(2):func(1):reason(2): error:2006D080:lib(32):func(109):reason(128)
19/08/20011 15:57:43 Daemon Notice 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Exiting
19/08/20011 15:57:43 User Info 192.168.128.254 Jan 1 00:00:14 kernel: device vlan1 entered promiscuous mode
19/08/20011 15:57:44 User Emergency 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: Setting MAC address to c0 c1 c0 3c f2 e5.
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_promiscuity(master, 1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_allmulti(master, 1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_promiscuity(master, -1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: device vlan1 left promiscuous mode
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_allmulti(master, -1)
19/08/20011 15:57:44 User Debug 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: add 01:00:5e:00:00:01 mcast address to master interface
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:45 User Info 192.168.128.254 Jan 1 00:00:15 syslog: process_monitor successfully started
19/08/20011 15:57:46 Daemon Debug 192.168.128.254 Aug 19 15:57:58 process_monitor[313]: We need to re-update after 3600 seconds
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:53 User Info 192.168.128.254 Aug 19 15:58:05 syslog: wland : WLAN daemon successfully stopped
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: wland : WLAN daemon successfully started
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: WAN is up. IP: 192.168.130.2
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: ttraff : traffic counter daemon successfully started
19/08/20011 15:57:56 User Debug 192.168.128.254 Aug 19 15:58:08 syslog: ttraff: data collection started
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:09 syslog: klogd : klog daemon successfully stopped
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:09 syslog: syslogd : syslog daemon successfully stopped
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:10 syslog: klogd : klog daemon successfully started
19/08/20011 15:57:57 User Notice 192.168.128.254 Aug 19 15:58:10 kernel: klogd started: BusyBox v1.11.1 (2008-07-27 16:20:53 CEST)
ich habe nach Anleitungen aus diesem Forum einen Linksys Router mit der DDWRT Firmenware geflasht und anschließend OpenVPN Schlüssel erstellt und in diesem eingebunden. Wenn ich den Serverstatus mithilfe von Putti abfrage wird der OpenVPN Diesnt/Prozes nicht angezeigt.
Was nun tun ?
Das Netz:
Ich habe ein Modem welches die Internetverbindung herstellt und dahinter den DDWRT der den VPN Server beherbergen soll, dahinter ist dann das eigentliche Netz mit Clienten, Server und Drucker:
Mit RealTimeViewer habe ich diesen Logeintrag gefunden: (Der gesammte Log steht Unten)
19/08/20011 15:57:43 Daemon Error 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Cannot open /tmp/openvpn/dh1024.pem for DH parameters:
Den Schlüssel habe ich nochmal eingefügt und auch das Feld auf richtigkeit überprüft, leider half das nicht,
Kann es sein, dass meine Server Conf falsch ist?
Server Config
port 1197
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/Name-OpenVPN.crt
key /tmp/openvpn/Name-OpenVPN.key
dh /tmp/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.128.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Ich bin für jeden Ratschlag dankbar!
Gruß Meho
RealTimeViewer Log
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth0 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device vlan0 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth1 entered promiscuous mode
19/08/20011 15:57:36 User Info 192.168.128.254 Jan 1 00:00:05 kernel: device eth1 entered promiscuous mode
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:07 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:07 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:37 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:38 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:38 User Info 192.168.128.254 Jan 1 00:00:08 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:39 User Info 192.168.128.254 Jan 1 00:00:09 syslog: wland : WLAN daemon successfully started
19/08/20011 15:57:39 User Info 192.168.128.254 Jan 1 00:00:09 syslog: cron : cron daemon successfully started
19/08/20011 15:57:39 Cron Info 192.168.128.254 Jan 1 00:00:10 cron[258]: (CRON) STARTUP (fork ok)
19/08/20011 15:57:39 Cron Info 192.168.128.254 Jan 1 00:00:10 cron[258]: (crontabs) ORPHAN (no passwd entry)
19/08/20011 15:57:41 System0 Info 192.168.128.254 Jan 1 00:00:11 dropbear[264]: Running in background
19/08/20011 15:57:43 Daemon Notice 192.168.128.254 Jan 1 00:00:13 openvpn[263]: OpenVPN 2.1_rc7 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Jul 27 2008
19/08/20011 15:57:43 Daemon Error 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Cannot open /tmp/openvpn/dh1024.pem for DH parameters: error:02001002:lib(2):func(1):reason(2): error:2006D080:lib(32):func(109):reason(128)
19/08/20011 15:57:43 Daemon Notice 192.168.128.254 Jan 1 00:00:14 openvpn[263]: Exiting
19/08/20011 15:57:43 User Info 192.168.128.254 Jan 1 00:00:14 kernel: device vlan1 entered promiscuous mode
19/08/20011 15:57:44 User Emergency 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: Setting MAC address to c0 c1 c0 3c f2 e5.
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_promiscuity(master, 1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_allmulti(master, 1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_promiscuity(master, -1)
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: device vlan1 left promiscuous mode
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: dev_set_allmulti(master, -1)
19/08/20011 15:57:44 User Debug 192.168.128.254 Jan 1 00:00:14 kernel: vlan1: add 01:00:5e:00:00:01 mcast address to master interface
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:44 User Info 192.168.128.254 Jan 1 00:00:14 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:45 User Info 192.168.128.254 Jan 1 00:00:15 syslog: process_monitor successfully started
19/08/20011 15:57:46 Daemon Debug 192.168.128.254 Aug 19 15:57:58 process_monitor[313]: We need to re-update after 3600 seconds
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:52 User Info 192.168.128.254 Aug 19 15:58:04 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:53 User Info 192.168.128.254 Aug 19 15:58:05 syslog: wland : WLAN daemon successfully stopped
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : vpn modules successfully unloaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_nat_proto_gre successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_conntrack_pptp successfully loaded
19/08/20011 15:57:54 User Info 192.168.128.254 Aug 19 15:58:07 syslog: vpn modules : ip_nat_pptp successfully loaded
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: wland : WLAN daemon successfully started
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: WAN is up. IP: 192.168.130.2
19/08/20011 15:57:55 User Info 192.168.128.254 Aug 19 15:58:08 syslog: ttraff : traffic counter daemon successfully started
19/08/20011 15:57:56 User Debug 192.168.128.254 Aug 19 15:58:08 syslog: ttraff: data collection started
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:09 syslog: klogd : klog daemon successfully stopped
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:09 syslog: syslogd : syslog daemon successfully stopped
19/08/20011 15:57:57 User Info 192.168.128.254 Aug 19 15:58:10 syslog: klogd : klog daemon successfully started
19/08/20011 15:57:57 User Notice 192.168.128.254 Aug 19 15:58:10 kernel: klogd started: BusyBox v1.11.1 (2008-07-27 16:20:53 CEST)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 171781
Url: https://administrator.de/contentid/171781
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
31 Kommentare
Neuester Kommentar
Lies dir bitte das Tutorial im Abschnitt OpenVPN installieren einmal genau durch:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Und beantworte folgende Fragen bzw. poste den Output hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Und beantworte folgende Fragen bzw. poste den Output hier:
- Hast du mit SSH (Putty etc.) einen Shellzugang wie im Tutorial beschrieben aktiviert ?
- Stimmen alle Dateirechte im Verzeichnis /tmp/openvpn ? ls -l /tmp/openvpn ?
- Was sagt der Output von ps ?
- Wichtig: Was passiert wenn du OpenVPN manuell startest mit openvpn -conf /tmp/openvpn/openvpn.conf ? Startet der Dienst dann und ist er mit "ps" zu sehen ? Poste ggf. den Output hier wenn du manuell startest wie es auch im Tutorialmzusehen ist ! Anhand des Terminaloutputs kann man sofort sehen wo es kneift.
Hallo Meho,
OpenVPN startet nicht. Bei mir heißt der Parameter --config, also:
Was meinst du mit, den Schlüssel sollte nicht jeder lesen können, den hab ich doch nirgens gepostet, oder ?
Meinst du den Nemen ?
Damit meinte ich den Server-key; also /tmp/openvpn/Name-OpenVPN.key.
Grüße, Kurt
Vielen Dank
Gruß Meho
OpenVPN startet nicht. Bei mir heißt der Parameter --config, also:
openvpn --config /tmp/openvpn/openvpn.conf
Was meinst du mit, den Schlüssel sollte nicht jeder lesen können, den hab ich doch nirgens gepostet, oder ?
Meinst du den Nemen ?
Grüße, Kurt
Vielen Dank
Gruß Meho
Keine Ahnung was du da machst auf deinem DD-WRT aber wenn man die Zertifikate (oder Testzertifikate) wie im Tutorial beschrieben installierst und alles korrekt Schritt für Schritt ausführst ist der OpenVPN Dienst automatisch gestartet. Spätestens nach einem Rebbot des Routers !!
Die Fehlermeldung oben sagt aber ganz klar das deine dh1024.pem Datei kaputt ist und/oder du die vermutlich nicht richtig kopiert hast über das GUI oder WinSCP oder wie auch immer du die auf den Router bringst ?! 2te Möglichkeit du hast die falschen Dateirechte für diese Datei. ls-l und der Check im Tutorial sagen dir das auf Anhieb !
Das ist doch eindeutig und dann korrigierst du das !! Das muss man nicht mal einem Erstklässler erklären....sorry !
Du hast immer die folgenden Optionen OpenVPN einmal von Hand zu starten um die Startmeldungen von OpenVPN zu sehen. Dazu kannst du ins Verzeichnis /tmp/openvpn gehen und erstmal mit ls -l nachsehen ob alle Dateien da sind !
Dann führst du das Kommando: openvpn /tmp/openvpn/openvpn.conf aus ! Das sollte sauber starten wie auf diesem Screenshot zu sehen:
Ist das der Fall und du siehst alle korrekten Startmeldungen von OpenVPN, dann kommt der nächste Schritt und du kannst OpenVPN dann manauell als Daemon (Dienst) starten !
Das geschieht mit dem Kommando: openvpn --config /tmp/openvpn/openvpn.conf --daemon
Der folgende Screenshot zeigt dir das. Einmal "ps" wo du siehst das der Dienst nicht rennt und nach dem Starten des Dienstes wo er gestartet ist und in der Prozessliste zu sehen ist:
Das ist doch eine lächerliche Standardprozedur zum Checken, ohne das man dafür 20 Threadeinträge schreiben muss dzzzz....
Korrigier also deine dh1024.pem und gut iss !!
Die Fehlermeldung oben sagt aber ganz klar das deine dh1024.pem Datei kaputt ist und/oder du die vermutlich nicht richtig kopiert hast über das GUI oder WinSCP oder wie auch immer du die auf den Router bringst ?! 2te Möglichkeit du hast die falschen Dateirechte für diese Datei. ls-l und der Check im Tutorial sagen dir das auf Anhieb !
Das ist doch eindeutig und dann korrigierst du das !! Das muss man nicht mal einem Erstklässler erklären....sorry !
Du hast immer die folgenden Optionen OpenVPN einmal von Hand zu starten um die Startmeldungen von OpenVPN zu sehen. Dazu kannst du ins Verzeichnis /tmp/openvpn gehen und erstmal mit ls -l nachsehen ob alle Dateien da sind !
Dann führst du das Kommando: openvpn /tmp/openvpn/openvpn.conf aus ! Das sollte sauber starten wie auf diesem Screenshot zu sehen:
Ist das der Fall und du siehst alle korrekten Startmeldungen von OpenVPN, dann kommt der nächste Schritt und du kannst OpenVPN dann manauell als Daemon (Dienst) starten !
Das geschieht mit dem Kommando: openvpn --config /tmp/openvpn/openvpn.conf --daemon
Der folgende Screenshot zeigt dir das. Einmal "ps" wo du siehst das der Dienst nicht rennt und nach dem Starten des Dienstes wo er gestartet ist und in der Prozessliste zu sehen ist:
Das ist doch eine lächerliche Standardprozedur zum Checken, ohne das man dafür 20 Threadeinträge schreiben muss dzzzz....
Korrigier also deine dh1024.pem und gut iss !!
Hallo,
ich weiß, der Thread ist schon ein paar Tage alt, aber ich kämpfe gerade mit einem ähnlichen Problem...
Hab einen Netgear R7000 mit DD-wrt (kongac)
Server config
Das ist die Ausgabe auf der Konsole
Jemand ne Idee wo hier ein Fehler ist?
ich weiß, der Thread ist schon ein paar Tage alt, aber ich kämpfe gerade mit einem ähnlichen Problem...
Hab einen Netgear R7000 mit DD-wrt (kongac)
Server config
port xxx
proto tcp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 10.8.0.0 255.255.255.0
push "dhcp-options DNS 8.8.8.8"
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
root@Privat:~# openvpn /tmp/openvpn/openvpn.conf
Sun Dec 18 17:56:22 2016 OpenVPN 2.4_rc1 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Dec 18 17:56:22 2016 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Sun Dec 18 17:56:22 2016 Diffie-Hellman initialized with 2016 bit key
Sun Dec 18 17:56:22 2016 TUN/TAP device tun0 opened
Sun Dec 18 17:56:22 2016 TUN/TAP TX queue length set to 100
Sun Dec 18 17:56:22 2016 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Dec 18 17:56:22 2016 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Dec 18 17:56:22 2016 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Dec 18 17:56:22 2016 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Sun Dec 18 17:56:22 2016 Cannot create TCP socket: Address family not supported by protocol (errno=97)
Sun Dec 18 17:56:22 2016 Exiting due to fatal error
Sun Dec 18 17:56:22 2016 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
Sun Dec 18 17:56:22 2016 Closing TUN/TAP interface
Sun Dec 18 17:56:22 2016 /sbin/ifconfig tun0 0.0.0.0
Jemand ne Idee wo hier ein Fehler ist?
Und "push "dhcp-options DNS 8.8.8.8" " machen nur ziemliche Dummies deren ihre privatsphäre nix mehr wert ist. Das Google dann die Gewohnheiten in ein Profil packt ist. Klar....
Sowas an seine Clients zu pushen ist völliger Blödsinn in der OVPN Konfig !
Wenn dann den lokalen DNS oder den des Providers (Router) niemals aber Google !
Sowas an seine Clients zu pushen ist völliger Blödsinn in der OVPN Konfig !
Wenn dann den lokalen DNS oder den des Providers (Router) niemals aber Google !
Müsste es dann nicht "proto tcp-server" heißen?
Nein das ist schon richtig. Siehe hier:https://openvpn.net/index.php/open-source/documentation/howto.html#examp ...
Den fatalen Fehler den der TO aber macht ist TCP Encapsulation zu nutzen. Das ist so gut wie immer tödlich und sollte man niemals machen, das das den Tunneloverhead unnötigerweise erhöht und weitere Probleme mit der MTU gibt.
Das OVPN Manual rät deshalb auch aus guten Grund dringenst davon ab und immer wenn nur irgend möglich mit UDP Encapsulation zu fahren wie der Standard.
Es ist also recht kontraproduktiv TCP zu nutzen. Besser ist und auch syntaktisch korrekt:
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 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
Das wäre eine sinnvolle Minimalkonfig. Siehe auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Wobei hier noch zu beachten ist das der TO mit push redirect.. sein komplettes Default Gateway auf dem Client Rechner in den Tunnel biegt.
Sinnvoller für den Test ist hier erstmal nur das lokale Server LAN zu nehmen mit push route...
Wichtig ist dass ich ovpn mal zum laufen bekomme
Sollte mit der o.a. Konfig fehlerlos klappen.Sonst zum Troubleshooting hier immer den Logauszug vom Server und Client posten beim Sessionaufbau !
Danke für die Antworten!
@aqui Ich hab mal C&P mit deiner Config gemacht, leider das selbe Problem
Hier die Terminal ausgabe
@aqui Ich hab mal C&P mit deiner Config gemacht, leider das selbe Problem
Hier die Terminal ausgabe
root@Privat:~# openvpn /tmp/openvpn/openvpn.conf
Mon Dec 19 16:37:19 2016 OpenVPN 2.4_rc1 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Dec 19 16:37:19 2016 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Mon Dec 19 16:37:19 2016 Diffie-Hellman initialized with 2016 bit key
Mon Dec 19 16:37:19 2016 TUN/TAP device tun0 opened
Mon Dec 19 16:37:19 2016 TUN/TAP TX queue length set to 100
Mon Dec 19 16:37:19 2016 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Dec 19 16:37:19 2016 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Mon Dec 19 16:37:19 2016 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Mon Dec 19 16:37:19 2016 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Mon Dec 19 16:37:19 2016 UDP: Cannot create UDP/UDP6 socket: Address family not supported by protocol (errno=97)
Mon Dec 19 16:37:19 2016 Exiting due to fatal error
Mon Dec 19 16:37:19 2016 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
Mon Dec 19 16:37:19 2016 Closing TUN/TAP interface
Mon Dec 19 16:37:19 2016 /sbin/ifconfig tun0 0.0.0.0
root@Privat:~#
Hier die Terminal ausgabe
Fatal error...ist ja klar das da nicht laufen kann !!!Das sieht so aus als ob der OpenVPN Prozess noch rennt ?! Kann das sein ??
Hast du mal vorher ps eingegeben und geprüft ob da noch ein OVPN Daemon läuft ??
Den musst du vorher mit kill <prozess_nr> stoppen !!!
Erst dann kannst du manuell den neuen OVPN Prozess starten ! Ansonsten versucht sich der neue Daemon über den Laufenden zu starten was natürlich sofort fehlschlägt wie oben bei dir zu sehen.
Der Output muss dann mit einer "Initialization Sequence Completed" Message abschliessen. Erst dann ist alles sauber !
Siehe auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Scheinbar wohl nicht, denn der Router sagt ja das er nicht erkennen kann für welches Protokoll es genutzt wird und sich dann für IPv6 entscheidet was dann prompt in die Hose geht.
Der Blick ins Handbuch sagt dir aber das du IPv4 im Setup erzwingen kannst:
To enforce only IPv4, you need to use --udp4, --tcp4-client or --tcp4-server;
Wenn du also:
proto udp4
in deine Konfig packst sollte er IPv4 erzwingen und starten !
Der Blick ins Handbuch sagt dir aber das du IPv4 im Setup erzwingen kannst:
To enforce only IPv4, you need to use --udp4, --tcp4-client or --tcp4-server;
Wenn du also:
proto udp4
in deine Konfig packst sollte er IPv4 erzwingen und starten !
Mit proto udp4 gehts (wenn ich Manuell starte) - hatte ich zwar selbst am Anfang mal probiert, da gings nicht aber jetzt gehts.
Jedoch habe ich bei Status keine anzeige drinnen (also kein Success o.Ä.)
Muss hier noch der Pfad fürs pid-file, log usw. angepasst werden (wie in den Server -> Fixed Parameters @ DD-Wrt)?
Jedoch habe ich bei Status keine anzeige drinnen (also kein Success o.Ä.)
Muss hier noch der Pfad fürs pid-file, log usw. angepasst werden (wie in den Server -> Fixed Parameters @ DD-Wrt)?
aber jetzt gehts.
Das hört sich doch schon mal sehr gut an Jedoch habe ich bei Status keine anzeige drinnen
Welche Status Anzeige ??Wenn du den OVPN testweise manuell startest gibts da keinen Status logischerweise.
Dann siehst du doch am Konsolen Output ob da als letzter Satz "Initialization Sequence Completed", oder ?
Ist das der Fall renn der Daemon fehlerfrei und staertet nach einem Reboot fehlerfrei.
Das manuelle Starten dient nur dazu zu checken ob der Daemon sauber hochkommt und die Konfig OK ist.
Danach rebootest du die Kiste und der Daemon wird ja durch System dann gestartet, was du mit "ps" ja auch checken kannst ob er rennt.
Dann mit dem Client eine Connection versuchen und hier wieder das Log beobachten. Wenn der auch ohne Errormeldung startet und nach einem route print den Tunnel und die Route darein anzeigt ist alles bella mit den VPN und OpenVPN !!
Im Terminal startet OpenVPN korrekt
Perfekt...sieht gut aus !Die Status Anzeige ist hier auf einem WRT-54 auch leer aber OVPN rennt fehlerlos !
Sieht nach einem kosmetischen Bug aus.
Leider wird OVPN beim Reboot nicht mitgestartet
Mmmmhhh das ist komisch !! Beim WRT-54 rennt das hier fehlerfrei.Hast du auch den OVPN Dienst im Setup aktiviert ??
Habs in der Zwischenzeit hinbekommen...
1. kongac router update - hat den autostart vom ovpn daemon gefixt
2. die ovpn conf um folgenden Syntax ergänzt management 127.0.0.1 14
Meine aktuelle config schaut nun so aus
Firewall sieht so aus (aus dem HowTo)
Was mir jetzt nur noch fehlt, nachdem der ganze Traffic (Client <-> Server) über den Tunnel läuft dass vom Tunnel über das WAN vom Router ins WWW geroutet wird.
Wie soll denn das hier aussehen?
1. kongac router update - hat den autostart vom ovpn daemon gefixt
2. die ovpn conf um folgenden Syntax ergänzt management 127.0.0.1 14
Meine aktuelle config schaut nun so aus
port 1194
proto udp4
dev tun0
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
mute 3
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
fast-io
passtos
writepid /var/run/openvpnd.pid
log-append /var/log/openvpn
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
ifconfig-pool-persist /tmp/openvpn/ip-pool 86400
iptables -I INPUT 1 -p tcp --dport 443 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
Wie soll denn das hier aussehen?
Habs in der Zwischenzeit hinbekommen...
Klasse, Glückwunsch ! dass vom Tunnel über das WAN vom Router ins WWW geroutet wird.
Ächz....das versteht keiner Bitte nochmal genauer ! Soviel ist jetzt verstanden...
- OVPN Server steht bei dir im lokalen Netz hinter einem NAT Router !
- Client ist irgendwo im Internet
- Gesamter Traffic soll vom Client über den OVPN Server via dem Router davor ins Internet, richtig ?
OK, im Grunde ist es ganz einfach....
Der Client schiebt so oder so alles in den Tunnel wenn der aktiv ist. Das kannst du ja mit Traceroute auch wunderbar sehen.
Dein OVPN Router braucht einzig nur eine Default Route auf den davorliegenden NAT Router.
Dieser braucht lediglich einen statische Route auf das 10.8.0.0 /24 Netz via next Hop lolae OVPN Server IP im LAN.
Das wars...
Du willst also quasi sowas wie einen sicheren Tunnel schaffen für deinen Client wenn du mal an öffentlichen Hotspots oder sowas bist, richtig ?
ExaktBsp. Client ist irgendwo im www -> Tunnelverbindung ist aufrecht -> Wenn ich jetzt beim Client http://www.wieistmeineip.at aufrufe soll die ip vom OVPN Server (die öffentliche IP vom Router=OVPN Server) angezeigt werden
So wie ich das aus dem Wiki verstanden habe, sollte das ca. so aussehen
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Das geht auch, dann machst du NAT am Tunnelinterface, sprich übersetzt das komplette interne VPN Netzwerk 10.8.0.0 auf die LAN IP Adresse des OVPN Servers.
Damit tauchen dann der gesamte Client Traffic mit der lokalen OVPN Server LAN IP Adresse im lokalen Netzwerk auf so das er aussieht wie lokaler Traffic.
Das Masquerading ersetzt die Source IP (Absender IP, -s Parameter) im Paket mit der IP des eth0 Interfaces (-o = output) und gaukelt dem lokalen Router dann so lokalen Traffic vor.
Billige Consumer Router wie häufig die billigen Zwangsrouter von providern NATen oft nur IP Pakete des lokalen LANs aber keine die andere IP Absenderadressen haben. In so einem Fall ist das o.a. Masquerading dann auch zwingend.
Damit ersparst du dir dann sämtliche statischen Routen.
Geht natürlich auch und funktioniert ebenso, wie auch der andere Weg.
Beides ist richtig !
Das ist natürlich Blödsinn !! Denk mal ein bischen nach bitte !!!
Die Original Absender IP des Clients ist 10.8.0.x die wird dann wenn du das o.a. iptables Masquerading im Tunnel aktivierst am Server auf dessen lokale eth0 IP Adresse gewandelt also eine 192.168.128.x IP aus deinem lokalen LAN.
Damit taucht sie in deinem lokalen LAN auf.
Diese geht jetzt durch den Internet Router davor und wird dann dort nochmals per NAT auf die öffentliche Provider IP gewandelt die dein Router da am DSL/WAN Interface hat. Diese IP siehst du dann bei wieistmeineip
Private RFC 1918 IP Adressen wie die 10er oder 192.168er IP wirst du niemals sehen, denn diese werden im Internet gar nicht geroutet, sind dort also folglich inexistent als IP Netze !
Kannst du dann ganz einfach mal verifizieren wenn du den Tunnel stoppst. Dann geht dein Client über das lokale Internet raus in dem Netz wo er sich befindet und hat dann mit einmal bei wieistmeineip eine ganz andere Absender IP.
Noch plastischer zeigt dir das ein Traceroute (tracert) auf die 8.8.8.8 z.B.
Da siehst du dann logischerweise mit und ohne VPN Tunnel völlig andere Routing Wege ins Ziel
Damit tauchen dann der gesamte Client Traffic mit der lokalen OVPN Server LAN IP Adresse im lokalen Netzwerk auf so das er aussieht wie lokaler Traffic.
Das Masquerading ersetzt die Source IP (Absender IP, -s Parameter) im Paket mit der IP des eth0 Interfaces (-o = output) und gaukelt dem lokalen Router dann so lokalen Traffic vor.
Billige Consumer Router wie häufig die billigen Zwangsrouter von providern NATen oft nur IP Pakete des lokalen LANs aber keine die andere IP Absenderadressen haben. In so einem Fall ist das o.a. Masquerading dann auch zwingend.
Damit ersparst du dir dann sämtliche statischen Routen.
Geht natürlich auch und funktioniert ebenso, wie auch der andere Weg.
Beides ist richtig !
Wenn ich jetzt beim Client http://www.wieistmeineip.at aufrufe soll die ip vom OVPN Server (die öffentliche IP vom Router=OVPN Server) angezeigt werden
Nein !Das ist natürlich Blödsinn !! Denk mal ein bischen nach bitte !!!
Die Original Absender IP des Clients ist 10.8.0.x die wird dann wenn du das o.a. iptables Masquerading im Tunnel aktivierst am Server auf dessen lokale eth0 IP Adresse gewandelt also eine 192.168.128.x IP aus deinem lokalen LAN.
Damit taucht sie in deinem lokalen LAN auf.
Diese geht jetzt durch den Internet Router davor und wird dann dort nochmals per NAT auf die öffentliche Provider IP gewandelt die dein Router da am DSL/WAN Interface hat. Diese IP siehst du dann bei wieistmeineip
Private RFC 1918 IP Adressen wie die 10er oder 192.168er IP wirst du niemals sehen, denn diese werden im Internet gar nicht geroutet, sind dort also folglich inexistent als IP Netze !
Kannst du dann ganz einfach mal verifizieren wenn du den Tunnel stoppst. Dann geht dein Client über das lokale Internet raus in dem Netz wo er sich befindet und hat dann mit einmal bei wieistmeineip eine ganz andere Absender IP.
Noch plastischer zeigt dir das ein Traceroute (tracert) auf die 8.8.8.8 z.B.
Da siehst du dann logischerweise mit und ohne VPN Tunnel völlig andere Routing Wege ins Ziel
Ich glaube ich drücke mich immer wieder einwenig unglücklich aus da dass was ich sagen will nicht so ankommt wie ich es meine....
Meine Firewall hab ich mal mit dem o.a. Syntax ergänzt, leider komme ich als client, mit dem Tunnel verbunden, nicht ins www. Auf z.B. das WebIf vom Router hab ich zugriff...
Meine Firewall hab ich mal mit dem o.a. Syntax ergänzt, leider komme ich als client, mit dem Tunnel verbunden, nicht ins www. Auf z.B. das WebIf vom Router hab ich zugriff...
da dass was ich sagen will nicht so ankommt wie ich es meine....
Oder wir sind hier zu blöd und verstehen es immer falsch...?!leider komme ich als client, mit dem Tunnel verbunden, nicht ins www.
Was sagt denn ein Pathping oder Traceroute (tracert) ?? Wo bleibt der hängen ?Weiterer wichtiger Test:
Hänge mal einen lokalen Rechner ins lokale LAN am OVPN Server und starte darauf einen Wireshark.
Dann pingst du diesen Rechner vom OVPN Client mal an.
Welche Absender IP hat der ICMP Ping ??
Ist ja der gleiche Unterbau wie bei DD-WRT.
Bleibt also nur die Vermutung das du im DD-WRT etwas falsch gemacht hast, denn damit rennt es erwiesenermaßen auch vollkommen problemlos.
Aber gut wenns nun rennt...wenn auch über den Tomatenumweg !
Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Bleibt also nur die Vermutung das du im DD-WRT etwas falsch gemacht hast, denn damit rennt es erwiesenermaßen auch vollkommen problemlos.
Aber gut wenns nun rennt...wenn auch über den Tomatenumweg !
Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !