mikeaul 10 Geschrieben 21. Oktober 2010 Melden Teilen Geschrieben 21. Oktober 2010 Hallo, habe folgendes Problem und hoffe, dass mir jemand helfen kann: WINDOWS 2003 Server mit Terminalserver hängt hinter einem Router. Lokale Netzverbindungen über Remotedektop nimmt der Server an, funktioniert einwandfrei. Auf dem Router ist eine Portweiterleitung des RDP-Ports 3389 konfiguriert. Sie funktioniert auch (mit 2. PC getestet). Verbindungen über den Router von aussen über das Internet nimmt der Server aber nicht an. Firewall ist aufgrund der Fehlersuche ausgeschaltet. Weiß nicht weiter. Danke für die Hilfe und beste Grüße Zitieren Link zu diesem Kommentar
djmaker 95 Geschrieben 21. Oktober 2010 Melden Teilen Geschrieben 21. Oktober 2010 Ich würde mal behaupten das dem TS das Standardgateway (Router) fehlt. Zitieren Link zu diesem Kommentar
lemeid 11 Geschrieben 22. Oktober 2010 Melden Teilen Geschrieben 22. Oktober 2010 Hallo,habe folgendes Problem und hoffe, dass mir jemand helfen kann: WINDOWS 2003 Server mit Terminalserver hängt hinter einem Router. Lokale Netzverbindungen über Remotedektop nimmt der Server an, funktioniert einwandfrei. Auf dem Router ist eine Portweiterleitung des RDP-Ports 3389 konfiguriert. Sie funktioniert auch (mit 2. PC getestet). Verbindungen über den Router von aussen über das Internet nimmt der Server aber nicht an. Firewall ist aufgrund der Fehlersuche ausgeschaltet. Weiß nicht weiter. Danke für die Hilfe und beste Grüße Hallo, wie hast Du es denn jetzt getestet? Lokal funktioniert es. Aus dem Internet nicht. Du schreibst "(mit 2. PC getestet)". Hast Du den Port auf den 2.PC gelegt und Dich übers Internet eingewählt? Oder das ganze auch im internen Netz gemacht? Find nur ich es gefährlich den Server direkt hinter einem Router mit weitergeleitetem RDP Port stehen zu haben? Ich würde mir da Gedanken über VPN machen. Gruß Stefan Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 22. Oktober 2010 Melden Teilen Geschrieben 22. Oktober 2010 Oder SSL für RDP. Muss ja nicht immer sofort ein VPN sein. Zitieren Link zu diesem Kommentar
perren 10 Geschrieben 22. Oktober 2010 Melden Teilen Geschrieben 22. Oktober 2010 Was heißt "mit zweitem PC getestet"? Auch von außen? Oder hast Du da vom LAN aus angegriffen? Du musst schon Details vom Router hier angeben, NATed er korrekt zum Server? Was sagt evt. Telnet von innen und von außen? Ausserdem würde ich den Dienst nicht an das externe Interface hängen, sondern da openssl/ein VPN dazwischenpacken (nicht ganz trivial). Zitieren Link zu diesem Kommentar
mikeaul 10 Geschrieben 22. Oktober 2010 Autor Melden Teilen Geschrieben 22. Oktober 2010 Was heißt "mit zweitem PC getestet"? Auch von außen? Oder hast Du da vom LAN aus angegriffen?Du musst schon Details vom Router hier angeben, NATed er korrekt zum Server? Was sagt evt. Telnet von innen und von außen? Ausserdem würde ich den Dienst nicht an das externe Interface hängen, sondern da openssl/ein VPN dazwischenpacken (nicht ganz trivial). Hallo, Danke für die Rückmeldung(en)! Hab die Portweiterleitung an einen anderen PC geschaltet, dann eine RDP-Verbindung von aussen (über's Internet) gestartet. Das hat funktioniert, der 2. PC nimmt die Verbindung an (XP-SP2). Daher gehe ich davon aus, dass es nicht am Router und der Portweiterleitung liegt. Über VPN-Verbindung ist auch mein "Problemserver" erreichbar. Arbeite hier mit einer Client-Software (SHREW). Dies ist meine produktive Verbindung im Echtbetrieb. Hier hab ich das Problem, dass die Verbindungen unregelmäßig abgebrochen werden (von 0 bis 5 mal am Tag). Die Fehlerursache liegt nicht in der Leitung (Telekom hat mehrfach und auch Dauerprüfungen vorgenommen), ich vermute, die Neugeneriereung der VPN-Schlüssel führt zu dieser Instabilität. Um dieses Problem einzugrenzen, will ich die Portweiterleitung prüfen. Bleibt diese stabil, ist es weder die Leitung, noch die Hardware. Bleibt also gegebenenfalls ein VPN-Problem. Die Portweiterleitung ist auch meiner Ansicht nach die 2. beste Lösung, aber der Verbindungsabbruch mit VPN-Tunneln ist keine wirklich praktikable Lösung. Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 22. Oktober 2010 Melden Teilen Geschrieben 22. Oktober 2010 Nabend mikeaul, kann man in den Terminalserver-Einstellungen des Servers nicht festlegen, für welche NW-Karte die Verbindung erlaubt wird? Hast Du denn mehr als eine Karte aktiv? Zitieren Link zu diesem Kommentar
mikeaul 10 Geschrieben 24. Oktober 2010 Autor Melden Teilen Geschrieben 24. Oktober 2010 Nabend mikeaul, kann man in den Terminalserver-Einstellungen des Servers nicht festlegen, für welche NW-Karte die Verbindung erlaubt wird? Hast Du denn mehr als eine Karte aktiv? Der Terminalserver besitzt 2 Karten mit 2 privaten Adressbereichen. Der 1. Adressbereich arbeitet mit dem LAN, der 2. hängt am Router, der nur für die Verbindung von aussen zuständig ist. Der Router besitzt eine feste öffentliche IP, unter der er im Internet zu finden ist. Am Router hängen unter dem privaten Adressbereich nur 2 PCs, der Terminalserver und der Test-PC, den ich angeschlossen habe, um die Portweiterleitung zu testen, die mit dem Terminalserver ja leider nicht funktionieren. DerTest PC ist ein Windows XP SP2 Rechner. Da die Anmeldung über VPN am Terminalserver funktioniert, kann es eigentlich nicht am privaten Adressraum hängen, da die VPN-Clients den selben Adressbereich verwenden, wie der Router bzw. der Terminalserver mit der 2. Karte. Viele Grüße und Dankeschön für die Unterstützung Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 24. Oktober 2010 Melden Teilen Geschrieben 24. Oktober 2010 Würde noch folgendes testen: Crossover-Kabel vom Test-Client an den TS direkt anschließen und RDP-Verbindung testen. Klappt die Verbindung nicht, liegt es jedenfalls schon mal nicht am Router (was ja eigentlich schon klar ist). Ich gehe mal davon aus, dass in der Terminaldienste-Konfiguration unter Verbindungen / RDP-TCP nur die eine Netzwerkkarte ins lokale Netz ausgewählt ist: Frag mich dann nur, warum das dann per VPN funktioniert(?) Falls das auch nicht zutrifft, bitte mal prüfen, ob beide NW-Karten den Router als Standard-Gateway eingestellt haben. Hat djmaker übrigens schon mal drauf hingewiesen: Ich würde mal behaupten das dem TS das Standardgateway (Router) fehlt. Zitieren Link zu diesem Kommentar
mikeaul 10 Geschrieben 25. Oktober 2010 Autor Melden Teilen Geschrieben 25. Oktober 2010 Würde noch folgendes testen: Crossover-Kabel vom Test-Client an den TS direkt anschließen und RDP-Verbindung testen. Klappt die Verbindung nicht, liegt es jedenfalls schon mal nicht am Router (was ja eigentlich schon klar ist). Ich gehe mal davon aus, dass in der Terminaldienste-Konfiguration unter Verbindungen / RDP-TCP nur die eine Netzwerkkarte ins lokale Netz ausgewählt ist: [ATTACH]5240[/ATTACH] Frag mich dann nur, warum das dann per VPN funktioniert(?) Falls das auch nicht zutrifft, bitte mal prüfen, ob beide NW-Karten den Router als Standard-Gateway eingestellt haben. Hat djmaker übrigens schon mal drauf hingewiesen: Hallo, tatsächlich hatte ich nur die Netzwerkkarte geprüft, die am Router hängt. Hier war und ist immer noch das Standardgateway auf den Router gesetzt. Nach diesem Hinweis hab ich die Netzwerkkarte für das LAN nochmals geprüft, hier war tatsächlich über DHCP ein anderes Standardgateway eingetragen. Nachdem ich auch hier die IP des Routers eingetragen habe, funktioniert die Portweiterleitung. Ich versteh zwar nicht, warum bisher (nur) die VPN-Verbindungen angenommen wurden und nur die Portweiterleitung nicht, aber offenbar liegt hier die Lösung meines Problems. Vielen Dank nochmal allen, die sich Gedanken gemacht haben und vielen Dank für die Ratschlage. Viele Grüße Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 25. Oktober 2010 Melden Teilen Geschrieben 25. Oktober 2010 Nachdem ich auch hier die IP des Routers eingetragen habe, funktioniert die Portweiterleitung. Na also. Schön, dass wir Dir helfen konnten und danke für Deine Rückmeldung :) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.