10.02.2015, aktualisiert am 24.02.2015

4067

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??

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 262954

Url: https://administrator.de/forum/dd-wrt-router-als-client-in-openvpn-internet-ueber-vpn-geht-nicht-262954.html

Ausgedruckt am: 25.04.2025 um 08:04 Uhr

37 Kommentare

Neuester Kommentar

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:
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 !!

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

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.

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 ...

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

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
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !

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

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

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???

Einen Provider-Zwangsrouter hast Du nicht zufällig in der Routerkaskade auf der Serverseite noch davor hängen ?

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.

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...

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 ...

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.

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 ...

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.

genau, und da ist die Frage was und da fehlt mir die Kenntnis für ;)

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.

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 ...

..das muss auch ohne Script funktionieren, sonst ist in Deiner Config was Faul....

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 ...

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?

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

Zitat von @orcape:

Morjn,
> ... und nu?
...die Ausgabe von "route" von Server- und Client-Router bitte.

Client-Router

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
0.1.0/24 via 10.0.1.5 dev tun1
0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6
250.73.55 via 192.168.2.1 dev ath0
0.0.0/8 dev lo  scope link
0.0.0/1 via 10.0.1.5 dev tun1
254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107
168.0.0/24 via 10.0.1.5 dev tun1
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
0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, da es ein anderes VPN Gateway als das besprochene ist
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
0.0.0/8 dev lo  scope link
254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
0.119.55 dev ppp0  proto kernel  scope link  src 79.253.124.158

VPN-Server

default via 192.168.0.1 dev eth0
0.1.0/24 via 10.0.1.2 dev tun0
0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1
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 ...

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

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.

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/1 via 10.0.1.5 dev tun1
default via 192.168.2.1 dev ath0 # also über die Router-Kaskade auf Client-Seite
0.1.0/24 via 10.0.1.5 dev tun1
0.1.5 dev tun1  proto kernel  scope link  src 10.0.1.6
250.73.55 via 192.168.2.1 dev ath0 # die 79.250.73.55 ist die IP vor der Zwangstrennung
0.0.0/8 dev lo  scope link
0.0.0/1 via 10.0.1.5 dev tun1
254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
168.2.0/24 dev ath0  proto kernel  scope link  src 192.168.2.107 # Router-Kaskade
168.0.0/24 via 10.0.1.5 dev tun1
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
0.0.0/24 via 10.0.0.2 dev tun0 # irrelevant, es geht um einen anderen VPN-Gateway
0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1 #  irrelevant, es geht um einen anderen VPN-Gateway
0.0.0/8 dev lo  scope link
254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
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
0.1.0/24 via 10.0.1.2 dev tun0
0.1.2 dev tun0  proto kernel  scope link  src 10.0.1.1
168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.5

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

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.

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.

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.

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

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.

Wenn da keine Fehlermeldung kommt ist das OK so.
Bei höheren, eingetragenen Werten kommen dann Fehlermeldungen ?

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