Wrt54gl mit DD-Wrt als Openvpn client!
Ich habe versucht meinen WRT54gl den ich mit DD-Wrt geflasht habe als Openvpn client einzurichten.
Ich bin jetzt soweit das ich eine Verbindung zum Openvpn Server konstant aufbauen kann.
Was jetzt noch nicht geht ist auf das Netz vom WRT54 von einem anderem Client aus zu zu greifen.
Das Server Konfigurationsfile schaut so aus
port 443
proto udp
dev tun0
ca keys/test/ca.crt
cert keys/test/servertest.crt
key keys/test/servertest.key
dh keys/test/dh2048.pem
server 10.1.100.0 255.255.255.0
crl-verify keys/test/crl.pem
cipher AES-128-CBC
user nobody
group nogroup
status servers/serverMy/logs/openvpn-status.log
log-append servers/serverMy/logs/openvpn.log
verb 6
mute 20
max-clients 100
management 127.0.0.1 2000
keepalive 10 120
client-config-dir /etc/openvpn/servers/serverMy/ccd
client-to-client
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "route 192.168.20.0 255.255.255.0"
Ich hoffe ihr könnt mir helfen.
Vielen Dank für Eure Hilfe
Ich bin jetzt soweit das ich eine Verbindung zum Openvpn Server konstant aufbauen kann.
Was jetzt noch nicht geht ist auf das Netz vom WRT54 von einem anderem Client aus zu zu greifen.
Das Server Konfigurationsfile schaut so aus
port 443
proto udp
dev tun0
ca keys/test/ca.crt
cert keys/test/servertest.crt
key keys/test/servertest.key
dh keys/test/dh2048.pem
server 10.1.100.0 255.255.255.0
crl-verify keys/test/crl.pem
cipher AES-128-CBC
user nobody
group nogroup
status servers/serverMy/logs/openvpn-status.log
log-append servers/serverMy/logs/openvpn.log
verb 6
mute 20
max-clients 100
management 127.0.0.1 2000
keepalive 10 120
client-config-dir /etc/openvpn/servers/serverMy/ccd
client-to-client
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "route 192.168.20.0 255.255.255.0"
Ich hoffe ihr könnt mir helfen.
Vielen Dank für Eure Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 197326
Url: https://administrator.de/contentid/197326
Ausgedruckt am: 26.11.2024 um 05:11 Uhr
43 Kommentare
Neuester Kommentar
Hier findest du weitere Infos zu dem Thema:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Klassischer Anfängerfehler wenn du von remote zugreifst: Die lokale Firewall !!
Die musst du natürlich customizen, ansonsten schmeisst sie alle Pakete weg die von fremden Netzen (IPs) kommen als dem eigenen lokalen !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Klassischer Anfängerfehler wenn du von remote zugreifst: Die lokale Firewall !!
Die musst du natürlich customizen, ansonsten schmeisst sie alle Pakete weg die von fremden Netzen (IPs) kommen als dem eigenen lokalen !
Die interne (Windows) Firewall auf dem Notebook ! Die WRT Firewall hat damit (fast) nichts zu tun.
Endgeräte Firewalls (wie z.B. die in Windows) schmeissen, wie jeder Netzwerker weiss, alles an Daten weg was Absender IP Adressen hat die NICHT aus dem lokalen IP Netz kommen !
Wie z.B. dein remotes VPN Netz, denn das kommt ja aus einem ganz anderen IP Netzwerk...logo !
Kommen solche Datenpakete also am Laptop an mit einer anderen IP, entsorgt sie die Firewall sofort mit dem Ergebnis was du oben siehst !
Fazit: Lokale Notbook Firewall anpassen oder zum Testen erstmal temporär deaktivieren !
Alles klar ?!
Endgeräte Firewalls (wie z.B. die in Windows) schmeissen, wie jeder Netzwerker weiss, alles an Daten weg was Absender IP Adressen hat die NICHT aus dem lokalen IP Netz kommen !
Wie z.B. dein remotes VPN Netz, denn das kommt ja aus einem ganz anderen IP Netzwerk...logo !
Kommen solche Datenpakete also am Laptop an mit einer anderen IP, entsorgt sie die Firewall sofort mit dem Ergebnis was du oben siehst !
Fazit: Lokale Notbook Firewall anpassen oder zum Testen erstmal temporär deaktivieren !
Alles klar ?!
Nur nochmal dumm nachgefragt:
Dein Netzwerk 10.1.100.0 /24 ist das ein Testnetzwerk oder soll das nur das interne OVPN Tunnelnetzwerk beschreiben. D.h. physisch sind die Endgeräte wie Server und der mobile Client schon im Internet nur die Tunnel IP Adressen bzw. das interne Tunnelnetz ist die 10.1.100.0 /24.
Wenn dem nicht so wäre ist klar das eine Funktion fehlschlägt, denn dann wäre das interne Tunnelnetz und das Transportnetz im gleichen IP Segment ! Das klappt dann natürlich nicht...logo !
Vermutlich meinst du aber wohl wirklich nur das Tunnelnetz ?!
Nochwas: Wenn man deinen Thread genauer liest herrscht doch ziemliche Verwirrung WAS du eigentlich genau willst und WAS genau die Aussage "...nicht geht ist auf das Netz vom WRT54 von einem anderem Client aus zu zu greifen." eigentlich meint ??
Einerseits sagst du ganz dick in der Überschrift "Wrt54gl mit DD-Wrt als Openvpn client!" was logischerweise für uns bedeutet das sich der DD-WRT dann als OpenVPN Client an einem OVPN Server anmeldet, und als "Server" fungiert ja vermutlich dann dein V-Server irgendwo im Internet, richtig ?!
Bedenke: Dann ist der DD-WRT in diesem Falle ein VPN Client !!
Folglicherweise ist er dann KEIN VPN Server und logische Schlussfolgerung daraus ist dann das sich auch niemand dort einwählen kann, denn eine Client Rolle ist ja kein Server...versteht jeder, oder ?!
Daraus wiederum resultiert das deine "Serverkonfiguration" oben irgendwie unsinnig ist, wenn diese denn für den DD-WRT sein sollte ?!? Kann aber nicht denn du erklärst uns ja das der DD-WRT sich als "Client" einwählt.... Denn das ein System Server und Client zur gleichen Zeit sein kann geht logischerweise technisch nicht.
Nehmen wir also mal an das das dann die Server Konfig des OVPN Servers (V-Servers) im Internet ist, richtig ?? Nur das macht ja Sinn...
Da wäre dann aber das Kommando "push "route 192.168.20.0 255.255.255.0"" totaler Blödsinn, denn damit anounced dieser Server eine Route in das 192.168.20er Netz an den Client, das der V-Server ja garnicht hat und das bei dir der Client aber selber hat. 2mal 192.168.20.0er Netz also...kein Router auf der Welt kommt mit doppelten IP Netzen klar.
Vermutlich hast du auch niemals einen Blick in die Routing Tabelle des DD-WRT (netstat -r) gemacht geschweige denn auf dem V-Server (route print), oder ??
Da hättest du das Elend sofort gesehen.
Das mit so einem Unsinn natürlich kein gescheites Routing zustande kommt ist also klar. Das Ping und remoter Zugriff dann nicht klappt sowieso...
Klar ist aber nun garnicht mehr WAS du denn nun eigentlich genau vorhast ?!?
Hier tut also dringenst etwas Aufklärung Not das wir dir hier zielgerichtet helfen können.
Ggf. solltest du auch dringenst nochmal die OVPN Online Doku lesen !
http://openvpn.net/index.php/open-source/documentation.html
oder das obige Tutorial wirklich nochmal GENAU Schritt für Schritt durchgehen. Speziell was Client und Server ist !
Dein Netzwerk 10.1.100.0 /24 ist das ein Testnetzwerk oder soll das nur das interne OVPN Tunnelnetzwerk beschreiben. D.h. physisch sind die Endgeräte wie Server und der mobile Client schon im Internet nur die Tunnel IP Adressen bzw. das interne Tunnelnetz ist die 10.1.100.0 /24.
Wenn dem nicht so wäre ist klar das eine Funktion fehlschlägt, denn dann wäre das interne Tunnelnetz und das Transportnetz im gleichen IP Segment ! Das klappt dann natürlich nicht...logo !
Vermutlich meinst du aber wohl wirklich nur das Tunnelnetz ?!
Nochwas: Wenn man deinen Thread genauer liest herrscht doch ziemliche Verwirrung WAS du eigentlich genau willst und WAS genau die Aussage "...nicht geht ist auf das Netz vom WRT54 von einem anderem Client aus zu zu greifen." eigentlich meint ??
Einerseits sagst du ganz dick in der Überschrift "Wrt54gl mit DD-Wrt als Openvpn client!" was logischerweise für uns bedeutet das sich der DD-WRT dann als OpenVPN Client an einem OVPN Server anmeldet, und als "Server" fungiert ja vermutlich dann dein V-Server irgendwo im Internet, richtig ?!
Bedenke: Dann ist der DD-WRT in diesem Falle ein VPN Client !!
Folglicherweise ist er dann KEIN VPN Server und logische Schlussfolgerung daraus ist dann das sich auch niemand dort einwählen kann, denn eine Client Rolle ist ja kein Server...versteht jeder, oder ?!
Daraus wiederum resultiert das deine "Serverkonfiguration" oben irgendwie unsinnig ist, wenn diese denn für den DD-WRT sein sollte ?!? Kann aber nicht denn du erklärst uns ja das der DD-WRT sich als "Client" einwählt.... Denn das ein System Server und Client zur gleichen Zeit sein kann geht logischerweise technisch nicht.
Nehmen wir also mal an das das dann die Server Konfig des OVPN Servers (V-Servers) im Internet ist, richtig ?? Nur das macht ja Sinn...
Da wäre dann aber das Kommando "push "route 192.168.20.0 255.255.255.0"" totaler Blödsinn, denn damit anounced dieser Server eine Route in das 192.168.20er Netz an den Client, das der V-Server ja garnicht hat und das bei dir der Client aber selber hat. 2mal 192.168.20.0er Netz also...kein Router auf der Welt kommt mit doppelten IP Netzen klar.
Vermutlich hast du auch niemals einen Blick in die Routing Tabelle des DD-WRT (netstat -r) gemacht geschweige denn auf dem V-Server (route print), oder ??
Da hättest du das Elend sofort gesehen.
Das mit so einem Unsinn natürlich kein gescheites Routing zustande kommt ist also klar. Das Ping und remoter Zugriff dann nicht klappt sowieso...
Klar ist aber nun garnicht mehr WAS du denn nun eigentlich genau vorhast ?!?
Hier tut also dringenst etwas Aufklärung Not das wir dir hier zielgerichtet helfen können.
Ggf. solltest du auch dringenst nochmal die OVPN Online Doku lesen !
http://openvpn.net/index.php/open-source/documentation.html
oder das obige Tutorial wirklich nochmal GENAU Schritt für Schritt durchgehen. Speziell was Client und Server ist !
OK, nun ist das verstanden und das macht dann auch Sinn !
Frage:
1.) Die 10er Tunnel IPs a.) des OVPN Servers .1 und die des DD-WRT Router Clients anpingen ?
2.) Wenn ja kannst du das 192.168.20er LAN Interface des DD-WRT anpingen ?
3.) Wie sieht die Routing Tabelle des OVPN Servers aus "route print" ?
4.) Wie sieht die Routing Tabelle des DD-WRT aus "netstat -r" ?
5.) Was sagt ein Traceroute oder Pathping einmal auf die Tunnel IP und die LAN IP des DD-WRT ?
Das wäre noch sinnvoll zu wissen ?
Frage:
- Wenn der DD-WRT Client eingeloggt ist
- ...und der Notebook Client eingeloggt ist...
1.) Die 10er Tunnel IPs a.) des OVPN Servers .1 und die des DD-WRT Router Clients anpingen ?
2.) Wenn ja kannst du das 192.168.20er LAN Interface des DD-WRT anpingen ?
3.) Wie sieht die Routing Tabelle des OVPN Servers aus "route print" ?
4.) Wie sieht die Routing Tabelle des DD-WRT aus "netstat -r" ?
5.) Was sagt ein Traceroute oder Pathping einmal auf die Tunnel IP und die LAN IP des DD-WRT ?
Das wäre noch sinnvoll zu wissen ?
Mit den "code" und "/code" Flags bekommst du die Formatierung hin. Lies bitte die "Formatierungshilfe" hier in den FAQs da steht wie es geht.
OK, die 10.1.100.2 ist vermutlich die Tunnel IP des DD-WRT Clients.
Das Problem kannst du selber sehen....der OVPN Server "kennt" das 192.168.20er Netz nicht. Kommen also dort Zielpakete für ihn an weiss er nicht wohin damit und routet sie an sein Default gateway wo sie dann auf Nimmerwiedersehen verschwinden.
Mit route print bekommst du unter Winblows die volle Tabelle !
Interessant wäre noch auf dem Laptop bei aktivem Tunnel ein route print zu sehen ob der Server das 192.168.20er Netz richtig annouced und ob das am laptop entsprechend in den Tunnel geroutet wird ?!
Du must also im Server noch ein iroute Statement konfigurieren, damit der das 192.168.20er netz kennt.
--iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive). The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.
This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script.
The --iroute directive also has an important interaction with --push "route ...". --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this. In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes.
Dort sollte dann iroute 192.168.20.0 255.255.255.0 stehen
Ggf. noch erweitert um das Route statementroute 192.168.20.0 255.255.255.0 10.1.100.2
Checken und immer mitroute printodernetstat -r// checken ob die Routing Tabellen konsitent sind.
Traceroute zeigt dann immer obs alles durchgeht.
OK, die 10.1.100.2 ist vermutlich die Tunnel IP des DD-WRT Clients.
Das Problem kannst du selber sehen....der OVPN Server "kennt" das 192.168.20er Netz nicht. Kommen also dort Zielpakete für ihn an weiss er nicht wohin damit und routet sie an sein Default gateway wo sie dann auf Nimmerwiedersehen verschwinden.
Mit route print bekommst du unter Winblows die volle Tabelle !
Interessant wäre noch auf dem Laptop bei aktivem Tunnel ein route print zu sehen ob der Server das 192.168.20er Netz richtig annouced und ob das am laptop entsprechend in den Tunnel geroutet wird ?!
Du must also im Server noch ein iroute Statement konfigurieren, damit der das 192.168.20er netz kennt.
--iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive). The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.
This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script.
The --iroute directive also has an important interaction with --push "route ...". --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this. In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes.
Dort sollte dann iroute 192.168.20.0 255.255.255.0 stehen
Ggf. noch erweitert um das Route statementroute 192.168.20.0 255.255.255.0 10.1.100.2
Checken und immer mitroute printodernetstat -r// checken ob die Routing Tabellen konsitent sind.
Traceroute zeigt dann immer obs alles durchgeht.
Du kannst sicher auch selber sehen wo der Fehler ist, oder ?? Da braucht es keine 1000 Worte oder Bilder...
Auf dem Notebook fehlt schlicht und einfach die Route ins 192.168.20.0er Netz !
Deshalb kann das Notebook dieses Netz niemals erreichen, dann Pakete dahin gehen statt ans VPN TUN Interface als next Hop immer ans Default Gateway und damit ins Nirwana !
Fazit: Der OVPN Server pusht die .20er Route nicht an den Laptop Client. Ggf. muss man da mit iroute etwas nachhelfen...
Was du testweise mal machen kannst:
Konfiguriere bei aktivem VPN Client am Laptop mal eine statische Route temporär ala:
route add 192.168.20.0 mask 255.255.255.0 10.1.100.6 2
Das sollte das Problem erstmal temporär fixen und du das .20er Netz dann erreichen !
(Route Table danach ansehen und Traceroute machen !)
Wenn ja , kommt das danach Finetuning
Auf dem Notebook fehlt schlicht und einfach die Route ins 192.168.20.0er Netz !
Deshalb kann das Notebook dieses Netz niemals erreichen, dann Pakete dahin gehen statt ans VPN TUN Interface als next Hop immer ans Default Gateway und damit ins Nirwana !
Fazit: Der OVPN Server pusht die .20er Route nicht an den Laptop Client. Ggf. muss man da mit iroute etwas nachhelfen...
Was du testweise mal machen kannst:
Konfiguriere bei aktivem VPN Client am Laptop mal eine statische Route temporär ala:
route add 192.168.20.0 mask 255.255.255.0 10.1.100.6 2
Das sollte das Problem erstmal temporär fixen und du das .20er Netz dann erreichen !
(Route Table danach ansehen und Traceroute machen !)
Wenn ja , kommt das danach Finetuning
Stichwort "9" weil du 182 statt 192 geschrieben hast ! Liegt doch auf der Hand... !
Der OVPN Router muss die .20er Route an den Laptop Client via Tunnel veschicken. Ansonsten routet er das per Default Route an den provider wo es logischerweise versandet.
Was du mal testweise machen kannst ist das der OVPN Server als Default Gateway das Tunnel Interface setz bei Einwahl.
Damit wird dann ALLES in den Tunnel geroutet.
http://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
push "redirect-gateway def1"
Damit muss dann in jedem Falle das .20er Netz erreichbar sein.
Testweise solltest du mal checken ob du von einem Client im .20er Netz das 10er Tunnelinterface des Laptop Clients pingen kannst.
Achte immer auf die lokalen Firewalls und deren Einstellungen auf den TUN Interfaces das das auch erlaubt ist !
Der OVPN Router muss die .20er Route an den Laptop Client via Tunnel veschicken. Ansonsten routet er das per Default Route an den provider wo es logischerweise versandet.
Was du mal testweise machen kannst ist das der OVPN Server als Default Gateway das Tunnel Interface setz bei Einwahl.
Damit wird dann ALLES in den Tunnel geroutet.
http://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
push "redirect-gateway def1"
Damit muss dann in jedem Falle das .20er Netz erreichbar sein.
Testweise solltest du mal checken ob du von einem Client im .20er Netz das 10er Tunnelinterface des Laptop Clients pingen kannst.
Achte immer auf die lokalen Firewalls und deren Einstellungen auf den TUN Interfaces das das auch erlaubt ist !
Kann man machen, sollte aber an der Problematik nichts ändern, den das Szenario ist das gleiche.
Der PC macht aber kein NAT, den wirst du also immer und in jedem Falle über seine VPN Tunnel IP erreichen.
Der DD-WRT routet ja noch dazwischen was der PC nicht tut da er ja "dahinter" kein Netz mehr hat.
Irgendwo ist also ein Routing und/oder FW Problem was es zu fixen gilt.
Generell ist das design so machbar und funktioniert auch !
Der PC macht aber kein NAT, den wirst du also immer und in jedem Falle über seine VPN Tunnel IP erreichen.
Der DD-WRT routet ja noch dazwischen was der PC nicht tut da er ja "dahinter" kein Netz mehr hat.
Irgendwo ist also ein Routing und/oder FW Problem was es zu fixen gilt.
Generell ist das design so machbar und funktioniert auch !
Denke mal mobiler Client (Laptop) und OVPN Server sind nicht das Thema. Können sie auch nicht, denn an der Infrastruktur kannst du wenig ändern mit Ausnahme des Finetunings der OVPN Server Konfig Datei.
Strategisch solltest du erstmal das Problem nur mit dem DD-WRT und dem Server lösen und den Client erstmal außen vor lassen.
Setze das eine Standard Konfig auf und log dich mit RDP oder was auch immer auf dem Server ein.
Dann baust du den Tunnel auf und pingst erstmal den Server vom 192.168.20er Client aus.
Idealerweise hast du dann einen Wireshark oder MS Netmonitor am Laufen auf dem Server und checkst mal WELCHE IP Adresse diese Pakete als Absender haben.
Wenns blöd kommt macht der DD-WRT NAT im VPN Tunnel, dann hast du einen 10er IP und es wird knifflig.
Wenn er kein NAT im Tunnel macht hat er ne 192.168er IP und es sollte recht einfach sein das zu fixen dann.
Dann der umgekehrte Weg... direkt vom Server einen Client im 192.168.20er Netz pingen und mit einer SSH Session am DD-WRT tcpdump laufen lassen von der Server Host IP usw.
Das wäre erstmal die Strategie...
Strategisch solltest du erstmal das Problem nur mit dem DD-WRT und dem Server lösen und den Client erstmal außen vor lassen.
Setze das eine Standard Konfig auf und log dich mit RDP oder was auch immer auf dem Server ein.
Dann baust du den Tunnel auf und pingst erstmal den Server vom 192.168.20er Client aus.
Idealerweise hast du dann einen Wireshark oder MS Netmonitor am Laufen auf dem Server und checkst mal WELCHE IP Adresse diese Pakete als Absender haben.
Wenns blöd kommt macht der DD-WRT NAT im VPN Tunnel, dann hast du einen 10er IP und es wird knifflig.
Wenn er kein NAT im Tunnel macht hat er ne 192.168er IP und es sollte recht einfach sein das zu fixen dann.
Dann der umgekehrte Weg... direkt vom Server einen Client im 192.168.20er Netz pingen und mit einer SSH Session am DD-WRT tcpdump laufen lassen von der Server Host IP usw.
Das wäre erstmal die Strategie...
Oha, wenn das schon fehlschlägt ist ja völlig klar das der rest dann auch nicht klappt !
Das bedeutet das dein VPN Tunnel gar nicht aufgebaut ist und aktiv ist !!
Wenn du per SSH auf dem DD-WRT bist und der Tunnel steht, dann muss ein Ping des Server Tunnel Interfaces in jedem Falle möglich sein !
Bei dir stimmt also generell was nicht schon in der DD VPN Einrichtung !
Hast du die Troubleshooting Hinweise via SSH Terminal hier
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
mal berücksichtigt, wenn du den OVPN Client mal manuell startest ??
Was sagt dort der Logoutput beim Verbindungsaufbau ?
Auf alle Fälle hast du so keinen aktiven VPN Tunnel laufen...
Das bedeutet das dein VPN Tunnel gar nicht aufgebaut ist und aktiv ist !!
Wenn du per SSH auf dem DD-WRT bist und der Tunnel steht, dann muss ein Ping des Server Tunnel Interfaces in jedem Falle möglich sein !
Bei dir stimmt also generell was nicht schon in der DD VPN Einrichtung !
Hast du die Troubleshooting Hinweise via SSH Terminal hier
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
mal berücksichtigt, wenn du den OVPN Client mal manuell startest ??
Was sagt dort der Logoutput beim Verbindungsaufbau ?
Auf alle Fälle hast du so keinen aktiven VPN Tunnel laufen...
Ja, sind gleich. Stimmt mit der Client Doku aber wenn du den Client Manuell über die Konsolle startest, dann kannst du anhand der Konsol Fehlermeldungen und auch Statusmeldungen sehr detailiert sehen was passiert. Zudem kannst du den Loglevel auch noch höherschrauben.
Das muss als allererstes fehlerfrei laufen, sonst müssen wir hier nicht weitermachen..
Das muss als allererstes fehlerfrei laufen, sonst müssen wir hier nicht weitermachen..
Klasse ! Problem gefixt !
Es ist wirklich wichtig das man IMMER wasserdicht prüft ob der VPN Tunnel wirklich aktiv ist. Ein tägliches Problem hier im Forum bei VPN Fragen das viele das glauben aber nicht testen
Was macht denn nun der Zugriff vom Laptop Client auf das LAN hinter dem DD-WRT ?
Funktioniert das jetzt auch ?
Es ist wirklich wichtig das man IMMER wasserdicht prüft ob der VPN Tunnel wirklich aktiv ist. Ein tägliches Problem hier im Forum bei VPN Fragen das viele das glauben aber nicht testen
Was macht denn nun der Zugriff vom Laptop Client auf das LAN hinter dem DD-WRT ?
Funktioniert das jetzt auch ?
Klasse, hört sich gut an und rennt dann wie es soll. Besser du lässt das in der Server.conf, denn so bekommt der oder die Clients das immer dynamisch !
Die Antwort auf deine WOL Frage kannst du hiernachlesen:
http://www.heise.de/netze/artikel/Wake-on-WAN-221718.html
Wenn das Magic Paket bei dir also kein Broadcast ist sondern ein gerichtetes mit UDP Port 9 kann es klappen.
WoL kann mehrere Formate haben entsprechend ist auch das Verhalten, das musst du also klären vorher, damit man die Frage wasserdicht beantworten kann !
Die Antwort auf deine WOL Frage kannst du hiernachlesen:
http://www.heise.de/netze/artikel/Wake-on-WAN-221718.html
Wenn das Magic Paket bei dir also kein Broadcast ist sondern ein gerichtetes mit UDP Port 9 kann es klappen.
WoL kann mehrere Formate haben entsprechend ist auch das Verhalten, das musst du also klären vorher, damit man die Frage wasserdicht beantworten kann !
Na ja ein Genie braucht es dazu nicht, nur mal "etwas" Nachdenken
Klasse wenns jetzt klappt !
Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Klasse wenns jetzt klappt !
Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !