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
GELÖST

DD-WRT Router als Client in OpenVPN + Internet über VPN geht nicht

Frage Netzwerke Router & Routing

Mitglied: traller

traller (Level 1) - Jetzt verbinden

10.02.2015, aktualisiert 24.02.2015, 1765 Aufrufe, 37 Kommentare

Hallo,
ich möchte, dass ein DD-WRT Router sich von extern in ein VPN einwählt und über dieses dann LAN Zugriff hat und auch die Internetverbindung über das VPN geroutet wird. Das die Internetverbindung auch über das VPN geht, habe ich schon mit normalen Windows 7 Clients wie folgt hin bekommen:
01.
dev tun 
02.
client 
03.
proto udp 
04.
remote server.de 1194 
05.
<ca> 
06.
</ca> 
07.
<cert> 
08.
</cert> 
09.
<key> 
10.
</key> 
11.
key-direction 1 
12.
<tls-auth> 
13.
</tls-auth> 
14.
cipher AES-256-CBC 
15.
auth SHA512 
16.
resolv-retry infinite 
17.
route-method exe 
18.
route-delay 30 
19.
route-metric 512 
20.
route 0.0.0.0 0.0.0.0 
21.
nobind 
22.
persist-key 
23.
persist-tun 
24.
comp-lzo 
25.
verb 3
die Server-Config sieht so aus:
01.
dev tun 
02.
proto udp 
03.
port 1194 
04.
ca /etc/openvpn/certificates/ca.crt 
05.
cert /etc/openvpn/certificates/pi.crt 
06.
key /etc/openvpn/certificates/pi.key 
07.
dh /etc/openvpn/certificates/dh2048.pem 
08.
tls-auth /etc/openvpn/certificates/ta.key 0 
09.
user nobody 
10.
group nogroup 
11.
server 10.0.1.0 255.255.255.0 
12.
cipher AES-256-CBC 
13.
auth SHA512 
14.
persist-key 
15.
persist-tun 
16.
keepalive 2 1200 
17.
status /var/log/openvpn-status.log 
18.
verb 1 
19.
push "redirect-gateway def1" 
20.
push "dhcp-option DNS 192.168.2.1" 
21.
push "route 192.168.2.0 255.255.255.0" 
22.
log-append /var/log/openvpn 
23.
comp-lzo
Im Client-DD-WRT Router habe ich folgendes konfiguriert:
01.
Start OpenVPN Client Enable 
02.
Server IP server.de 
03.
Port 1194 
04.
Tunnel Device TUN 
05.
Tunnel Protocol UDP 
06.
Encryption Cipher AES-256-CBC 
07.
Hash Algorithm SHA512 
08.
User Pass Authentication Disable 
09.
Advance Options Enable 
10.
TLS Cipher None 
11.
LZO Compression Adaptive 
12.
NAT Enable 
13.
Firewall Protection Disable 
14.
keine IP Adresse / Subnet Mask 
15.
Tunnel MTU setting 1500 
16.
Tunnel UDP Fragment nichts 
17.
Tunnel UDP MSS-Fix Disable 
18.
kein nsCertType verification
Dann natürlich die ganzen Zertifikate und als Additional Config:
01.
route-method exe 
02.
route-delay 30 
03.
route-metric 512 
04.
route 0.0.0.0 0.0.0.0
Beim DD-WRT Router komme ich so zwar in das interne LAN, aber für das Internet zeigt er mir die falsche IP an. Dementsprechend geht das Internet nicht über das VPN Wo ist der Fehler??
37 Antworten
Mitglied: aqui
11.02.2015, aktualisiert um 09:30 Uhr
Generell ist das problemlos möglich. Und sehr hilfreich wäre mal gewesen wenn du die Routing Tabelle (netstat -r) bei aktivem Tunnel hier gepostet hättest Ohne diese wirklichen sinnvollen Outputs des Client muss man leider vieles erraten...
Du musst am Server die conf Datei so einstellen das das Default Gateway zentral über den Tunnel geroutet wird (Gateway redirect), damit landet dann jeglicher Traffic im VPN Tunnel wie du es willst.
Wie das geht steht hier:
https://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Schlüssel zum Erfolg ist also das Kommando push "redirect-gateway def1" in der Server Conf.

