RDP über VPN aus virtueller maschine nicht möglich
hallo!
vielleicht kann hier wer weiterhelfen:
ich habe eine virtuelle maschine (vmware workstation) mit windows 7 und einen vpn-client (sonciwall global vpn client) installiert. die vpn-verbindung kann problemlos hergestellt werden aber weder eine verbindung zum server per RDP noch zugriffe auf shares sind möglich (pings kommen erfolgreich an und zurück). folgendes habe ich bereits versucht:
- netzwerkkarte: bridged und nat eingestellt
- firewall: auf allen seiten deaktiviert
- auch mit windows 8 & 10 versucht
grundsätzlich gibt es sonst keine probleme (sprich bei normal installierten geräte - egal welche windows version - funktioniert alles einwandfrei). in einer virtuellen maschine mit windows xp funktioniert es auch...
hat wer eine idee/tipps??
thx4hlp!
renevolution
vielleicht kann hier wer weiterhelfen:
ich habe eine virtuelle maschine (vmware workstation) mit windows 7 und einen vpn-client (sonciwall global vpn client) installiert. die vpn-verbindung kann problemlos hergestellt werden aber weder eine verbindung zum server per RDP noch zugriffe auf shares sind möglich (pings kommen erfolgreich an und zurück). folgendes habe ich bereits versucht:
- netzwerkkarte: bridged und nat eingestellt
- firewall: auf allen seiten deaktiviert
- auch mit windows 8 & 10 versucht
grundsätzlich gibt es sonst keine probleme (sprich bei normal installierten geräte - egal welche windows version - funktioniert alles einwandfrei). in einer virtuellen maschine mit windows xp funktioniert es auch...
hat wer eine idee/tipps??
thx4hlp!
renevolution
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 297706
Url: https://administrator.de/forum/rdp-ueber-vpn-aus-virtueller-maschine-nicht-moeglich-297706.html
Ausgedruckt am: 21.05.2025 um 07:05 Uhr
8 Kommentare
Neuester Kommentar
Was ist denn mit einem ping?
Geht der durch und wird beantwortet?
Oder nen traceroute würde ich mal versuchen...
Einfach nur um mal zu sehen, wohin des Wegs die Pakete fließen.
Geht der durch und wird beantwortet?
Oder nen traceroute würde ich mal versuchen...
Einfach nur um mal zu sehen, wohin des Wegs die Pakete fließen.
- netzwerkkarte: bridged und nat eingestellt
Das ist technischer Blödsinn. Eine Netzwerk Karte kann auf dem Hypervisor niemals in beiden Modi zugleich sein. Es geht entweder nur Bridged oder NAT.NAT wäre in diesem Falle tödlich, denn diverse VPN Protokolle können die NAT Firewall nicht überwinden.
Sinnvoll wäre also hier einzig im Bridge Modus zu arbeiten.
Das setzt dann natürlich voraus das Hypervisor und VMs dann in einem gemeinsamen IP Netzwerk arbeiten, klar !
Leider warst du ja auch in der recht oberflächlichen Beschreibung noch nicht mal in der Lage uns mitzuteilen welches VPN Protokoll du denn verwendest. Wäre für eine zielführende Hilfestellung schon wichtig zu wissen !
P.S.: Deine Shift Taste ist defekt. Solltest du mal reparieren, denn es macht nicht unbedingt Spaß solche Texte lesen zu müssen.
@beidermachtvongreyscull: ja geht beides
Zitat von @aqui:
- netzwerkkarte: bridged und nat eingestellt
Das ist technischer Blödsinn. Eine Netzwerk Karte kann auf dem Hypervisor niemals in beiden Modi zugleich sein. Es geht entweder nur Bridged oder NAT.stimmt! habe mich falsch ausgedrückt, meinte natürlich damit dass ich beide varianten versucht habe...
NAT wäre in diesem Falle tödlich, denn diverse VPN Protokolle können die NAT Firewall nicht überwinden.
Sinnvoll wäre also hier einzig im Bridge Modus zu arbeiten.
Sinnvoll wäre also hier einzig im Bridge Modus zu arbeiten.
das ist ebenfalls technischer blödsinn...
Leider warst du ja auch in der recht oberflächlichen Beschreibung noch nicht mal in der Lage uns mitzuteilen welches VPN Protokoll du denn verwendest. Wäre für eine zielführende Hilfestellung schon wichtig zu wissen !
ich glaube nicht dass das problem vpn seitig ist...
P.S.: Deine Shift Taste ist defekt. Solltest du mal reparieren, denn es macht nicht unbedingt Spaß solche Texte lesen zu müssen.
nö die funktioniert eigenltich ganz gut... bin nur zu faul um sie zu verwenden
Du schreibst, Du nutzt nen Sonicwall-VPN-Client.
Ich nehme an, dann nutzt Du auch eine Sonicwall.
ISt die hinsichtlich VPN so konfiguriert, Ports in beide Richtungen 1:1 durchzulassen?
Ein Ping benötigt keine Zufallsports. Deswegen ist er nur ein grundlegender Indikator, dass Kommunikation möglich wäre.
Hast Du Ihn von beiden Seiten aus probiert?
Denn bei höheren Protokollen muss auch die Serverseite Verbindungen initiieren können.
In welchem IP-Adressraum befinden sich die VPN-Clients nach der Einwahl?
ISt dieser Raum per Routing vom Server aus erreichbar?
Ich nehme an, dann nutzt Du auch eine Sonicwall.
ISt die hinsichtlich VPN so konfiguriert, Ports in beide Richtungen 1:1 durchzulassen?
Ein Ping benötigt keine Zufallsports. Deswegen ist er nur ein grundlegender Indikator, dass Kommunikation möglich wäre.
Hast Du Ihn von beiden Seiten aus probiert?
Denn bei höheren Protokollen muss auch die Serverseite Verbindungen initiieren können.
In welchem IP-Adressraum befinden sich die VPN-Clients nach der Einwahl?
ISt dieser Raum per Routing vom Server aus erreichbar?
@renevolution
So so... wenn NAT so easy ist dann erklär der Community hier mal wie du IPsec oder PPTP über eine NAT Firewall bekommst ohne Port Forwarding.
Dein Statement technischer Blödsinn ist dann selber wieder technischer Blödsinn... Sollte man aber als Netzwerker auch wissen.
Aber wenns gar nicht das VPN ist, dann ist das Netzwerk ja raus...
So so... wenn NAT so easy ist dann erklär der Community hier mal wie du IPsec oder PPTP über eine NAT Firewall bekommst ohne Port Forwarding.
Dein Statement technischer Blödsinn ist dann selber wieder technischer Blödsinn... Sollte man aber als Netzwerker auch wissen.
Aber wenns gar nicht das VPN ist, dann ist das Netzwerk ja raus...
hallo aqui,
also ich würde mich nicht gerade als "netzwerker" bezeichnen...
vielleicht reden wir auch aneinander vorbei, aber soviel ich weiss passiert das nat mapping automatisch wenn eine verbindung von der virtuellen maschine initiiert wird (umgekehrt wärs natürlich nicht möglich ohne dass ein forwarding eingerichtet wird).
also zusammengefasst:
- vpn verbindung wird hergestellt (somit ist jede weitere diskussion über vpn über nat-adapter überflüssig)
- zugriffe auf shares oder verbindungen per rdp (aus der virtuellen maschine ins private netzwerk) funktionieren nicht = DAS IST DAS PROBLEM!
- und noch angemerkt: wenn ich die vpn-verbindung über einen "echten" host (egal welches OS) aufbaue, funktioniert alles reibungslos
daher sagt mir mein analytischer verstand dass es irgendwo an der vmware liegt (und nicht an der firewall-, vpn-verbindung/konfiguration usw..)
also ich würde mich nicht gerade als "netzwerker" bezeichnen...
vielleicht reden wir auch aneinander vorbei, aber soviel ich weiss passiert das nat mapping automatisch wenn eine verbindung von der virtuellen maschine initiiert wird (umgekehrt wärs natürlich nicht möglich ohne dass ein forwarding eingerichtet wird).
also zusammengefasst:
- vpn verbindung wird hergestellt (somit ist jede weitere diskussion über vpn über nat-adapter überflüssig)
- zugriffe auf shares oder verbindungen per rdp (aus der virtuellen maschine ins private netzwerk) funktionieren nicht = DAS IST DAS PROBLEM!
- und noch angemerkt: wenn ich die vpn-verbindung über einen "echten" host (egal welches OS) aufbaue, funktioniert alles reibungslos
daher sagt mir mein analytischer verstand dass es irgendwo an der vmware liegt (und nicht an der firewall-, vpn-verbindung/konfiguration usw..)
Bei dem Fehlerbild ist es in der Tat kein Netzwerk Problem an sich sondern liegt einzig am RDP. Eher ist es vermutlich die lokale Firewall die keine fremden IPs aus dem VPN passieren lässt.
Der Wireshark ist hier dein Freund !!
Was das Mapping einer outbound VPN Verbindung anbetrifft irrst du. Ist aber nicht tragisch bei einem nicht Netzwerker.
Bei PPTP muss z.B. auch auf Client Seite ein GRE (IP Protokoll 47) Forwarding passieren.
Bei IPsec klappt es sofern der Client bzw. der Server NAT Traversal supportet. Ohne das muss dann auch zwingend ESP (IP Protokoll 50) an der NAT Firewall geforwardet werden. GRE und ESP sind eigene IP Protokolle und haben nichts mit UDP oder TCP zu tun.
Bei SSL basierten VPNs auf Basis von UDP oder TCP ist das nicht erforderlich.
Es ist also nicht ganz so trivial wie du als nicht Netzwerker denkst...
P.S.: Deine Shift Taste ist defekt !
Der Wireshark ist hier dein Freund !!
Was das Mapping einer outbound VPN Verbindung anbetrifft irrst du. Ist aber nicht tragisch bei einem nicht Netzwerker.
Bei PPTP muss z.B. auch auf Client Seite ein GRE (IP Protokoll 47) Forwarding passieren.
Bei IPsec klappt es sofern der Client bzw. der Server NAT Traversal supportet. Ohne das muss dann auch zwingend ESP (IP Protokoll 50) an der NAT Firewall geforwardet werden. GRE und ESP sind eigene IP Protokolle und haben nichts mit UDP oder TCP zu tun.
Bei SSL basierten VPNs auf Basis von UDP oder TCP ist das nicht erforderlich.
Es ist also nicht ganz so trivial wie du als nicht Netzwerker denkst...
P.S.: Deine Shift Taste ist defekt !
