8
Remote Desktop über LAN funktioniert, über WAN trotz Port Forwarding nicht
Hallo Experten,
ich habe ein Problem mit meinem Windows Server 2012 R2 bzgl. Remote Desktop.
Die RDP Verbindung im LAN klappt ohne Probleme. Jetzt wollte ich mir den Zugang per RDP auch von extern einrichten und scheitere dabei leider.
- Der Server hat eine fixe IP: 192.168.1.99
- meine WAN IP ist seit ca. 1 Jahr fix (verwende (noch) kein DynDNS)
- Der Port 3389 wird von meinem ASUS Router (TCP) an die IP Adresse weitergeleitet. (UDP und BOTH auch schon getestet)
- Ich teste anschließend ob der Port geöffnet ist und erhalte dabei immer die Fehlermeldung, dass dem nicht so ist (z.B. http://www.yougetsignal.com/tools/open-ports/).
- Die Firewall am Windows Server ist komplett deaktiviert.
- Laut "netstat -ano" wird der Port 3389 "abgehört". (eigentlich klar, LAN RDP funktioniert ja)
Ich habe für einen anderen Zweck (Bus System Steuerung von extern) einen Port an meinen Web Server des Bussystems weitergeleitet, das klappt wunderbar. Auch der Port Checker zeigt an, dass der Port geöffnet ist.
Daher gehe ich davon aus, dass der Forward richtig funktioniert und der Fehler eigentlich am Server liegen muss?
Was kann ich noch tun / prüfen? Ich bin mit meinen (beschränkten) Netzwerk Kenntnissen nun am Ende.
Vielen Dank schon mal vorab!
LG,
Mario
ich habe ein Problem mit meinem Windows Server 2012 R2 bzgl. Remote Desktop.
Die RDP Verbindung im LAN klappt ohne Probleme. Jetzt wollte ich mir den Zugang per RDP auch von extern einrichten und scheitere dabei leider.
- Der Server hat eine fixe IP: 192.168.1.99
- meine WAN IP ist seit ca. 1 Jahr fix (verwende (noch) kein DynDNS)
- Der Port 3389 wird von meinem ASUS Router (TCP) an die IP Adresse weitergeleitet. (UDP und BOTH auch schon getestet)
- Ich teste anschließend ob der Port geöffnet ist und erhalte dabei immer die Fehlermeldung, dass dem nicht so ist (z.B. http://www.yougetsignal.com/tools/open-ports/).
- Die Firewall am Windows Server ist komplett deaktiviert.
- Laut "netstat -ano" wird der Port 3389 "abgehört". (eigentlich klar, LAN RDP funktioniert ja)
Ich habe für einen anderen Zweck (Bus System Steuerung von extern) einen Port an meinen Web Server des Bussystems weitergeleitet, das klappt wunderbar. Auch der Port Checker zeigt an, dass der Port geöffnet ist.
Daher gehe ich davon aus, dass der Forward richtig funktioniert und der Fehler eigentlich am Server liegen muss?
Was kann ich noch tun / prüfen? Ich bin mit meinen (beschränkten) Netzwerk Kenntnissen nun am Ende.
Vielen Dank schon mal vorab!
LG,
Mario
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: 317721
Url: https://administrator.de/forum/remote-desktop-ueber-lan-funktioniert-ueber-wan-trotz-port-forwarding-nicht-317721.html
Ausgedruckt am: 03.04.2025 um 16:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
???
LG, Thomas
Der Port 3389 wird von meinem ASUS Router (TCP) an die IP Adresse weitergeleitet.
Die Firewall am Windows Server ist komplett deaktiviert.
ich such noch Jemanden, der mir mein LAN so unsicher wie möglich konfiguriert ... Interesse Die Firewall am Windows Server ist komplett deaktiviert.
???LG, Thomas
2
Hallo,
RDP NUR ÜBER VPN wenn man kein VPN machen kann dann auch kein RDP.
RDP so im Internet ist gleichbedeutend mit Rechner mit Monitor, Tastatur und Maus in die Fußgängerzone stellen, jeder darfmal..
RDP ist default nur aus dem eigenen Netzwerk erlaubt.
Gruß
Chonta
Die Firewall am Windows Server ist komplett deaktiviert.
NCRDP NUR ÜBER VPN wenn man kein VPN machen kann dann auch kein RDP.
RDP so im Internet ist gleichbedeutend mit Rechner mit Monitor, Tastatur und Maus in die Fußgängerzone stellen, jeder darfmal..
RDP ist default nur aus dem eigenen Netzwerk erlaubt.
Gruß
Chonta
Zitat von @keine-ahnung:
ich such noch Jemanden, der mir mein LAN so unsicher wie möglich konfiguriert ... Interesse???
Danke, YMMD ich such noch Jemanden, der mir mein LAN so unsicher wie möglich konfiguriert ... Interesse
???
Hallo,
jetzt macht ihn nicht alle fertig.
Auch für das testen, ist es nicht gerade toll,
einen sehr unsicheren Zugang öffentlich freizugeben.
Wie versuchst du von außen auf den RDP Client zuzugreifen ?
Eventuell liege ich falsch, aber ich nehme an du musst dennoch beim Zugriff den Port angeben.
Auch wenn es der Standard Port ist, da der ASUS Router ja die Ports an die internen IPs weitergibt.
Darf ich annehmen das der Asus Router, auch das Modem ist ?
Mein Tipp:
ändere den Port den du auf machst, auf einen anderen.
Dreh die Firewall auf, und mach lieber spezielle Ports auf.
Falls der PC durch gängig erreicht werden soll vom Internet aus,
wäre eine kleine Überwachung der Aktivitäten am PC ratsam.
Lg
jetzt macht ihn nicht alle fertig.
Auch für das testen, ist es nicht gerade toll,
einen sehr unsicheren Zugang öffentlich freizugeben.
Wie versuchst du von außen auf den RDP Client zuzugreifen ?
Eventuell liege ich falsch, aber ich nehme an du musst dennoch beim Zugriff den Port angeben.
Auch wenn es der Standard Port ist, da der ASUS Router ja die Ports an die internen IPs weitergibt.
Darf ich annehmen das der Asus Router, auch das Modem ist ?
Mein Tipp:
ändere den Port den du auf machst, auf einen anderen.
Dreh die Firewall auf, und mach lieber spezielle Ports auf.
Falls der PC durch gängig erreicht werden soll vom Internet aus,
wäre eine kleine Überwachung der Aktivitäten am PC ratsam.
Lg
Man kann das ja ganz einfach prüfen ob das Port Forwarding des Asus Routers klappt indem man auf dem Server mal einen Wireshark startet oder den Microsoft NetMonitor.
Wenn man das nicht auf dem Server installieren möchte nimmt man eben einen Laptop den man statisch die gleiche IP Adresse wie den Server gibt. Server dann natürlich temporär vom Switch abklemmen !!
Sieht man dort eingehende TCP 3389 Pakete vom externen RDP Client funktioniert das.
Sieht man sie nicht, dann funktioniert das Port Forwarding im Router nicht.
So einfach ist das.
Verwunderlich das der TO auf so einen einfachen Test nicht kommt bei der strategischen Fehlersuche.
So oder so ist VPN die bessere und sicherere Lösung. Bei schlichtem Port Forwarding kann die ganze Welt seine RDP Daten mitlesen !
Wenn man das nicht auf dem Server installieren möchte nimmt man eben einen Laptop den man statisch die gleiche IP Adresse wie den Server gibt. Server dann natürlich temporär vom Switch abklemmen !!
Sieht man dort eingehende TCP 3389 Pakete vom externen RDP Client funktioniert das.
Sieht man sie nicht, dann funktioniert das Port Forwarding im Router nicht.
So einfach ist das.
Verwunderlich das der TO auf so einen einfachen Test nicht kommt bei der strategischen Fehlersuche.
So oder so ist VPN die bessere und sicherere Lösung. Bei schlichtem Port Forwarding kann die ganze Welt seine RDP Daten mitlesen !
Moin,
klingt nach "Authentifizierung auf Netzwerkebene".
Gruß Krämer
PS: Wenn du das dann auch noch ausgestellt hast, solltest du so ziemlich jeden Sicherheitsmechanismus gekillt haben.
klingt nach "Authentifizierung auf Netzwerkebene".
Gruß Krämer
PS: Wenn du das dann auch noch ausgestellt hast, solltest du so ziemlich jeden Sicherheitsmechanismus gekillt haben.
1
Hast du die Systemeigenschaft angepasst:
Hallo,
Benutze doch einfach mal VPN und verzichte doch bitte auf umnötige Portweiterleitungen, wen es garnicht anders geht.
Ist es ein Multi Homed System? Stelle sicher das dein Gateway auf den die Port Weiterleitung läuft höchste Priorität hat.
Stelle sicher das dein Terminal Server den du freigeben möchtest auch auf dein Gateway zeigt (Standart Gateway)
Stelle sicher das du auf die richtige IP-Addresse weitergeleitet hast. (Stelle die IP sonst Sstatisch ein auserhalb der DHCP-Ranges)
Gruß an die IT-Welt,
J Herbrich
Benutze doch einfach mal VPN und verzichte doch bitte auf umnötige Portweiterleitungen, wen es garnicht anders geht.
Ist es ein Multi Homed System? Stelle sicher das dein Gateway auf den die Port Weiterleitung läuft höchste Priorität hat.
Stelle sicher das dein Terminal Server den du freigeben möchtest auch auf dein Gateway zeigt (Standart Gateway)
Stelle sicher das du auf die richtige IP-Addresse weitergeleitet hast. (Stelle die IP sonst Sstatisch ein auserhalb der DHCP-Ranges)
Gruß an die IT-Welt,
J Herbrich