Alles andere zum Thema OpenVPN auf DD-WRT beantwortet dir wie immer dieses Forums Tutorial:
http://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...
Noch ein Tip: Die Tunnel MTU auf 1500 zu setzen ist tödlich und führt fast immer zum Scheitern des VPN. Ist ja auch lgisch, denn wenn du dir vorstellst das du die Tunnel MTU schon auf den max. möglichen Wert gesetzt hast und jetzt z.B. noch eine PPPoE Encapsulation bei DSL dazukommt übersteigt das die max. mögliche MTU bei Ethernet und es kommt zum Sessionabbruch.
Was hat dich also geritten diesen Unsinn zu konfigurieren ? Wenn dann sollte die MTU immer kleiner sein 1416 oder sowas. Besser erstmal allen überflüssigen Unsinn der nicht in der Konfig sein muss weglassen ! Halte dich an das Tutorial und lese mal etwas über die Grundlagen von Ethernet und seinen MTU Sizes !!
Bitte warten ..
Mitglied: orcape
11.02.2015 um 10:35 Uhr
Die Tunnel MTU auf 1500 zu setzen ist tödlich und führt fast immer zum Scheitern des VPN.
Zu seiner Ehrenrettung muss ich sagen, das die pfSense automatisch eine MTU 1500 setzt.
Nur wenn ich das explizit unter advenced so einrichte, funktioniert es auch mit der richtigen MTU-Einstellung.
Meine Tunnel machen seit nunmehr fast 3 Jahren auch mit der MTU 1500 Null Probleme.
Gruß orcape
Bitte warten ..
Mitglied: aqui
11.02.2015 um 10:42 Uhr
Ich denke das ist ein Anzeigefehler, denn die Tunnel MTU bei VPN ist / muss immer kleiner sein als die max. MTU sonst besteht eben die Gefahr eines Abbruchs. Vermutlich machen das all die Geräte zeigen es aber nicht oder falsch an.
Häufig merkt man es auch nicht weil die Durchschnittsgröße der verwendeten Pakete oft om Bereich 80 bis 200 liegt so das man die max. MTU nicht erreicht. Das ändert sich dann häufig erst bei Filetransfers wo es dann zu Abbrüchen kommt oder die gar nicht klappen oder auch einige Websites die nicht angezeigt werden. Ursache ist dann die MTU wie hier beschrieben.
Bitte warten ..
Mitglied: traller
11.02.2015 um 14:28 Uhr
Zitat von aqui:
Schlüssel zum Erfolg ist also das Kommando push "redirect-gateway def1" in der Server Conf.


irgendwie funktioniert es nun. Das Problem hing damit zusammen: DD-WRT übernimmt den push "redirect-gateway def1" aus der server.conf nicht. In der Client.conf auf dem DD-WRT musste ich das redirect-gateway manuell eintragen. Eventuell könnte man das in dem Wissen-Artikel ja ergänzen ...
Bitte warten ..
Mitglied: orcape
LÖSUNG 11.02.2015, aktualisiert 24.02.2015
Hi,
@aqui
Die pfSense als OpenVPN-Server braucht unter Advanced configuration explizit einen Eintrag der MTU-Größe <1500.
Sonst wird automatisch ein Tunnel mit MTU 1500 aktiviert.
Die empfohlene Größe ist nach meinen jetzigen Recherchen...
tun-mtu 1432
Der Tunnel steht zwar auch mit MTU 1500 stabil und bricht nicht ab.
Es führt aber teils dazu, das man auf das remote Netz zwar kommt, größere Dateien aber nicht angezeigt werden.
Betrifft z.B. den Zugriff auf einen remoten PC per ssh-Konsole und den Aufruf größerer Dateien, mc, etc..
Mir ist das jetzt erst auf einem remoten Anschluss aufgefallen, der vor kurzem auf DSLite umgestellt wurde.
Bis dahin gab es mit dem Anschluss diese Probleme nicht.
Gruß orcape
Bitte warten ..
Mitglied: aqui
11.02.2015, aktualisiert um 20:40 Uhr
explizit einen Eintrag der MTU-Größe <1500.
Mein Reden....

