traller
Goto Top

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

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:
dev tun
client
proto udp
remote server.de 1194
<ca>
</ca>
<cert>
</cert>
<key>
</key>
key-direction 1
<tls-auth>
</tls-auth>
cipher AES-256-CBC
auth SHA512
resolv-retry infinite
route-method exe
route-delay 30
route-metric 512
route 0.0.0.0 0.0.0.0
nobind
persist-key
persist-tun
comp-lzo
verb 3

die Server-Config sieht so aus:
dev tun
proto udp
port 1194
ca /etc/openvpn/certificates/ca.crt
cert /etc/openvpn/certificates/pi.crt
key /etc/openvpn/certificates/pi.key
dh /etc/openvpn/certificates/dh2048.pem
tls-auth /etc/openvpn/certificates/ta.key 0
user nobody
group nogroup
server 10.0.1.0 255.255.255.0
cipher AES-256-CBC
auth SHA512
persist-key
persist-tun
keepalive 2 1200
status /var/log/openvpn-status.log
verb 1
push "redirect-gateway def1"  
push "dhcp-option DNS 192.168.2.1"  
push "route 192.168.2.0 255.255.255.0"  
log-append /var/log/openvpn
comp-lzo

Im Client-DD-WRT Router habe ich folgendes konfiguriert:
Start OpenVPN Client Enable
Server IP server.de
Port 1194
Tunnel Device TUN
Tunnel Protocol UDP
Encryption Cipher AES-256-CBC
Hash Algorithm SHA512
User Pass Authentication Disable
Advance Options Enable
TLS Cipher None
LZO Compression Adaptive
NAT Enable
Firewall Protection Disable
keine IP Adresse / Subnet Mask
Tunnel MTU setting 1500
Tunnel UDP Fragment nichts
Tunnel UDP MSS-Fix Disable
kein nsCertType verification
Dann natürlich die ganzen Zertifikate und als Additional Config:
route-method exe
route-delay 30
route-metric 512
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??

Content-Key: 262954

Url: https://administrator.de/contentid/262954

Ausgedruckt am: 28.03.2024 um 19:03 Uhr

Mitglied: aqui
aqui 11.02.2015 aktualisiert um 09:30:02 Uhr
Goto Top
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 face-sad 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:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
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 !!
Mitglied: orcape
orcape 11.02.2015 um 10:35:17 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.02.2015 um 10:42:54 Uhr
Goto Top
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.
Mitglied: traller
traller 11.02.2015 um 14:28:50 Uhr
Goto Top
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 ...
Mitglied: orcape
Lösung orcape 11.02.2015, aktualisiert am 24.02.2015 um 00:14:12 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.02.2015 aktualisiert um 20:40:35 Uhr
Goto Top
explizit einen Eintrag der MTU-Größe <1500.
Mein Reden.... face-wink

@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
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Mitglied: traller
traller 20.02.2015 um 09:52:11 Uhr
Goto Top
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:
dev tun
proto udp
port 1194
ca /etc/openvpn/certificates/ca.crt
cert /etc/openvpn/certificates/pi.crt
key /etc/openvpn/certificates/pi.key
dh /etc/openvpn/certificates/dh4096.pem
tls-auth /etc/openvpn/certificates/ta.key 0
user nobody
group nogroup
server 10.0.1.0 255.255.255.0
cipher AES-256-CBC
auth SHA512
persist-key
persist-tun
keepalive 10 120
status /var/log/openvpn-status.log
verb 1
client-to-client
push "redirect-gateway def1"  
push "dhcp-option DNS 192.168.0.1"  
push "route 192.168.0.0 255.255.255.0"  
log-append /var/log/openvpn
comp-lzo

beim DD-WRT Client-Router:
Server IP/Name: host.adresse.de
Port: 1194
Tunnel device: tun
Tunnel Protocol: udp
Cipher: AES-256-CBC
Hash: SHA512
User Pass Authentication: Disable
Advanced Options: Enable
TLS Cipher: None
LZO Compression Adaptive
NAT: Enable
Firewall Protection: disable
Ip Address:
Subnet Mask:
Tunnel MTU Setting: 1500
Tunnel UDP Fragment:
Tunnel UDP MSS-Fix: Disable
nsCertType verification: nichts

