14
Remote Desktop Verbindung über Netgear FVS336g und SSL VPN
Hallo liebe Forumgemeinde
ich habe folgendes Problem:
Im Büro steht ein Netgear FVS336g mit einer festen IP. Eine Mitarbeiterin im HomeOffice soll jetzt via SSL VPN einen Zugriff auf einen Rechner im Büro-LAN bekommen und mit RemoteDesktop arbeiten.
Was bi jetzt funzt, ist die Anmeldung über den SSL VPN im IE. Der Tunnel wird aufgebaut und ich kann auch die interne IP anpingen. Aber wenn ich versuche auf dem Client eine RDP Verbindung aufzubauen scheitert die Verbindung mit einem Timeout.
Das ganze ist per TrialAndError eingerichtet worden.
Hat vieleicht jemand ein Tutorial oder irgenwas in der Richtung, was ich wo in der Routeroberfläche einrichten muss, damit das funzt?
Freue mich über jeden Tip.
Gruß
Hans-Peter
ich habe folgendes Problem:
Im Büro steht ein Netgear FVS336g mit einer festen IP. Eine Mitarbeiterin im HomeOffice soll jetzt via SSL VPN einen Zugriff auf einen Rechner im Büro-LAN bekommen und mit RemoteDesktop arbeiten.
Was bi jetzt funzt, ist die Anmeldung über den SSL VPN im IE. Der Tunnel wird aufgebaut und ich kann auch die interne IP anpingen. Aber wenn ich versuche auf dem Client eine RDP Verbindung aufzubauen scheitert die Verbindung mit einem Timeout.
Das ganze ist per TrialAndError eingerichtet worden.
Hat vieleicht jemand ein Tutorial oder irgenwas in der Richtung, was ich wo in der Routeroberfläche einrichten muss, damit das funzt?
Freue mich über jeden Tip.
Gruß
Hans-Peter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 124022
Url: https://administrator.de/forum/remote-desktop-verbindung-ueber-netgear-fvs336g-und-ssl-vpn-124022.html
Ausgedruckt am: 30.12.2024 um 17:12 Uhr
14 Kommentare
Neuester Kommentar
Ein Tutorial ist eigentlich überflüssig, denn das wichtigste hast du ja schon geschafft nämlich den VPN Tunnel zu aktivieren.
Wenn der aktiv ist, also ein Ping wie oben sauber durchgeht, ist deine IP Connectivity ja da.
Damit hast du dann eine transparente Netzanbindung an dein Netzwerk wie ein lokaler Client !
Dein Problem ist also was anderes und vermutlich wie immer hier die Windows Firewall !
Da du aus einem Fremdnetz kommst, blockt die lokale Firewall alle diese Zugriffe ! Du musst also in den erweiterten Firewall Einstellungen für den RDP Dienst (Remotedesktop) unter Bearbeiten den Bereich auf dein VPN Netz anpassen oder die Scheunentorlösung anklicken "Alle Computer einschliesslich Internet" !
Dann wirds auch was mit dem RDP Zugriff !!
Wenn der aktiv ist, also ein Ping wie oben sauber durchgeht, ist deine IP Connectivity ja da.
Damit hast du dann eine transparente Netzanbindung an dein Netzwerk wie ein lokaler Client !
Dein Problem ist also was anderes und vermutlich wie immer hier die Windows Firewall !
Da du aus einem Fremdnetz kommst, blockt die lokale Firewall alle diese Zugriffe ! Du musst also in den erweiterten Firewall Einstellungen für den RDP Dienst (Remotedesktop) unter Bearbeiten den Bereich auf dein VPN Netz anpassen oder die Scheunentorlösung anklicken "Alle Computer einschliesslich Internet" !
Dann wirds auch was mit dem RDP Zugriff !!
Hi Hans-Peter,
kommt Ihr denn intern auf den Rechner per RDP? Nicht dass es noch garnicht aktiviert wurde?
Gruß
Hkhan
kommt Ihr denn intern auf den Rechner per RDP? Nicht dass es noch garnicht aktiviert wurde?
Gruß
Hkhan
Hallo Hkhan
Im internen Netz geht's einwandfrei. RDP öffnen, Rechnername eingeben und Verbinden. Passt.
@aqui
Firewall testweise mal deaktiviert. Hat auch nichts gebracht.
Und der Client kriegt ja auch eine IP aus dem LAN.
Gruß
HaPe
Im internen Netz geht's einwandfrei. RDP öffnen, Rechnername eingeben und Verbinden. Passt.
@aqui
Firewall testweise mal deaktiviert. Hat auch nichts gebracht.
Und der Client kriegt ja auch eine IP aus dem LAN.
Gruß
HaPe
Kannst du den Rechner denn anpingen?
Gib bei der RDP-Verbindung mal nicht den Clientnamen, sondern die IP-Adresse ein.
Gib bei der RDP-Verbindung mal nicht den Clientnamen, sondern die IP-Adresse ein.
Anpingen kann ich den Rechner. Aber dafür muss ich im Router einstellen, das er Pings durchlässt.
Die Verbindung über IP hab ich auch versucht (mach ich eigentlich immer, sicher ist sicher
)
Ich vermute mal, das ich noch irgendwo in der Routeroberfläche was einstellen muss, hab aber keine Ahnung was und wo. Erschwerden kommt hinzu, das ich das Teil auch nicht eingerichtet habe und jetzt quasi "nacharbeite". Und die Routeroberfläche ist, sagen wir mal, unübersichtlich ;-(
Gruß
HaPe
Die Verbindung über IP hab ich auch versucht (mach ich eigentlich immer, sicher ist sicher
)Ich vermute mal, das ich noch irgendwo in der Routeroberfläche was einstellen muss, hab aber keine Ahnung was und wo. Erschwerden kommt hinzu, das ich das Teil auch nicht eingerichtet habe und jetzt quasi "nacharbeite". Und die Routeroberfläche ist, sagen wir mal, unübersichtlich ;-(
Gruß
HaPe
Dann musst du wohl im Router auch einstellen, das er RDP Zugriff zulässt (Port TCP 3389)
Das ist für eine VPN Verbindung aber recht ungewöhnlich, mag aber sein das der NetGear auch für die VLN Verbindung noch eine Firewall betreibt.
Also TCP 3389 freigeben und dann klappts auch mit RDP !
Das ist für eine VPN Verbindung aber recht ungewöhnlich, mag aber sein das der NetGear auch für die VLN Verbindung noch eine Firewall betreibt.
Also TCP 3389 freigeben und dann klappts auch mit RDP !
wenn du dich per VPN einwählst hast du höchstwahrscheinlich eine IP Adresse aus einem anderen IP Adressbereich. In der dazwischenliegenden Firewall muss evtl. eine statische Route eingerichtet werden der die Pakete auf den VPN Router routet...
Oder ist deine Firewall = VPN Gateway?
Oder ist deine Firewall = VPN Gateway?
Steht ja oben das seine Firewall = VPN Gateway = Router ist !!
Ist also Unsinn mit dem Routen, denn er ist ja direkt mit dem VPN Client am Router und damit kennt der ja dann alle IP Netze !
Wenn ein Ping sauber klappt ist die Connectivity ja da !
Das Problem ist vermutlich nur ein Firewall Problem nicht mehr...
Ist also Unsinn mit dem Routen, denn er ist ja direkt mit dem VPN Client am Router und damit kennt der ja dann alle IP Netze !
Wenn ein Ping sauber klappt ist die Connectivity ja da !
Das Problem ist vermutlich nur ein Firewall Problem nicht mehr...
Hmmm, ich würde mal sagen Firewall = VPN Gateway.
Wenn ich mir mit ipconfig die IP's ansehe, habe ich folgende Konstellation.
Interner Rechner: 192.168.1.2 mit 255.255.255.0 Subnet (auf dem soll die RDP Verbing hergestellt werden)
Client (über UMTS oder WLAN): Externe IP vom ISP und IP der VPN Verbindung 192.168.1.101 mit Subnet 255.255.255.0.
Das bescheidene an der sch... Netgearkiste ist, das man auch nirgendwo ein aussagekräfitiges Logfile findet, an dem ich sehen kann, was an Traffic / Anfragen ankommt.
Ich sehe, das sich der User über VPN angemeldet hat und das wars.
@aqui
Das denke ich auch. Ich habe schon mit eineigen VPN's gearbeitet und kenne es nur so. Tunnel aufgebaut und schon kann ich wie im lokalen Netz bewegen.
Hab leider keine Ahnung von dieser Netgearkiste und die Doku ist auch eher lau.
Naja, werd's heute Abend noch mal ein paar Möglichkeiten ausprobieren
Danke erstmal für die Anregungen
Gruß
HaPe
Wenn ich mir mit ipconfig die IP's ansehe, habe ich folgende Konstellation.
Interner Rechner: 192.168.1.2 mit 255.255.255.0 Subnet (auf dem soll die RDP Verbing hergestellt werden)
Client (über UMTS oder WLAN): Externe IP vom ISP und IP der VPN Verbindung 192.168.1.101 mit Subnet 255.255.255.0.
Das bescheidene an der sch... Netgearkiste ist, das man auch nirgendwo ein aussagekräfitiges Logfile findet, an dem ich sehen kann, was an Traffic / Anfragen ankommt.
Ich sehe, das sich der User über VPN angemeldet hat und das wars.
@aqui
Das denke ich auch. Ich habe schon mit eineigen VPN's gearbeitet und kenne es nur so. Tunnel aufgebaut und schon kann ich wie im lokalen Netz bewegen.
Hab leider keine Ahnung von dieser Netgearkiste und die Doku ist auch eher lau.
Naja, werd's heute Abend noch mal ein paar Möglichkeiten ausprobieren
Danke erstmal für die Anregungen
Gruß
HaPe
OK, mit deiner IP Liste ist der Fehler eindeutig:
Du bekommst vom Mobilfunk Provider im Funknetz keine öffentliche IP sondern eine private IP aus dem RFC 1918
http://de.wikipedia.org/wiki/Private_IP-Adresse
Die Adress Translation macht dann zentral der Mobilfunk Provider. Damit ist generell keinerlei VPN Traffic möglich da lediglich eine billiger Surf Tarif.
Dieser Thread erklärt dir alles im Detail:
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Oder meinst du mit deiner Beschreibung oben "externe IP vom ISP" dann doch noch zusätzlich die öffentliche IP ?? Das ist nicht ganz verständlich ?!
Bedenke das es bei VPN Betrieb nicht sehr intelligent ist eine 192.168.1.0 er IP Allerwelt Adresse zu verwenden, da die beiden Netze immer zwangsweise unterschiedlich sein MÜSSEN.
Mit der 192.168.1.0 er Allerwelts IP wirds du immer und immer wieder in Adressprobleme laufen !
Details zum Warum erklärt dir dieses Tutorial:
VPNs einrichten mit PPTP
Hättest du statt der NetGear Krücke einen richtigen VPN Router beschafft wie z.B. einen Draytek der das besser kann, dann hättest du auch aussagekräftige Log Files !!
Du bekommst vom Mobilfunk Provider im Funknetz keine öffentliche IP sondern eine private IP aus dem RFC 1918
http://de.wikipedia.org/wiki/Private_IP-Adresse
Die Adress Translation macht dann zentral der Mobilfunk Provider. Damit ist generell keinerlei VPN Traffic möglich da lediglich eine billiger Surf Tarif.
Dieser Thread erklärt dir alles im Detail:
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Oder meinst du mit deiner Beschreibung oben "externe IP vom ISP" dann doch noch zusätzlich die öffentliche IP ?? Das ist nicht ganz verständlich ?!
Bedenke das es bei VPN Betrieb nicht sehr intelligent ist eine 192.168.1.0 er IP Allerwelt Adresse zu verwenden, da die beiden Netze immer zwangsweise unterschiedlich sein MÜSSEN.
Mit der 192.168.1.0 er Allerwelts IP wirds du immer und immer wieder in Adressprobleme laufen !
Details zum Warum erklärt dir dieses Tutorial:
VPNs einrichten mit PPTP
Hättest du statt der NetGear Krücke einen richtigen VPN Router beschafft wie z.B. einen Draytek der das besser kann, dann hättest du auch aussagekräftige Log Files !!
Tja, dem ist nichts hinzuzufügen
Wie schon mal oben kurz beschrieben, bin ich wie die Jungfrau zum Kinde gekommen.
Ein Bekannter hat das Teil angeschaft, ein Kumpel von ihm hat das Teil eingerichtet, sodaß erstmal alle aus dem internen Netz raus kommen, dann hat ein Dritter die gloreiche Idee gehabt, das man ja auch über VPN von draussen arbeiten könnte und dann ...
... zwei Monat später komm ich in Spiel, weil keiner der anderen das ans laufen kriegt und ich quasi der Einäugige unter den Blinden bin. So nach dem Motto: "Kannst Du nicht mal gucken, was da nicht läuft?"
Also, kurz gestern abend in den Router geschaut, am Kinn gekratzt und gesagt "Hmmm, mal in die Doku schauen." Und siehe da, keine vorhanden, Online-Hilfe ist für den selbigen und deshalb mal gefragt ob sich jemand mit dem Teil auskennt (deswegen ja die Frage nach nem Tutorial)
Zu der externen IP:
Ich hab's gestern abend mal kurz mit einem Notebook versucht, welches über einen UMTS-Stick online ging !?!? (Beim meinem MacBook mit dem Firmennetz geht VPN über UMTS ??????)
Allerdings müsste es doch gehen, wenn ich mit Notebook über WLAN/LAN von woanders versuche zu verbinden?
Fragen über Fragen
Werd mir mal Deine Links in Ruhe durchlesen
Gruß
HaPe
Nachtrag:
Habe mir gerade mal den Link zu "Information und Erfahrungsbericht zu SSL-VPNs" durchgelesen.
Wenn ich das richtig verstehe (?!) laüft der Traffic bei SSL-VPN über den Port 443.
In meinem Beispiel ist es nämlich genau so: Auf dem Client wird die https-Adresse des Routers aufgerufen, dann kommt die Autentifzierung am Router, ein ActiveX wird installiert und dann der Tunnel aufgebaut. Zusaätzlich kann ich noch ein ActiveX fürs PortForwarding installieren.
Das erste ActiveX installiert eine neue Netzwerkarte xyz-vpn-isdn über die dann der Traffic läuft, aber was macht das PortForwarding ActiveX?
Hmmm, beim nächsten mal sag ich einfach: "Keine Ahnung." und mach mich vom Acker
Wie schon mal oben kurz beschrieben, bin ich wie die Jungfrau zum Kinde gekommen.
Ein Bekannter hat das Teil angeschaft, ein Kumpel von ihm hat das Teil eingerichtet, sodaß erstmal alle aus dem internen Netz raus kommen, dann hat ein Dritter die gloreiche Idee gehabt, das man ja auch über VPN von draussen arbeiten könnte und dann ...
... zwei Monat später komm ich in Spiel, weil keiner der anderen das ans laufen kriegt und ich quasi der Einäugige unter den Blinden bin. So nach dem Motto: "Kannst Du nicht mal gucken, was da nicht läuft?"
Also, kurz gestern abend in den Router geschaut, am Kinn gekratzt und gesagt "Hmmm, mal in die Doku schauen." Und siehe da, keine vorhanden, Online-Hilfe ist für den selbigen und deshalb mal gefragt ob sich jemand mit dem Teil auskennt (deswegen ja die Frage nach nem Tutorial)
Zu der externen IP:
Ich hab's gestern abend mal kurz mit einem Notebook versucht, welches über einen UMTS-Stick online ging !?!? (Beim meinem MacBook mit dem Firmennetz geht VPN über UMTS ??????)
Allerdings müsste es doch gehen, wenn ich mit Notebook über WLAN/LAN von woanders versuche zu verbinden?
Fragen über Fragen
Werd mir mal Deine Links in Ruhe durchlesen
Gruß
HaPe
Nachtrag:
Habe mir gerade mal den Link zu "Information und Erfahrungsbericht zu SSL-VPNs" durchgelesen.
Wenn ich das richtig verstehe (?!) laüft der Traffic bei SSL-VPN über den Port 443.
In meinem Beispiel ist es nämlich genau so: Auf dem Client wird die https-Adresse des Routers aufgerufen, dann kommt die Autentifzierung am Router, ein ActiveX wird installiert und dann der Tunnel aufgebaut. Zusaätzlich kann ich noch ein ActiveX fürs PortForwarding installieren.
Das erste ActiveX installiert eine neue Netzwerkarte xyz-vpn-isdn über die dann der Traffic läuft, aber was macht das PortForwarding ActiveX?
Hmmm, beim nächsten mal sag ich einfach: "Keine Ahnung." und mach mich vom Acker
Auf der US Seite findest du die komplette Dokumentation (Handbücher) und auch jede Menge HowTos wie man sowas im Handumdrehen zum Fliegen bringt !
http://kb.netgear.com/app/products/model/a_id/2425
bzw.
http://kb.netgear.com/app/answers/detail/a_id/10877
Mit letzterem Dokument sollte auch eine Jungfrau mit Kind das locker hinbekommen...
Die aktuelle Firmware solltest du auch unbedingt auf der Maschine haben:
http://www.netgear.de/de/Support/download.html?func=Detail&id=12593
die fixt noch eine Menge Bugs in älterer Firmware !!
http://kb.netgear.com/app/products/model/a_id/2425
bzw.
http://kb.netgear.com/app/answers/detail/a_id/10877
Mit letzterem Dokument sollte auch eine Jungfrau mit Kind das locker hinbekommen...
Die aktuelle Firmware solltest du auch unbedingt auf der Maschine haben:
http://www.netgear.de/de/Support/download.html?func=Detail&id=12593
die fixt noch eine Menge Bugs in älterer Firmware !!
Werde ich Wochenende mal probieren. Wenn das geht, werd ich nochmal über das Thema Verhütung nachdenken
Erst mal vielen Dank
Gruß
HaPe
Erst mal vielen Dank
Gruß
HaPe
So, das Thema ist für's erste geklärt.
Der Router wird mit zwei DSL Leitungen betrieben. Eine mit eine festen IP und eine mit einem "normalen" DSL Zugang.
Nachdem der zweite DSL Zugang ausgeschaltet ist und man nur noch über die feste IP reinkommt, funktioniert es auch mit dem PortForwarding.
Jetzt muss ich mal schauen, wie ich in dem Router konfigurieren kann, wann das Teil wir routet. Aber dafür werd ich mir mal ein bisschen Zeit nehmen.
Erst mal vielen Dank für die Tipps und Hinweise.
Gruß
HaPe
PS: Zum Thema Verhütung... bei zwei Zugängen sollte man(n) immer überprüfen, welcher der richtige ist
Der Router wird mit zwei DSL Leitungen betrieben. Eine mit eine festen IP und eine mit einem "normalen" DSL Zugang.
Nachdem der zweite DSL Zugang ausgeschaltet ist und man nur noch über die feste IP reinkommt, funktioniert es auch mit dem PortForwarding.
Jetzt muss ich mal schauen, wie ich in dem Router konfigurieren kann, wann das Teil wir routet. Aber dafür werd ich mir mal ein bisschen Zeit nehmen.
Erst mal vielen Dank für die Tipps und Hinweise.
Gruß
HaPe
PS: Zum Thema Verhütung... bei zwei Zugängen sollte man(n) immer überprüfen, welcher der richtige ist