@traller
Hier funktionierts auf dem DD-WRT problemlos mit dem Redirect. Aber egal wenns nun alles klappt wie es soll ist ja gut !
Bitte dann auch
http://www.administrator.de/faq/32
nicht vergessen !
Bitte warten ..
Mitglied: traller
20.02.2015 um 09:52 Uhr
Hallo,
ich muss das noch einmal aus der Versenkung holen. Ich teste es gerade von einem anderem DSL Anschluss aus. Soweit funktioniert es auch. Nur der DSL an dem ich bin und von VPN-Server besitzen eine DSL Zwangstrennung nach 24h. Wenn der IP-Wechsel kommt, steht im Log nur "Can not resolve host" und macht dann irgendwann nichts mehr. Natürlich muss sich der Host erst aktualisieren. Wie bekomme ich es hin, dass weiterhin Verbindungsversuche unternommen werden, bis er halt wieder connected ist?
Die Config des VPN-Servers ist folgende:
01.
dev tun 
02.
proto udp 
03.
port 1194 
04.
ca /etc/openvpn/certificates/ca.crt 
05.
cert /etc/openvpn/certificates/pi.crt 
06.
key /etc/openvpn/certificates/pi.key 
07.
dh /etc/openvpn/certificates/dh4096.pem 
08.
tls-auth /etc/openvpn/certificates/ta.key 0 
09.
user nobody 
10.
group nogroup 
11.
server 10.0.1.0 255.255.255.0 
12.
cipher AES-256-CBC 
13.
auth SHA512 
14.
persist-key 
15.
persist-tun 
16.
keepalive 10 120 
17.
status /var/log/openvpn-status.log 
18.
verb 1 
19.
client-to-client 
20.
push "redirect-gateway def1" 
21.
push "dhcp-option DNS 192.168.0.1" 
22.
push "route 192.168.0.0 255.255.255.0" 
23.
log-append /var/log/openvpn 
24.
comp-lzo
beim DD-WRT Client-Router:
01.
Server IP/Name: host.adresse.de 
02.
Port: 1194 
03.
Tunnel device: tun 
04.
Tunnel Protocol: udp 
05.
Cipher: AES-256-CBC 
06.
Hash: SHA512 
07.
User Pass Authentication: Disable 
08.
Advanced Options: Enable 
09.
TLS Cipher: None 
10.
LZO Compression Adaptive 
11.
NAT: Enable 
12.
Firewall Protection: disable 
13.
Ip Address: 
14.
Subnet Mask: 
15.
Tunnel MTU Setting: 1500 
16.
Tunnel UDP Fragment: 
17.
Tunnel UDP MSS-Fix: Disable 
18.
nsCertType verification: nichts 
19.
 
20.
Additional Config: 
21.
redirect-gateway def1 
22.
dhcp-option DNS 192.168.0.1
Bitte warten ..
Mitglied: orcape
20.02.2015 um 10:24 Uhr
Nur der DSL an dem ich bin und von VPN-Server besitzen eine DSL Zwangstrennung nach 24h.
Wo liegt das Problem ?
Nur die Server-Seite braucht dann einen eingerichteten DynDNS-Eintrag und gut ist es.
Der DynDNS-Account (z.B. herbert.no-ip.org) wird noch in Deiner Client-config eingetragen und schon initiert der Client die Verbindung wieder, da er die Serveradresse nun kennt, wenn der OpenVPN-Server läuft natürlich.
Also kein Thema.
Gruß orcape
Bitte warten ..
Mitglied: traller
20.02.2015 um 13:16 Uhr
Zitat von orcape:

> Nur der DSL an dem ich bin und von VPN-Server besitzen eine DSL Zwangstrennung nach 24h.
Wo liegt das Problem ?
Nur die Server-Seite braucht dann einen eingerichteten DynDNS-Eintrag und gut ist es.
Der DynDNS-Account (z.B. herbert.no-ip.org) wird noch in Deiner Client-config eingetragen und schon initiert der Client die
Verbindung wieder, da er die Serveradresse nun kennt, wenn der OpenVPN-Server läuft natürlich.
Also kein Thema.
Gruß orcape

bei der Adresse liegt ja ein DynDNS-Eintrag vor und deshalb wundert mich das selbst ... eventuell hat der sich nicht schnell genug aktualisiert und der Client-Router bricht dann irgendwann ab???
Bitte warten ..
Mitglied: orcape
20.02.2015 um 13:26 Uhr
bei der Adresse liegt ja ein DynDNS-Eintrag vor und deshalb wundert mich das selbst ... eventuell hat der sich nicht schnell genug aktualisiert und der Client-Router bricht dann irgendwann ab???
Einen Provider-Zwangsrouter hast Du nicht zufällig in der Routerkaskade auf der Serverseite noch davor hängen ?
Bitte warten ..
Mitglied: traller
20.02.2015 um 14:45 Uhr
Zitat von orcape:

> bei der Adresse liegt ja ein DynDNS-Eintrag vor und deshalb wundert mich das selbst ... eventuell hat der sich nicht schnell
genug aktualisiert und der Client-Router bricht dann irgendwann ab???
Einen Provider-Zwangsrouter hast Du nicht zufällig in der Routerkaskade auf der Serverseite noch davor hängen ?

auf Clientseite sind aktuell 2 Router davor. Auf der Serverseite ist einer vor dem Server, Portweiterleitung eingerichtet. Server ist ein Linux-Server ... hilft es was, dass auf dem Router auf Serverseite einzurichten? Ist nämlich auch ein DD-WRT, würde ich aber ungern machen wollen, wenn es nicht auch anders geht.
Bitte warten ..
Mitglied: orcape
20.02.2015, aktualisiert um 15:45 Uhr
Auf der Serverseite ist einer vor dem Server, Portweiterleitung eingerichtet.
Der DynDNS-Eintrag gehört auf den ersten Router, sonst wird die IP nicht aktualisiert.
Es gib da Ausnahmen, durch DD-WRT wird das aber nicht unterstützt.
Wenn das Dein erster Router nicht kann, hast Du erst mal ein Problem.
hilft es was, dass auf dem Router auf Serverseite einzurichten?
Klares Nein...
Bitte warten ..
Mitglied: traller
20.02.2015 um 16:07 Uhr
Zitat von orcape:

> Auf der Serverseite ist einer vor dem Server, Portweiterleitung eingerichtet.
Der DynDNS-Eintrag gehört auf den ersten Router, sonst wird die IP nicht aktualisiert.
Es gib da Ausnahmen, durch DD-WRT wird das aber nicht unterstützt.
Wenn das Dein erster Router nicht kann, hast Du erst mal ein Problem.

wieder ien Verständnisdilemma: die obige Situation gilt für den VPN Gateway. Dyndns wird vom richtigen Router aktualisiert und funktioniert ...
Bitte warten ..
Mitglied: orcape
20.02.2015 um 16:12 Uhr
wieder ien Verständnisdilemma: die obige Situation gilt für den VPN Gateway.
..welches uns erspart bleibt, wenn dafür hier eine kleine Zeichnung mit entsprechenden Bezeichnungen, IP-Daten, etc. hier schon mal am Anfang des Threads gepostet wird.
Bitte warten ..
Mitglied: traller
20.02.2015 um 16:22 Uhr
Zitat von orcape:

> wieder ien Verständnisdilemma: die obige Situation gilt für den VPN Gateway.
..welches uns erspart bleibt, wenn dafür hier eine kleine Zeichnung mit entsprechenden Bezeichnungen, IP-Daten, etc. hier
schon mal am Anfang des Threads gepostet wird.

das meinte ich ja mit "funktioniert" schon :p
Problem ist ja nur, dass der Client keine unendlichen Einwahlversuche unternimmt. Das müsste er aber, da es natürlich dauern kann, bis sich die IP etc. aktualisiert hat ...
Bitte warten ..
Mitglied: orcape
20.02.2015, aktualisiert um 16:35 Uhr
Problem ist ja nur, dass der Client keine unendlichen Einwahlversuche unternimmt. Das müsste er aber, da es natürlich dauern kann, bis sich die IP etc. aktualisiert hat ...
..genau, das muss er, sonst ist irgend etwas an der config nicht so, wie es notwendig ist.

Wenn Du den OVPN-Server abschaltest und wieder zuschaltest, muss sich der Tunnel immer wieder neu aktivieren, egal wie lange der Server abgeschaltet ist.
Bitte warten ..
Mitglied: traller
20.02.2015 um 16:33 Uhr
Zitat von orcape:

> Problem ist ja nur, dass der Client keine unendlichen Einwahlversuche unternimmt. Das müsste er aber, da es
natürlich dauern kann, bis sich die IP etc. aktualisiert hat ...
..genau, das muss er, sonst ist irgend etwas an der config nicht so, wie es notwendig ist.

genau, und da ist die Frage was und da fehlt mir die Kenntnis für ;)
Bitte warten ..
Mitglied: orcape
20.02.2015 um 16:47 Uhr
Wenn der Tunnel unterbrochen ist, kannst Du den am Client händisch starten, per ssh oder telnet mit....
openvpn /tmp/openvpncl/openvpn.conf
Lies Dir dazu mal das Tutorial von @aqui genau durch....
http://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-r ...
...irgend eine Meldung muss da auftauchen, die Aufschluß über Dein Problem gibt.
Bitte warten ..
Mitglied: traller
20.02.2015 um 16:47 Uhr
Zitat von orcape:

> Problem ist ja nur, dass der Client keine unendlichen Einwahlversuche unternimmt. Das müsste er aber, da es
natürlich dauern kann, bis sich die IP etc. aktualisiert hat ...
..genau, das muss er, sonst ist irgend etwas an der config nicht so, wie es notwendig ist.

Wenn Du den OVPN-Server abschaltest und wieder zuschaltest, muss sich der Tunnel immer wieder neu aktivieren, egal wie lange der
Server abgeschaltet ist.

da würde sich dann ja ein Script mit Ping-Abfrage anbieten, dass das dann auf dem DD-WRT-Client ausführt ... soll ja automatisch funktionieren ...
Bitte warten ..
Mitglied: orcape
20.02.2015 um 16:49 Uhr
da würde sich dann ja ein Script mit Ping-Abfrage anbieten, dass das dann auf dem DD-WRT-Client ausführt ... soll ja automatisch funktionieren ...
..das muss auch ohne Script funktionieren, sonst ist in Deiner Config was Faul....
Bitte warten ..
Mitglied: traller
20.02.2015 um 16:50 Uhr
Zitat von orcape:

