[Gelöst]RDP von extern auf Win 2008R2 nicht möglich

carcharoth

Enthusiast
Thread Starter
Mitglied seit
06.03.2007
Beiträge
483
Ort
Schweiz
Hallo,

mein Windows 2008 R2 Server ist von extern nicht erreichbar.
Aufgebaut ist das Netzwerk wie folgt.


(Internet)---(Router)-----(Gigabit-Switch)

Am Switch hängt der Win2008 Server, ein Win7 Client und noch anderer kleinkram.


Ping von Server auf Win7 und vice versa geht ohne Probleme solange man nur auf die IP pingt. Wenn ich auf den Servernamen pingen will, kann der Router den Namen nicht auflösen. Ping auf Clientname geht aber.
RDP intern geht auch, solangs auf die IP ist. RDP auf den Rechnernamen geht nicht.
IPs sind alle statisch verteilt. 192.168.1.x


Routereinstellungen:
Als DNS ist bei beiden Rechnern jeweils der Router eingestellt.
Gerät ist von aussen über DynDNS erreichbar. Ping auf die Adresse funktioniert, der Router gibt Antwort.
Port 3389 ist per NAT auf dem Router an den Server weitergeleitet.

Und hier fängt das Problem an. Laut dem Heise-Portscan ist 3389 offen und erreichbar. Laut anderen Portscannern gibt das Gerät hinter dem Port keine Antwort.

Ich habe testweise auch die Firewall vom Server deaktiviert. Bringt auch nichts.
Telnet auf den Port hilft auch nicht.

Woran könnte es noch liegen? Andere Portweiterleitungen auf dem Router machen keine Probleme (z.b. 5001, 21, etc...)
Mir gehen langsam die Ideen aus.


Ich hoff ich habs nicht zu kompliziert beschrieben :)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Du testest jetzt RDP von dem Windows 7 PC, der im gleichen Netz steht wie der Server, über das Internet (DynDNS)?
Oder willst du dich über ein drittes Gerät (z.b. dein Privat PC) in das Netz einwählen?

Wenn der Win 7 PC den Server schon nicht per Namen pingen kann (und umgekehrt) würde ich dein DNS mal auf Fehler überprüfen.
Kannst auch mal testen, ob es funktioniert wenn du die IP's in die Host Datei einträgst...


LG
 
Ich teste beides. Intern im selben Netz gehts.

Vom Win7-Rechner der intern ist über die externe Adresse des Servers geht nicht.
Danach hab ich nen Bekannten gefragt, ob er von sich aus auf den Server kommt (telnet und rdp). Ging auch nicht.

Ping über Rechnername von Client auf Server geht nicht. Aber von Server auf Client geht. D.h. es ist nur einseitig "kaputt".
DNS "Prüfen" kann ich nicht wirklich, da der Router ne Netopia Schrottkiste ist, die kein vernünftiges Management hat.

IP in die hosts Datei wär nur Symptombekämpfung. Das Problem liegt ja soweit ersichtlich auf dem Router, nicht am Client.


Was vllt. noch zu erwähnen ist: Ich hab den Server ca. nach 2 Tagen Betrieb umbenannt. Vorher hiess er irgendwas mit "WS-H235OR34" oder sowas in der Art. Halt n kryptischer Zufallsname der per default vergeben wird. Der Router hat den neuen Namen aber nicht sofort erkannt und zur IP noch den falschen Namen angezeigt.
Danach hab ich manuell die IP geändert, damit er aufm Router als neues Gerät erkannt wird. Nun wird er intern wenigstens normal aufgelistet. Nur wird der neue Name nicht angezeigt... (wobei er das eh nur bei wenigen Geräten macht. Die sind aber trotzdem erreichbar.)
 
Firewall war ja schon aus. Könnte ja sein, dass da eine Richtlinie blockiert, was ich mir gut vorstellen könnte. 0711 wüsste sicher woran es liegt. ;)

Die Richtlinien werden soweit ich weiss über die erweiterte Firewall gesteuert. Da gibts bei den beiden RDP Inbound-Einträgen ne Option, die Edge-Traffic nicht erlaubt. Die hab ich testweise enabled. Ohne Erfolg. Danach hab ich wie erwähnt die gesamte Firewall ausgeschaltet, bringt auch nichts.

Oder meinst du andere Richtlinien? Falls ja, wo und welche? ;)
 
Ich habs grad nochmal mit ner virtuellen WinXP Maschine getestet die eine andere IP hat und vom Router mit DNS-Name erkennt wird und auch per Name pingbar ist. Auch da geht RDP nicht wenn man von extern draufwill. Intern gehts.

Ich nerv mal meinen Provider... würd mich nich wundern wenn die das geblockt haben.

Edit:
Hab grad angerufen wegen Portfreigabe...
"Wir können Ihnen höchstens zeigen, wo man den freigeben kann, aber das wissen Sie ja bereits." - "Ja, aber mir würd schon die Bestätigung reichen, dass gewisse Ports nicht geblockt werden." - "Kann ich Ihnen leider nicht sagen." - "Sie müssen doch irgendwo ne Liste mit den Ports haben?" - "Nein." (LOL?) - "Können Sie mich wenigstens an einen Techniker weiterverbinden?" - "Nein, tut mir Leid" - "..."


Wollen die mich verarschen? :/

Edit2:
Hab mal den Traffic mit WinDump angeguckt. Da kommt kein einziges Signal rein.

---------- Beitrag hinzugefügt um 18:33 ---------- Vorheriger Beitrag war um 17:23 ----------

Meine Damen und Herren, wir haben eine Lösung.

Das ganze nennt sich Portumleitung und sieht so aus.

Servicename *RemoteDesktopProtocol
Protokoll TCP
Allgemeiner Port-Bereich 53389 - 53389
Port der Basis-Arbeitsstation 3389

Drecksrouter. *g*
 
Zuletzt bearbeitet:
Muss nicht unbedingt der Provider sein der das blockt. Kann theoretisch genausogut der Router nen defekt haben.

Die Frage ist: Wieso sollte man 3389 blocken? Weil die Leute zu dumm sind RDP deaktiviert zu lassen und pöse pöse Hacker da eindringen könnten? Das ist doch unsinnig...


Kleine Anekdote dazu: Vor ca. nem Jahr oder so, hab ich Napoleon:Total War gekauft und wollte das im Netz spielen. Das ging über nen bestimmten Portbereich den man erst freigeben musste.
Per Zufall hab ich dann von nem Bekannten der bei meinem Provider arbeitet erfahren, dass die DSLAM's (Verteilerstationen die jeweils im Quartier stehn) nen verbuggten Alcatel-Chip hatten, der gewisse Ports im oberen Portbereich nicht richtig durchleiten konnte. Austauschen wollten die das natürlich nicht. "Wir supporten keine Games!" - "Ja, aber eure Hardware ist kaputt..." - "Wir supporten keine Games!" - "..."




Edit:
Grad in nem Schweizer Forum gefragt. Andere Nutzer mitm selben Provider haben kein Problem mit dem Port.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh