7
Wie bestehende VPN Verbindung nutzen?
Router und VPN Client haben erfolgreich VPN Verbindung aufgebaut, wie geht es nun weiter?
Hallo Admins,
ich bitte als VPN-Neuling um Hilfe. Mit folgender Konfiguration habe ich bereits erfolgreich eine VPN Verbindung aufgebaut:
---Praxis-Netzwerk:
Router: Netgear DG834B, dahinter mehrere Rechner mit statischen IPs
VPN Einstellungen des Routers für Lokales LAN: Adressbereich
VPN Einstellungen des Routers für entferntes LAN: einzelne Adresse
---Heim-Netzwerk:
Router: Eumex 820 LAN, Filter zur Kommunikation über Port 500 (UDP) und Port forwarding auf Client bereits eingerichtet
Client: mit LAN IP 192.168.0.14 mit Netgear ProSafe VPN Client, Firewall auf Client deaktiviert
Beide Router haben feste Hostnamen per dyndns.
Nach Connect mit Prosafe VPN Client erscheint Meldung: "Successfully connected to...."
Im VPN-Status des DG834B steht zu lesen:
So weit, so gut. Wie kann ich diese Verbindung nun nutzen?
Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen zu können.
Der Clientanwendung wurde die private IP des Servers im Praxisnetz mitgeteilt. Seit dies geschehen ist schmiert die Clientanwendung nach dem Start ab.
Ich habe keine Anhnung, wie sich das bestehnde VPN auf dem Clientrechner im Heimnetzwerk bemerkbar machen sollte. Ich dachte an eine neue Netzwerkverbindung oder ähnliches.
"ipconfig /all" gibt allerdings keinen Hinweis auf das VPN.
Sind weitere Einstellungen in der Eumex oder auf dem Clientrechner nötig? Die Rechner im Praxisnetzwerk sollten über die wenigen zu machenden Einstellungen im Router dem VPN zugänglich sein.
HINWEIS: Ich nutze den Netgear ProSafe VPN CLient in der Version 10.3.5 (Build 6). Die Verbindung kann nur hergestellt werden, wenn ich in dessen Einstellungen unter "My Identity" den "Virtual Adapter" auf "disabled" stelle. Auf meiner Suche im Web stieß ich auf den Hinweis, dass es sich hierbei um einen Bug der älteren Versionen des ProSafe Clients (wie der von mir genutzten) handele. Die Einstellungen "required" oder "prefered" lassen den Verbindungsaufbau mit folgenden Einträgen im Log des ProSafe Clients scheitern:
Was ist dieser virtuelle Adapter und brauche ich ihn zum erfolgreichen VPN-Zugriff auf den Server?
Der VPN-Status des DG834B zeigt folgendes zum gescheiterten Verbindungsversuch mit der "required" Einstellung:
Für Hilfe bin ich dankbar. Falls ich wichtige Angaben vergessen habe, hole ich das auf Hinweis gerne nach.
Gute Nacht,
MaeSiuS
ich bitte als VPN-Neuling um Hilfe. Mit folgender Konfiguration habe ich bereits erfolgreich eine VPN Verbindung aufgebaut:
---Praxis-Netzwerk:
Router: Netgear DG834B, dahinter mehrere Rechner mit statischen IPs
VPN Einstellungen des Routers für Lokales LAN: Adressbereich
VPN Einstellungen des Routers für entferntes LAN: einzelne Adresse
---Heim-Netzwerk:
Router: Eumex 820 LAN, Filter zur Kommunikation über Port 500 (UDP) und Port forwarding auf Client bereits eingerichtet
Client: mit LAN IP 192.168.0.14 mit Netgear ProSafe VPN Client, Firewall auf Client deaktiviert
Beide Router haben feste Hostnamen per dyndns.
Nach Connect mit Prosafe VPN Client erscheint Meldung: "Successfully connected to...."
Im VPN-Status des DG834B steht zu lesen:
Thu, 2010-01-14 00:40:51 - [Praxis-VPN] responding to Main Mode from unknown peer XXX.XXX.XXX.XXX
Thu, 2010-01-14 00:40:51 - [Praxis-VPN] sent MR3, ISAKMP SA established
Thu, 2010-01-14 00:40:51 - [Praxis-VPN] Dead Peer Detection (RFC 3706): enabled
Thu, 2010-01-14 00:40:52 - [Praxis-VPN] responding to Quick Mode {msgid:11e56b72}
Thu, 2010-01-14 00:40:52 - [Praxis-VPN] Dead Peer Detection (RFC 3706): enabled
Thu, 2010-01-14 00:40:52 - [Praxis-VPN] IPsec SA establishedSo weit, so gut. Wie kann ich diese Verbindung nun nutzen?
Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen zu können.
Der Clientanwendung wurde die private IP des Servers im Praxisnetz mitgeteilt. Seit dies geschehen ist schmiert die Clientanwendung nach dem Start ab.
Ich habe keine Anhnung, wie sich das bestehnde VPN auf dem Clientrechner im Heimnetzwerk bemerkbar machen sollte. Ich dachte an eine neue Netzwerkverbindung oder ähnliches.
"ipconfig /all" gibt allerdings keinen Hinweis auf das VPN.
Sind weitere Einstellungen in der Eumex oder auf dem Clientrechner nötig? Die Rechner im Praxisnetzwerk sollten über die wenigen zu machenden Einstellungen im Router dem VPN zugänglich sein.
HINWEIS: Ich nutze den Netgear ProSafe VPN CLient in der Version 10.3.5 (Build 6). Die Verbindung kann nur hergestellt werden, wenn ich in dessen Einstellungen unter "My Identity" den "Virtual Adapter" auf "disabled" stelle. Auf meiner Suche im Web stieß ich auf den Hinweis, dass es sich hierbei um einen Bug der älteren Versionen des ProSafe Clients (wie der von mir genutzten) handele. Die Einstellungen "required" oder "prefered" lassen den Verbindungsaufbau mit folgenden Einträgen im Log des ProSafe Clients scheitern:
1-14: 01:12:32.687 Error creating Virtual Interface for local interface 192.168.0.14, err=RASSTATUS_NO_PROTOCOLS
1-14: 01:12:32.687 My Connections\Praxis-VPN - Failed to create required virtual adapter
1-14: 01:12:32.687 My Connections\Praxis-VPN - Deleting IKE SA (IP ADDR=XX.XXX.XXX.XXX)
1-14: 01:12:32.687 MY COOKIE 55 86 ba 8d 7f 12 59 66
1-14: 01:12:32.687 HIS COOKIE 56 5c 77 23 6 a6 38 58
1-14: 01:12:32.687 My Connections\Praxis-VPN - SENDING>>>> ISAKMP OAK INFO *(HASH, DEL)
1-14: 01:12:32.781 NO MATCHING SECURE CONNECTION - RECEIVED<<< ISAKMP OAK INFO *(Opaque)
1-14: 01:12:32.781 NO MATCHING SECURE CONNECTION - Received message for non-active SADer VPN-Status des DG834B zeigt folgendes zum gescheiterten Verbindungsversuch mit der "required" Einstellung:
Thu, 2010-01-14 01:13:04 - [Praxis-VPN] responding to Main Mode from unknown peer XXX.XXX.XXX.XXX
Thu, 2010-01-14 01:13:05 - [Praxis-VPN] sent MR3, ISAKMP SA established
Thu, 2010-01-14 01:13:05 - [Praxis-VPN] Dead Peer Detection (RFC 3706): enabled
Thu, 2010-01-14 01:13:10 - [Praxis-VPN] received Delete SA payload: deleting ISAKMP State #14Für Hilfe bin ich dankbar. Falls ich wichtige Angaben vergessen habe, hole ich das auf Hinweis gerne nach.
Gute Nacht,
MaeSiuS
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 133417
Url: https://administrator.de/contentid/133417
Printed on: April 24, 2024 at 05:04 o'clock
7 Comments
Latest comment
Guten Morgen,
kann es sein das die Verbindung für die Software schlicht weg zu langsam ist?
kann es sein das die Verbindung für die Software schlicht weg zu langsam ist?
Zitat von @MaeSiuS:
Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen zu können.
Vergiss es!Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen zu können.
Wir arbeiten seit 15 Jahren für Zahnärzte und ich kenne ziemlich viele Programme. Aber selbst die, die auf einem SQL-Server basieren und lokal installierte Clients haben sind über ein VPN nicht nutzbar.
Selbst WLAN ist für viele Programme (auch N nicht) nicht nutzbar. Das liegt an der Struktur und Qualität ALLER (mir bekannten) Programme.
Die Programme die zur Zeit entwicklet werden basieren quasi alle auf Web-Techniken. Damit wird dass dann möglich sein.
Deine Lösung heißt erstmal RDP.
Also entweder einen Terminamlserver wenn mehrere Personen von Außen arbeiten sollen oder RemoteDesktop wenn es nur darum geht, dass eine Person außerhalb der Arbeitszeiten arbeiten will.
Stefan
Guten Abend,
nein, denn die Software ist für den Fernzugriff über schmalbandige Verbindungen ausgelegt. Die clientseitige Anwendung gibt sich auch mit einer ISDN-Wählverbindung zum Zugriff auf den Server zufrieden. Es wird nur Text übermittelt.
nein, denn die Software ist für den Fernzugriff über schmalbandige Verbindungen ausgelegt. Die clientseitige Anwendung gibt sich auch mit einer ISDN-Wählverbindung zum Zugriff auf den Server zufrieden. Es wird nur Text übermittelt.
Hallo Stefan, vielen Dank für Deine Antwort.
Wie in meiner Antwort an wiesi200 geschrieben, gibt sich die Clientsoftware auch mit einer ISDN-Wählverbindung zufrieden. Es wird ja nur Text übertragen, keine Befunde oder ähnliches.
Die VPN-Lösung, in der die Clientsoftware direkt auf dem Heimarbeitsplatz ausgeführt wird (statt ferngesteuert zu werden) ist sinnvoller und eleganter. So man den VPN beherrscht.
Ich stehe nun vor dem Problem nichts mit meinem bestehenden VPN anfangen zu können, da dieses auf dem Heimrechner schlicht nicht sicht- und benutzbar ist. Wie schon geschrieben stelle ich mir vor, dass nach erfolgreicher Herstellung eines VPNs mit dem Praxisnetz eine neue Netzwerkverbindung hergestellt wird, die Zugriff auf das Praxisnetzwerk möglich macht. Ist diese Vorstellung falsch? Wenn nicht, liegt es wahrscheinlich an der Einstellung virtual Adapter disabled. Dieser liefert vermutlich die Netzwerkverbindung, die ich vermisse.
Ich freue mich auf weitere Antworten
Zitat von @StefanKittel:
> Zitat von @MaeSiuS:
> Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen
zu können.
Vergiss es!
Niemals! > Zitat von @MaeSiuS:
> Mein Plan war über die Clientanwendung der Praxisverwaltungssoftware aus dem Heimnetzwerk den Server der Praxis bedienen
zu können.
Vergiss es!
Wie in meiner Antwort an wiesi200 geschrieben, gibt sich die Clientsoftware auch mit einer ISDN-Wählverbindung zufrieden. Es wird ja nur Text übertragen, keine Befunde oder ähnliches.Deine Lösung heißt erstmal RDP.
Eine ähnliche Lösung erprobe ich gerade mit der proprietären "VNC"-Software Teamviewer.Also entweder einen Terminamlserver wenn mehrere Personen von Außen arbeiten sollen oder RemoteDesktop wenn es nur darum
geht, dass eine Person außerhalb der Arbeitszeiten arbeiten will.
Hier liegt das Problem, die Mitarbeiter können nicht am Rechner arbeiten, wenn der Heimarbeiter aus der Ferne zugreift. Außerdem müssten zusätzlich zum Linux-Server zwei Windows-Rechner permanent eingeschaltet bleiben, da zwei Heimarbeitsplätze existieren. Der ununterbrochenen Rechner-Laufzeit könnte man vielleicht mit einer funktionierendern WOL-Lösung über's Internet Abhilfe schaffen.geht, dass eine Person außerhalb der Arbeitszeiten arbeiten will.
Die VPN-Lösung, in der die Clientsoftware direkt auf dem Heimarbeitsplatz ausgeführt wird (statt ferngesteuert zu werden) ist sinnvoller und eleganter. So man den VPN beherrscht.
Ich stehe nun vor dem Problem nichts mit meinem bestehenden VPN anfangen zu können, da dieses auf dem Heimrechner schlicht nicht sicht- und benutzbar ist. Wie schon geschrieben stelle ich mir vor, dass nach erfolgreicher Herstellung eines VPNs mit dem Praxisnetz eine neue Netzwerkverbindung hergestellt wird, die Zugriff auf das Praxisnetzwerk möglich macht. Ist diese Vorstellung falsch? Wenn nicht, liegt es wahrscheinlich an der Einstellung virtual Adapter disabled. Dieser liefert vermutlich die Netzwerkverbindung, die ich vermisse.
Ich freue mich auf weitere Antworten
Vielleicht solltest du mal einen stabileren VPN Client als den von NetGear verwenden wie z.B. den freien Shrew Client:
http://www.shrew.net/
bzw.
http://www.shrew.net/support/wiki/HowtoNetgear
Damit sollte es problemlos klappen. (Dafür den NetGear Client komplett deinstallieren) NetGear ist im Bereich VPN Hard- und Software nicht gerade ein Ruhmesblatt wie dir die zahllosen Threads hier beweisen...leider. Besser machen sich da Router von Draytek z.B.
So oder so sollte es aber mit dem o.a. Client besser und fehlerfrei klappen.
Generell hast du alles richtig gemacht und man muss auch nichts besonderes beachten oder zusätzlich installieren wenn man denn die grundlegenden VPN Design Regeln zwingend beachtet hat:
VPNs einrichten mit PPTP
P.S.: Den "virtuellen Adapter" kannst du immer sehen, wenn du bei erforlgreicher Herstellung der VPN Verbindung einmal ein ipconfig in der Eingabeaufforderung eingibst. Dort findest du dann den Adapter den der VPN Client einrichtet über den dann der VPN Traffic geroutet wird !
Er ist auch immer ein Indiz dafür das alles korrekt abgelaufen ist beim Aufbau der VPN Verbindung.
Ob alle Routen korrekt laufen kannst du mit dem Kommando route print überprüfen !!
http://www.shrew.net/
bzw.
http://www.shrew.net/support/wiki/HowtoNetgear
Damit sollte es problemlos klappen. (Dafür den NetGear Client komplett deinstallieren) NetGear ist im Bereich VPN Hard- und Software nicht gerade ein Ruhmesblatt wie dir die zahllosen Threads hier beweisen...leider. Besser machen sich da Router von Draytek z.B.
So oder so sollte es aber mit dem o.a. Client besser und fehlerfrei klappen.
Generell hast du alles richtig gemacht und man muss auch nichts besonderes beachten oder zusätzlich installieren wenn man denn die grundlegenden VPN Design Regeln zwingend beachtet hat:
VPNs einrichten mit PPTP
P.S.: Den "virtuellen Adapter" kannst du immer sehen, wenn du bei erforlgreicher Herstellung der VPN Verbindung einmal ein ipconfig in der Eingabeaufforderung eingibst. Dort findest du dann den Adapter den der VPN Client einrichtet über den dann der VPN Traffic geroutet wird !
Er ist auch immer ein Indiz dafür das alles korrekt abgelaufen ist beim Aufbau der VPN Verbindung.
Ob alle Routen korrekt laufen kannst du mit dem Kommando route print überprüfen !!
@aqui,
vielen Dank für die konstruktive Hilfe. Wegen des "virtual adapter" Bug des NetGear Clients wollte ich einen anderen VPN Client ausprobieren. Ich habe bereits die Testversion des "TheGreenBow IPSec VPN Client 4.6" installiert, werde die aber deinstallieren und Ihre Empfehlung nutzen.
Danke auch für den Link zur VPN-Anleitung.
FRAGEN:
Grüße,
MaeSiuS
vielen Dank für die konstruktive Hilfe. Wegen des "virtual adapter" Bug des NetGear Clients wollte ich einen anderen VPN Client ausprobieren. Ich habe bereits die Testversion des "TheGreenBow IPSec VPN Client 4.6" installiert, werde die aber deinstallieren und Ihre Empfehlung nutzen.
Danke auch für den Link zur VPN-Anleitung.
FRAGEN:
- Hat jemand Erfahrung, ob eine erfolgreiche VPN-Nutzung durch einen "Eumex 820 LAN" Router auf Clientseite vereitelt wird? Einstellungen zum Verkehr über die Protokolle ESP oder AH bietet dieser nicht.
- Ich möchte während der VPN-Einrichtung an einem anderen Arbeitsplatz arbeiten, der über devolo DLAN an die Eumex angebunden ist. Wird das Probleme geben?
Grüße,
MaeSiuS
Ein DLAN Link arbeitet wie du ja vermutlich selber weisst als simple Netzwerk Bridge auf Basis der MAC Adressen. Hat also gar keine Ahnung was da IP technisch rübergeht.
Das ist also nicht das Thema und funktioniert sicher... !!
Schlimmer ist da schon der Eumex Router: Generell betreiben alle Consumer DSL Router eine NAT Firewall (Adress Translation). Sie müssten also ein im Internet nicht routebares IP Netzwerk (dein lokales LAN) auf eine öffentliche IP Adresse (die DSL Adresse des Providers) umsetzen.
Dies bedingt dann das eingehende verbindungen von außen generell nicht möglich sind (NAT Firewall)
IPsec das nach einen Sessionrequest eine Verbingung von der VPN Serverseite zum Client aufbaut scheitert als generell IMMER an einem NAT Router. Generell sind also IPsec VPN so gar nicht möglich ! Es gibt aber 2 Ausnahmen:
Generell muss also dein Eumex Router ertsmal VPN Passthrough supporten. Minimal müsstest du eine Port Weiterleitung für UDP 4500 (NAT Traversal) einrichten wenn der Client NAT Traversal kann. Besser UDP 500 und UDP 4500 forwarden. Wenn er VPN Passthrough supportet geht ESP meist dann mit durch.
Ohne das alles wird eine IPsec Verbindung am Eumex Router scheitern !
Du solltest also dann ins Handbuch sehen.
Wäre das der Fall das er all das nicht kann, ist deine einzige Chance dann nur noch ein SSL VPN das über eine normale Webseite und HTTPS rennt oder das sog. SSL VPN für Arme wie es hier beschrieben ist:
VPN für Arme - TCP in SSH tunneln mit Putty
Das ist also nicht das Thema und funktioniert sicher... !!
Schlimmer ist da schon der Eumex Router: Generell betreiben alle Consumer DSL Router eine NAT Firewall (Adress Translation). Sie müssten also ein im Internet nicht routebares IP Netzwerk (dein lokales LAN) auf eine öffentliche IP Adresse (die DSL Adresse des Providers) umsetzen.
Dies bedingt dann das eingehende verbindungen von außen generell nicht möglich sind (NAT Firewall)
IPsec das nach einen Sessionrequest eine Verbingung von der VPN Serverseite zum Client aufbaut scheitert als generell IMMER an einem NAT Router. Generell sind also IPsec VPN so gar nicht möglich ! Es gibt aber 2 Ausnahmen:
- Modernere IPsec Clients bzw. VPN support NAT Traversal. Wie das funktioniert steht hier: http://en.wikipedia.org/wiki/NAT_traversal
- Port Weiterleitung mit ESP und UDP 500 bzw. 4500
Generell muss also dein Eumex Router ertsmal VPN Passthrough supporten. Minimal müsstest du eine Port Weiterleitung für UDP 4500 (NAT Traversal) einrichten wenn der Client NAT Traversal kann. Besser UDP 500 und UDP 4500 forwarden. Wenn er VPN Passthrough supportet geht ESP meist dann mit durch.
Ohne das alles wird eine IPsec Verbindung am Eumex Router scheitern !
Du solltest also dann ins Handbuch sehen.
Wäre das der Fall das er all das nicht kann, ist deine einzige Chance dann nur noch ein SSL VPN das über eine normale Webseite und HTTPS rennt oder das sog. SSL VPN für Arme wie es hier beschrieben ist:
VPN für Arme - TCP in SSH tunneln mit Putty