> da würde sich dann ja ein Script mit Ping-Abfrage anbieten, dass das dann auf dem DD-WRT-Client ausführt ... soll
ja automatisch funktionieren ...
..das muss auch ohne Script funktionieren, sonst ist in Deiner Config was Faul....

ok, sobald der Fehler wieder auftritt, werde ich das mal protokollieren ...
Bitte warten ..
Mitglied: traller
21.02.2015, aktualisiert um 01:09 Uhr
Zitat von orcape:

> da würde sich dann ja ein Script mit Ping-Abfrage anbieten, dass das dann auf dem DD-WRT-Client ausführt ... soll
ja automatisch funktionieren ...
..das muss auch ohne Script funktionieren, sonst ist in Deiner Config was Faul....

ich hab den Fehler wohl lokalisieren können, weiß aber nicht wie ich ihn behebe. Es ist ein Fehler bei der DNS-Auflösung. Das Protokoll unter Status>OpenVPN zeigt folgendes an:
01.
20150221 00:57:34 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again 
02.
20150221 00:57:44 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again 
03.
20150221 00:57:54 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again 
04.
20150221 00:58:04 NOTE: --mute triggered... 
05.
20150221 00:58:14 2 variation(s) on previous 3 message(s) suppressed by --mute 
06.
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
07.
20150221 00:58:14 D MANAGEMENT: CMD 'state' 
08.
20150221 00:58:14 MANAGEMENT: Client disconnected 
09.
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
10.
20150221 00:58:14 D MANAGEMENT: CMD 'state' 
11.
20150221 00:58:14 MANAGEMENT: Client disconnected 
12.
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
13.
20150221 00:58:14 D MANAGEMENT: CMD 'state' 
14.
20150221 00:58:14 MANAGEMENT: Client disconnected 
15.
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
16.
20150221 00:58:14 D MANAGEMENT: CMD 'status 2' 
17.
20150221 00:58:14 MANAGEMENT: Client disconnected 
18.
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
19.
20150221 00:58:14 D MANAGEMENT: CMD 'log 500' 
20.
20150221 00:58:14 MANAGEMENT: Client disconnected 
darauf hin hab ich mich mit telnet beim Client-DD-WRT eingeloggt und habe mal einen ping auf host.adresse.de gemacht, Packets lost. Genauso wie bei adresse.de, wo eine statische IP hinterlegt ist. Bei Eingabe der IP-Adresse, ging es dann mit dem Ping. Irgendwie verschluckt sich dann die gesamte DNS-Auflösung des Routers. nach einem klick auf "Apply Settings" ging es dann manuell wieder ... und nu?
Bitte warten ..
Mitglied: orcape
21.02.2015 um 01:24 Uhr
Morjn,
... und nu?
...die Ausgabe von "route" von Server- und Client-Router bitte.
Auf der Serverseite ist einer vor dem Server, Portweiterleitung eingerichtet.
...nur für den Tunnelport oder auch für DNS ?
Gruß orcape
Bitte warten ..
Mitglied: traller
21.02.2015, aktualisiert um 13:21 Uhr
Zitat von orcape:

Morjn,
> ... und nu?
...die Ausgabe von "route" von Server- und Client-Router bitte.
Client-Router
01.
0.0.0.0/1 via 10.0.1.5 dev tun1 
02.
default via 192.168.2.1 dev ath0 # W-LAN in das sich der Client zu erst einwählt (über 2,4Ghz), stellt somit die Internetverbindung bereit 
03.
10.0.1.0/24 via 10.0.1.5 dev tun1 
04.
10.0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6 
05.
79.250.73.55 via 192.168.2.1 dev ath0 
06.
127.0.0.0/8 dev lo  scope link 
07.
128.0.0.0/1 via 10.0.1.5 dev tun1 
08.
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
09.
192.168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107 
10.
192.168.0.0/24 via 10.0.1.5 dev tun1 
11.
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
Server-Router
01.
default via 217.0.119.55 dev ppp0 
02.
10.0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, da es ein anderes VPN Gateway als das besprochene ist 
03.
10.0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1 # irrelevant, da es ein anderes VPN Gateway als das besprochene ist 
04.
127.0.0.0/8 dev lo  scope link 
05.
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
06.
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1 
07.
217.0.119.55 dev ppp0  proto kernel  scope link  src 79.253.124.158
VPN-Server
01.
default via 192.168.0.1 dev eth0 
02.
10.0.1.0/24 via 10.0.1.2 dev tun0 
03.
10.0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1 
04.
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.5

> Auf der Serverseite ist einer vor dem Server, Portweiterleitung eingerichtet.
...nur für den Tunnelport oder auch für DNS ?
Gruß orcape