Additional Config:
redirect-gateway def1
dhcp-option DNS 192.168.0.1
Mitglied: orcape
orcape 20.02.2015 um 10:24:44 Uhr
Goto Top
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
Mitglied: traller
traller 20.02.2015 um 13:16:43 Uhr
Goto Top
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???
Mitglied: orcape
orcape 20.02.2015 um 13:26:08 Uhr
Goto Top
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 ?
Mitglied: traller
traller 20.02.2015 um 14:45:05 Uhr
Goto Top
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.
Mitglied: orcape
orcape 20.02.2015 aktualisiert um 15:45:51 Uhr
Goto Top
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...
Mitglied: traller
traller 20.02.2015 um 16:07:33 Uhr
Goto Top
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 ...
Mitglied: orcape
orcape 20.02.2015 um 16:12:13 Uhr
Goto Top
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.face-wink
Mitglied: traller
traller 20.02.2015 um 16:22:06 Uhr
Goto Top
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.face-wink

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 ...
Mitglied: orcape
orcape 20.02.2015 aktualisiert um 16:35:27 Uhr
Goto Top
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.
Mitglied: traller
traller 20.02.2015 um 16:33:51 Uhr
Goto Top
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 ;)
Mitglied: orcape
orcape 20.02.2015 um 16:47:08 Uhr
Goto Top
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....
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
...irgend eine Meldung muss da auftauchen, die Aufschluß über Dein Problem gibt.
Mitglied: traller
traller 20.02.2015 um 16:47:39 Uhr
Goto Top
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 ...
Mitglied: orcape
orcape 20.02.2015 um 16:49:13 Uhr
Goto Top
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....
Mitglied: traller
traller 20.02.2015 um 16:50:12 Uhr
Goto Top
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 ...
Mitglied: traller
traller 21.02.2015 aktualisiert um 01:09:47 Uhr
Goto Top
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:
20150221 00:57:34 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again
20150221 00:57:44 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again
20150221 00:57:54 N RESOLVE: Cannot resolve host address: host.adresse.de: Try again
20150221 00:58:04 NOTE: --mute triggered...
20150221 00:58:14 2 variation(s) on previous 3 message(s) suppressed by --mute
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20150221 00:58:14 D MANAGEMENT: CMD 'state'  
20150221 00:58:14 MANAGEMENT: Client disconnected
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20150221 00:58:14 D MANAGEMENT: CMD 'state'  
20150221 00:58:14 MANAGEMENT: Client disconnected
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20150221 00:58:14 D MANAGEMENT: CMD 'state'  
20150221 00:58:14 MANAGEMENT: Client disconnected
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20150221 00:58:14 D MANAGEMENT: CMD 'status 2'  
20150221 00:58:14 MANAGEMENT: Client disconnected
20150221 00:58:14 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20150221 00:58:14 D MANAGEMENT: CMD 'log 500'  
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?
Mitglied: orcape
orcape 21.02.2015 um 01:24:15 Uhr
Goto Top
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
Mitglied: traller
traller 21.02.2015 aktualisiert um 13:21:24 Uhr
Goto Top
Zitat von @orcape:

Morjn,
> ... und nu?
...die Ausgabe von "route" von Server- und Client-Router bitte.
Client-Router
0.0.0.0/1 via 10.0.1.5 dev tun1
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
10.0.1.0/24 via 10.0.1.5 dev tun1
10.0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6
79.250.73.55 via 192.168.2.1 dev ath0
127.0.0.0/8 dev lo  scope link
128.0.0.0/1 via 10.0.1.5 dev tun1
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107
192.168.0.0/24 via 10.0.1.5 dev tun1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1

Server-Router
default via 217.0.119.55 dev ppp0
10.0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, da es ein anderes VPN Gateway als das besprochene ist
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
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
217.0.119.55 dev ppp0  proto kernel  scope link  src 79.253.124.158

VPN-Server
default via 192.168.0.1 dev eth0
10.0.1.0/24 via 10.0.1.2 dev tun0
10.0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1
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 ...
Mitglied: orcape
orcape 21.02.2015 um 12:38:20 Uhr
Goto Top
Sorry, so kommen wir nicht weiter.face-sad
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..face-sad, 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
Mitglied: traller
traller 21.02.2015 aktualisiert um 13:27:15 Uhr
Goto Top
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.face-sad
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

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
dev tun
proto udp
port 1194
ca /etc/openvpn/certificates/ca.crt
cert /etc/openvpn/certificates/pi.crt
key /etc/openvpn/certificates/pi.key
dh /etc/openvpn/certificates/dh4096.pem
tls-auth /etc/openvpn/certificates/ta.key 0
user nobody
group nogroup
server 10.0.1.0 255.255.255.0
cipher AES-256-CBC
auth SHA512
persist-key
persist-tun
keepalive 10 120
status /var/log/openvpn-status.log
verb 1
client-to-client
push "redirect-gateway def1"  
push "dhcp-option DNS 192.168.0.1"  
push "route 192.168.0.0 255.255.255.0"  
log-append /var/log/openvpn
comp-lzo

beim DD-WRT Client-Router:
Server IP/Name: host.adresse.de
Port: 1194
Tunnel device: tun
Tunnel Protocol: udp
Cipher: AES-256-CBC
Hash: SHA512
User Pass Authentication: Disable
Advanced Options: Enable
TLS Cipher: None
LZO Compression Adaptive
NAT: Enable
Firewall Protection: disable
Ip Address:
Subnet Mask:
Tunnel MTU Setting: 1500
Tunnel UDP Fragment:
Tunnel UDP MSS-Fix: Disable
nsCertType verification: nichts

Additional Config:
redirect-gateway def1
dhcp-option DNS 192.168.0.1

und noch mal Route verbessert:
Client-Router
0.0.0.0/1 via 10.0.1.5 dev tun1
default via 192.168.2.1 dev ath0 # also über die Router-Kaskade auf Client-Seite
10.0.1.0/24 via 10.0.1.5 dev tun1
10.0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6
79.250.73.55 via 192.168.2.1 dev ath0 # die 79.250.73.55 ist die IP vor der Zwangstrennung
127.0.0.0/8 dev lo  scope link
128.0.0.0/1 via 10.0.1.5 dev tun1
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107 # Router-Kaskade
192.168.0.0/24 via 10.0.1.5 dev tun1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1

Router serverseitig (192.168.0.1)
default via 217.0.119.55 dev ppp0
10.0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, es geht um einen anderen VPN-Gateway
10.0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1 #  irrelevant, es geht um einen anderen VPN-Gateway
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
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
default via 192.168.0.1 dev eth0
10.0.1.0/24 via 10.0.1.2 dev tun0
10.0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.5
Mitglied: orcape
orcape 21.02.2015 um 14:11:13 Uhr
Goto Top
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
Mitglied: traller
traller 21.02.2015 um 14:22:09 Uhr
Goto Top
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.
Mitglied: orcape
Lösung orcape 21.02.2015, aktualisiert am 24.02.2015 um 00:13:57 Uhr
Goto Top
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.
Mitglied: traller
traller 21.02.2015 um 15:31:21 Uhr
Goto Top
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.
Mitglied: aqui
aqui 21.02.2015 um 15:58:31 Uhr
Goto Top
1500 ist für einen VPN Tunnel via DSL definitiv zu groß. Bedenke den doppelten Header (IP, PPPoE) plus VPN Header !
Mitglied: traller
traller 21.02.2015 aktualisiert um 18:08:14 Uhr
Goto Top
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
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.
Mitglied: orcape
Lösung orcape 22.02.2015, aktualisiert am 24.02.2015 um 00:13:51 Uhr
Goto Top
Wenn da keine Fehlermeldung kommt ist das OK so.
Bei höheren, eingetragenen Werten kommen dann Fehlermeldungen ?
Mitglied: traller
traller 23.02.2015 um 11:54:13 Uhr
Goto Top
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:
#!/bin/sh
INTERVAL=10
PACKETS=1
VPN="openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down-pre /tmp/openvpncl/route-down.sh --daemon"  
IFACE=tun0
TARGET=192.168.0.1


ME=`basename $0`
RUNNING=`ps | awk '/'"$ME"'/ {++x}; END {print x+0}'`  
if [ "$RUNNING" -gt 3 ]; then  
   echo "Another instance of \"$ME\" is running"  
   exit 1
fi

while sleep $INTERVAL
do
   RET=`ping -c $PACKETS $TARGET 2> /dev/null | awk '/packets received/ {print $4}'`  

   if [ "$RET" -ne "$PACKETS" ]; then  
      echo "Ping failed, releasing IP address on $IFACE"  
	#send a RELEASE signal
		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 )  
	#ensure udhcpc is not running
      killall openvpn 2> /dev/null
      echo "Renewing IP address: $IFACE"  
      $VPN
      echo "Waiting 10 s..."  
      sleep 10
   else
      echo "Network is up via $TARGET"  
   fi
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??
Mitglied: aqui
aqui 23.02.2015 um 11:56:21 Uhr
Goto Top
Ja, entweder GUI (Autostart unter Administration) oder eben einfach per Shell Zugriff via SSH.
Mitglied: traller
traller 23.02.2015 um 12:09:58 Uhr
Goto Top
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?
Mitglied: aqui
Lösung aqui 23.02.2015, aktualisiert am 24.02.2015 um 00:13:44 Uhr
Goto Top
Bei jedem Reboot.