nur der entsprechende UDP-Port. Weshalb DNS? Das Problem ist ja, dass der Client keinen erneuten DNS anfragt ...
Bitte warten ..
Mitglied: orcape
21.02.2015 um 12:38 Uhr
Sorry, so kommen wir nicht weiter.
Wir haben nun einen Server-Router und einen VPN-Server.
Du hast, wie´s scheint, Server-Seitig eine Routerkaskade und auf beiden Routern laufen OpenVPN-Server.
Während der 1. Router die Verbindung zum Internet herstellt und dessen Tunnel für mich irrelevant...
10.0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, da es ein anderes VPN Gateway als das besprochene ist
sein soll.., geht es nur um den 2. Router und dessen Multiclienttunnel.
Multiclienttunnel (client-to-client), sträuben sich bei mir auch schon die Haare, wenn Du nur Server + Client in einer Tunnelverbindung hast. Wenn dem so ist, ist die IP-Vergabe des Tunnels nicht korrekt, aber dazu später.
Auch vermisse ich in Deiner Server.conf noch einen Verweis auf eine CCD, die clientspezifische Daten enthält.
Das könnte auch ein Grund sein, das sich der Client nicht wieder verbindet.
Ich hoffe mal Dein gesamtes Routersortiment besteht nicht aus "hornalten" WRT54, die Du für 10 € in der Bucht ersteigert hast.
Dann könnte nämlich auch noch ein Hardwarefehler das ganze "Prozedere" auslösen.
Also mal mit klaren Worten...
...entweder Du machst hier mal "Nägel mit Köpfen", in dem Du das ganze Szenario Deines Netzwerks einmal komplett zu "Papier" bringst und hier postest....
Hardware, Interfaces, Netze etc.
....oder wir posten Weihnachten 2016 noch sinnlos hin und her.
Gruß orcape
Bitte warten ..
Mitglied: traller
21.02.2015, aktualisiert um 13:27 Uhr
Problem: nach der Zwangstrennung des Teils beim VPN-Server (192.168.0.0), macht der DD-WRT-Client (192.168.1.1) keinen automatischen Reconnect. Die Dyndns-Adresse funktioniert richtig. Der DD-WRT-Client nimmt anscheinend automatisch keine DNS-Aktualisierung vor und verwendet für den Reconnect immer noch die alte IP.
Zitat von orcape:

Sorry, so kommen wir nicht weiter.
Wir haben nun einen Server-Router und einen VPN-Server.
Du hast, wie´s scheint, Server-Seitig eine Routerkaskade und auf beiden Routern laufen OpenVPN-Server.
hab es hier mal aufgezeichnet. Im Grunde geht es um den DD-WRT-Client und den Part mit dem VPN-Server. Der DD-WRT Client aktualisiert seinen DNS nicht von selbst, also ohne manuelles zutun.
377792173e3682389735a837f0d2b65a - Klicke auf das Bild, um es zu vergrößern

Multiclienttunnel (client-to-client), sträuben sich bei mir auch schon die Haare, wenn Du nur Server +
Client in einer Tunnelverbindung hast. Wenn dem so ist, ist die IP-Vergabe des Tunnels nicht korrekt, aber dazu später.
in dem VPN sind auch normale Windows-Clients, deshalb client-to-client.
Auch vermisse ich in Deiner Server.conf noch einen Verweis auf eine CCD, die clientspezifische Daten enthält.
Das könnte auch ein Grund sein, das sich der Client nicht wieder verbindet.
??


und noch einmal die Konfiguration:
VPN-Server
01.
dev tun 
02.
proto udp 
03.
port 1194 
04.
ca /etc/openvpn/certificates/ca.crt 
05.
cert /etc/openvpn/certificates/pi.crt 
06.
key /etc/openvpn/certificates/pi.key 
07.
dh /etc/openvpn/certificates/dh4096.pem 
08.
tls-auth /etc/openvpn/certificates/ta.key 0 
09.
user nobody 
10.
group nogroup 
11.
server 10.0.1.0 255.255.255.0 
12.
cipher AES-256-CBC 
13.
auth SHA512 
14.
persist-key 
15.
persist-tun 
16.
keepalive 10 120 
17.
status /var/log/openvpn-status.log 
18.
verb 1 
19.
client-to-client 
20.
push "redirect-gateway def1" 
21.
push "dhcp-option DNS 192.168.0.1" 
22.
push "route 192.168.0.0 255.255.255.0" 
23.
log-append /var/log/openvpn 
24.
comp-lzo
beim DD-WRT Client-Router:
01.
Server IP/Name: host.adresse.de 
02.
Port: 1194 
03.
Tunnel device: tun 
04.
Tunnel Protocol: udp 
05.
Cipher: AES-256-CBC 
06.
Hash: SHA512 
07.
User Pass Authentication: Disable 
08.
Advanced Options: Enable 
09.
TLS Cipher: None 
10.
LZO Compression Adaptive 
11.
NAT: Enable 
12.
Firewall Protection: disable 
13.
Ip Address: 
14.
Subnet Mask: 
15.
Tunnel MTU Setting: 1500 
16.
Tunnel UDP Fragment: 
17.
Tunnel UDP MSS-Fix: Disable 
18.
nsCertType verification: nichts 
19.
 
20.
Additional Config: 
21.
redirect-gateway def1 
22.
dhcp-option DNS 192.168.0.1
und noch mal Route verbessert:
Client-Router
01.
0.0.0.0/1 via 10.0.1.5 dev tun1 
02.
default via 192.168.2.1 dev ath0 # also über die Router-Kaskade auf Client-Seite 
03.
10.0.1.0/24 via 10.0.1.5 dev tun1 
04.
10.0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6 
05.
79.250.73.55 via 192.168.2.1 dev ath0 # die 79.250.73.55 ist die IP vor der Zwangstrennung 
06.
127.0.0.0/8 dev lo  scope link 
07.
128.0.0.0/1 via 10.0.1.5 dev tun1 
08.
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
09.
192.168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107 # Router-Kaskade 
10.
192.168.0.0/24 via 10.0.1.5 dev tun1 
11.
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
Router serverseitig (192.168.0.1)
01.
default via 217.0.119.55 dev ppp0 
02.
10.0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, es geht um einen anderen VPN-Gateway 
03.
10.0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1 #  irrelevant, es geht um einen anderen VPN-Gateway 
04.
127.0.0.0/8 dev lo  scope link 
05.
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
06.
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1 
07.
217.0.119.55 dev ppp0  proto kernel  scope link  src 79.253.124.158 # 79.253.124.158 entspricht der IP nach der Zwangstrennung
VPN-Server
01.
default via 192.168.0.1 dev eth0 
02.
10.0.1.0/24 via 10.0.1.2 dev tun0 
03.
10.0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1 
04.
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.5
Bitte warten ..
Mitglied: orcape
21.02.2015 um 14:11 Uhr
Jetzt wird mir natürlich einiges klar.
Kennt denn der Client überhaupt die Adresse des DynDNS-Accounts für den IP-Wechsel ?...
Server IP/Name: host.adresse.de
Was steht da genau Drin ?
Ist eben immer Frickelkram, wenn OpenVPN auf einem Server hinter einem Router läuft.
Ein 2. OpenVPN-Server auf dem Router und ein ordentliches Routing zum Server und das Problem wäre sicher gelöst.
Leider ist das bei der Config über den DD-WRT GUI nicht vorgesehen und deshalb wohl auch nicht so problemlos machbar.
Gruß orcape
Bitte warten ..
Mitglied: traller
21.02.2015 um 14:22 Uhr
Zitat von orcape:

Jetzt wird mir natürlich einiges klar.
Kennt denn der Client überhaupt die Adresse des DynDNS-Accounts für den IP-Wechsel ?...
> Server IP/Name: host.adresse.de
Was steht da genau Drin ?
host.adresse.de ist eine Subdomain mit CNAME-Weiterleitung an host.no-ip.org. Aktualisiert wird dieses über den Server-Router (192.168.0.1). Wird also immer erfolgreich durchgeführt. Bei den Windows-Clients klappt das eigentlich problemlos, wobei ich es hier nur manuell verbinde. Ich vermute, dass der Client-DD-WRT (192.168.1.1) die alte IP noch in irgendeinem Cache hat. Diese aktualisiert sich irgendwie nur, wenn ich irgendwo manuell auf "Apply Settings" klicke, obwohl ich natürlich keine Einstellungen verändert habe.

Ist eben immer Frickelkram, wenn OpenVPN auf einem Server hinter einem Router läuft.
Ein 2. OpenVPN-Server auf dem Router und ein ordentliches Routing zum Server und das Problem wäre sicher gelöst.
Leider ist das bei der Config über den DD-WRT GUI nicht vorgesehen und deshalb wohl auch nicht so problemlos machbar.
Das wäre machbar, indem ich die VPN-Server-Konfigurationen auf der Serverseite einfach tauschen würde. Ich denke aber nicht, dass es das Problem behebt, da die Dyndns-Adresse ja korrekt aktualisiert wird.
Bitte warten ..
Mitglied: orcape
LÖSUNG 21.02.2015, aktualisiert 24.02.2015
So richtig wirklich fällt mir da jetzt auch nichts mehr ein.
Ich vermute, dass der Client-DD-WRT (192.168.1.1) die alte IP noch in irgendeinem Cache hat.
..eher unwahrscheinlich, habe das über Monate mit no-ip.org laufen gehabt und hatte da nie Probleme.
Wenn Du also auf "Apply Settings" klickst, baut sich Dein Tunnel anschließend wieder auf ?
Was natürlich auch noch ein Knackpunkt sein kann, ist Deine MTU 1500. Setz die mal auf 1300 runter und teste da mal.
Wenn´s was bringt, kannst Du die ja wieder Richtung 1492 hoch korrigieren.
Bitte warten ..
Mitglied: traller
21.02.2015 um 15:31 Uhr
Zitat von orcape:
Was natürlich auch noch ein Knackpunkt sein kann, ist Deine MTU 1500. Setz die mal auf 1300 runter und
teste da mal.
Wenn´s was bringt, kannst Du die ja wieder Richtung 1492 hoch korrigieren.

wenn ich apply settings mache, geht es. der hängt nur immer im Status "Resolve" ... ich werd das mal auf 1300 stellen.
Bitte warten ..
Mitglied: aqui
21.02.2015 um 15:58 Uhr
1500 ist für einen VPN Tunnel via DSL definitiv zu groß. Bedenke den doppelten Header (IP, PPPoE) plus VPN Header !
Bitte warten ..
Mitglied: traller
21.02.2015, aktualisiert um 18:08 Uhr
Zitat von aqui:

1500 ist für einen VPN Tunnel via DSL definitiv zu groß. Bedenke den doppelten Header (IP, PPPoE) plus VPN Header !

Hallo,
ich habe nun vom VPN-Server einen Ping zum Client gemacht und die MTU mittels
01.
ping -c 1 -s $((1370-28)) -M do 10.0.1.6
ermittelt. Ist das so korrekt gewesen? Somit konnte ich 1370 als Wert festlegen. Das habe ich dann auf Server und Client so eingestellt.
Bitte warten ..
Mitglied: orcape
LÖSUNG 22.02.2015, aktualisiert 24.02.2015
Wenn da keine Fehlermeldung kommt ist das OK so.
Bei höheren, eingetragenen Werten kommen dann Fehlermeldungen ?
Bitte warten ..
Mitglied: traller
23.02.2015 um 11:54 Uhr
Das mit der MTU hat nicht funktioniert. Ist wieder passiert. Hab nun einfach mit der Hilfe von http://www.dd-wrt.com/wiki/index.php/Useful_Scripts#Automatic_Connectio ... ein Script entwickelt. Dieses sieht nun so aus:
01.
#!/bin/sh 
02.
INTERVAL=10 
03.
PACKETS=1 
04.
VPN="openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down-pre /tmp/openvpncl/route-down.sh --daemon" 
05.
IFACE=tun0 
06.
TARGET=192.168.0.1 
07.
 
08.
 
09.
ME=`basename $0` 
10.
RUNNING=`ps | awk '/'"$ME"'/ {++x}; END {print x+0}'` 
11.
if [ "$RUNNING" -gt 3 ]; then 
12.
   echo "Another instance of \"$ME\" is running" 
13.
   exit 1 
14.
fi 
15.
 
16.
while sleep $INTERVAL 
17.
do 
18.
   RET=`ping -c $PACKETS $TARGET 2> /dev/null | awk '/packets received/ {print $4}'` 
19.
 
20.
   if [ "$RET" -ne "$PACKETS" ]; then 
21.
      echo "Ping failed, releasing IP address on $IFACE" 
22.
	#send a RELEASE signal 
23.
		kill $(ps | grep "openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down-pre /tmp/openvpncl/route-down.sh --daemon" | head -c 5 ) 
24.
	#ensure udhcpc is not running 
25.
      killall openvpn 2> /dev/null 
26.
      echo "Renewing IP address: $IFACE" 
27.
      $VPN 
28.
      echo "Waiting 10 s..." 
29.
      sleep 10 
30.
   else 
31.
      echo "Network is up via $TARGET" 
32.
   fi 
33.
done
das klappt so weit. Nun müsste ich das nur noch so einbinden, dass es immer automatisch gestartet wird. Geht das irgendwie über GUI??
Bitte warten ..
Mitglied: aqui
23.02.2015 um 11:56 Uhr
Ja, entweder GUI (Autostart unter Administration) oder eben einfach per Shell Zugriff via SSH.
Bitte warten ..
Mitglied: traller
23.02.2015 um 12:09 Uhr
Zitat von aqui:

Ja, entweder GUI (Autostart unter Administration) oder eben einfach per Shell Zugriff via SSH.

also Administration>Commands>Save Startup? dann startet das Script bei jedem Apply oder Reboot?
Bitte warten ..
Mitglied: aqui
LÖSUNG 23.02.2015, aktualisiert 24.02.2015
Bei jedem Reboot.
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 ...

Router & Routing
Router für OpenVPN (Client) und VLAN (24)

Frage von damnbx zum Thema Router & Routing ...

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

Frage von homermg zum Thema Router & Routing ...

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

Frage von semperf1delis zum Thema Exchange Server ...

Windows Server
DHCP Server switchen (20)

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

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

Frage von MegaGiga zum Thema Hardware ...