Mehrere RDP-Verbindungen auf verschiedene Rechner über AVM Fritzbox 7490

[PHuV]

Ich habe doch bereits alle Ursachen und Vorschläge durch, wie oft den noch? Und Wireshark meldet nichts im Rechner selbst, da doch die Verbindung per RDP gar nicht zustande kommt.

Wobei mir gerade einfällt, daß ich so eine Konfiguration damals mit Windows 7 hatte. Mit Windows hat habe ich das in dieser Form noch gar nicht probiert, und aktuell stelle ich fest, daß die Portänderung von Anwendung auf 3388 mittels RDP Wrapper überhaupt keinen Zugang mehr ermöglicht.

Windows 8.1.1 läßt anscheinend nur 3389 zu, oder die interne Firewall von Anwendung sperrt gerade, und wurde nicht entsprechend automatisch angepaßt.

 

[Raijin]

Ich glaube wir reden gerade aneinander vorbei. Auch wenn keine Verbindung zustande kommt, heißt das noch lange nicht, dass auch keine Kommunikation abläuft. Du hast bisher in keinster Weise eindeutig gesagt, dass du bereits mit WireShark auf eingehende Pakete geprüft hast "geht" und "geht nicht" sind keine Antworten. Bei WireShark geht es wie gesagt nicht ums "gehen", sondern darum ob die Netzwerkkarte überhaupt irgendwelche Daten auf dem Port empfängt.

Auch die Prüfung der Firewall kann ich aus deinen Antworten nicht so recht herauslesen. Du schreibst, dass RDP auf zB 3388 innerhalb des LANs funktioniert, von extern aber nicht. Und genau da haben wir eben eine weitere potentielle Fehlerquelle. Die (Windows)Firewall kann 3388 aus dem eigenen Subnetz zulassen, aber wenn du von extern verbindest, dann steht in der RDP-Anfrage eine WAN-IP und das kann die Firewall aktiv unterbinden! Frei nach dem Motto "Fremde IPs kommen bei mir nicht rein".

 

[PHuV]

Update: So, nachdem die Firewall auf dem Anwendungsrechner geändert wurde:

• Systemsteuerung\Alle Systemsteuerungselemente\Windows-Firewall - erweiterte Einstellungen - Eingehende Regeln - Remotedesktop (doppelklick oder rechte Maustaste - Eigenschaften)
• Reiter Protokolle und Ports
• Änderung Lokale Ports und Remoteport auf "Alle"

Komme ich intern vom Server mit dem neuen Port 3390 über RDP zum Anwendungsrechner ran, aber über extern über die Fritzbox geht es nach wie vor nicht.
Anhang anzeigen 490386
Es muß also an der Fritzbox 7490 liegen.

Auch die Prüfung der Firewall kann ich aus deinen Antworten nicht so recht herauslesen. Du schreibst, dass RDP auf zB 3388 innerhalb des LANs funktioniert, von extern aber nicht. Und genau da haben wir eben eine weitere potentielle Fehlerquelle. Die (Windows)Firewall kann 3388 aus dem eigenen Subnetz zulassen, aber wenn du von extern verbindest, dann steht in der RDP-Anfrage eine WAN-IP und das kann die Firewall aktiv unterbinden! Frei nach dem Motto "Fremde IPs kommen bei mir nicht rein".

Siehe oben. Was hat die Firewall damit zu tun, wenn ich per Port-Forwarding eine Zuweisung mache?

Bisher habe ich alle Anwendungen immer so konfiguriert, und mußte bisher die Firewall des Routers dafür nicht exta anpassen.

Update: Falls Du die Firewall des Anwendungsrechner meinst, die ist bei Remote-IP mit beliebigen Adressen auf Default belassen worden, das sollte eigentlich alle externen Adressen reinlassen.

 

[Raijin]

Ich geb's auf... Du schreibst ständig nur "geht nicht", aber eben dieses "geht nicht" hat mehrere Schichten, eine davon ist die verdammte Firewall! Wenn die Portweiterleitung greift und die Daten beim Server ankommen, die Firewall aber die Verbindung blockt, dann funktioniert RDP genausowenig wie wenn die Portweiterleitung nicht klappt und beim Server überhaupt nichts ankommt! Zwei Ursachen, dasselbe Symptom => RDP geht nicht...

Stell dir vor, wir sitzen nicht neben dir und wir wissen nicht wie du bisher immer "alle Anwendungen" konfiguriert hast. Wir können hier nur ins Blaue schießen und wenn dann von dir "geht nicht" kommt, ist das wenig hilfreich.

Whatever..

 

[PHuV]

Ich geb's auf...

Dann solltest Du niemals im Support arbeiten. Da braucht man eine Menge Geduld, und vor allen Dingen, man gibt hier nicht auf! Und ich habe doch ein Bild gepostet, wie die Portweiterleitung aussieht.

Nochmals, von welcher Firewall redest Du den? Die von Windows auf dem Anwendungsrechner, oder der Firewall vom Router?

Die Firewall auf dem Anwendungsrechner spielt erst mal keine Rolle da:

• Ich die Firewall schon für die Test komplett ausgeschaltet hatte, und trotzdem die Verbindung extern nicht funktioniert
• Die Firewall aktuell nun korrekt konfiguriert wurde
• Die RDP-Verbindung intern von Server zu Anwendung mit dem neuen Port 3390 einwandfrei funktioniert

Wo habe ich jetzt den Denkfehler?

Du darfst gerne per Teamviewer mal raufschauen, wenn Du willst.

Update: Das mit Wireshark ist übrigens ein Trugschluß von Dir. Wenn man mit Wireshark vernünftig analysieren will, mußt Du dafür sorgen, daß es eine direkte Verbindung von Rechner zum Router gibt. Sobald - wie in meinem Fall - ein Switch dazwischen hängt, hast Du mit Wireshark keine Chance.

 

[Raijin]

Und ich habe doch ein Bild gepostet, wie die Portweiterleitung aussieht.

Das ist die GUI, das heißt noch nicht, dass die Weiterleitung auch tatsächlich aktiv ist. Ich hab im Büro einen Netgear-Router, bei dem ich denselben Port an 12 verschiedene IPs weiterleiten kann (vermutlich noch mehr). Abgesehen von Multi-/Broadcast gibt es aber nur Punkt-zu-Punkt Verbindungen. Während andere Router doppelte Weiterleitungen mit einer Fehlermeldung quittieren, hat der Netgear einfach nur die erste benutzt und die anderen ignoriert. Du siehst also, ein Screenshot sagt nur aus, dass du im Rahmen der GUI alles richtig eingetragen hast.

Nochmals, von welcher Firewall redest Du den? Die von Windows auf dem Anwendungsrechner, oder der Firewall vom Router?

Ich rede die ganze Zeit von Windows-Firewall, Firewall auf dem PC und dergleichen..

Die Firewall auf dem Anwendungsrechner spielt erst mal keine Rolle da:
Ich die Firewall schon für die Test komplett ausgeschaltet hatte, und trotzdem die Verbindung extern nicht funktioniert

Das kann man schlecht riechen oder durch Handauflegen auf den Monitor wissen. Nur wenn du es klar und deutlich schreibst. Bis dahin muss man davon ausgehen, dass die PC-Windows-Firewall nicht angefasst wurde.

[*]Die RDP-Verbindung intern von Server zu Anwendung mit dem neuen Port 3390 einwandfrei funktioniert

Nochmal: Die PC-Firewall kann RDP von einer WAN-IP, also extern, aktiv blocken. Dass es innerhalb des Netzwerks funktioniert wissen wir nun, das muss aber PC-Firewall-technisch nicht zwangsläufig auch für extern gelten! Das ist so als wenn dein Briefkasten automatisch alle Briefe schreddert, die aus dem Ausland kommen (Quelle=WAN-IP), während er Briefe aus D-Land (LAN) in Ruhe lässt. Wie dem auch sei, nu hast du es ja geprüft.


Dein Denkfehler liegt einfach da, dass man bei Netzwerkfehlern den Datenfluss Station für Station nachvollziehen und überprüfen muss. Die Kommunikation läuft grob dargestellt so ab:

1) Daten kommen von außen an den Router (WAN-IP oder DDNS)
2) Router leitet die Daten an den Server weiter (Portforwarding)
3) Die Firewall des Servers entscheidet ob diese Verbindung erlaubt ist (WAN=ok?)
4) Die Anwendung nimmt die Daten entgegen und schickt eine Bestätigung an die Quell-IP (=WAN-IP des Clients)
5) Quell-IP ist außerhalb des lokalen Subnetzes => zum Default Gateway (Router) schicken
6) Router "nattet" die Bestätigung und schickt sie zum Ziel
7) Verbindungsaufbau komplett


In JEDEM dieser Schritte kann ein Fehler auftreten, der Effekt ist aber immer derselbe: Der RDP-Client meldet "keine Verbindung". Deswegen muss man der Reihe nach prüfen wie weit die Daten überhaupt kommen. In der Regel reicht es bis 4, weil der Rückweg mehr oder weniger eine normale ausgehende Internetverbindung ist und selten geblockt wird.

 

[Joe Dalton]

MoinMoin,

Erster Satz ja, ich komme von außen mit einem anderen Port rein, und der sollte doch per Fritzbox einfach intern anders geroutet werden. So verstehe ich Port-Weiterleitung. Wie oben gesagt, mit Draytek-Routern geht das ja ohne weiteres.

So, nachdem Du uns endlich mal verraten hast, dass am *gleichen* Anschluss mit *anderer* Hardware alles funktioniert hat, kann die Fehlerquelle etwas weiter eingegrenzt werden...

Und nein, ich brauche keinen extra Port, weil Weiterleitung heißt für mich, eine Anwendung meldet sich von außen mit einem anderen Port am Router an, und der sollte intern doch korrekt auf den Stardardport routen.

Das ist kein Routing, sondern nennt sich NAT bzw. PAT.

Ergänzung (29. April 2015)

Nochmals, ich bitte darum, die Dinge vorher genauer zu lesen.

Du solltest Dir das selbst zu Herzen nehmen!
Nimm Telnet und verbinde Dich von außen(!) auf Deine DynDNS-Adresse und die unterschiedlichen Ports. Parallel sollte auf Deinen Zielrechnern im internen(!) Netz Wiresharks laufen und aufzeichen, was sie vom Router an Paketen kriegen (Ziel: 3389).

Von diesen drei Tests ausgehend kannst Du dann sagen, wo der Fehler im Router steckt (entweder schon WAN-seitig oder beim NAT/PAT auf der LAN-Seite).

Wenn ich den Standardport 3389 verwende, egal welcher Rechner ich dann per Portweiterleitung konfiguiere, dann klappt die Weiterleitung immer. Das habe ich bereits alles überprüft und getestet.

Prima, gibt einen Keks.
-> alle Zielrechner sind per RDP-Standardport erreichbar.

Ändere ich einen Rechner per Registry, wie hier vorgeschlagen, z.B. auf 3388, klappt die Verbindung zwar intern, aber nicht von außen per Port-Weiterleitung von der Fritzbox 7490

Prima, zweiter Keks.
-> die Personal Firewall scheint also auch kein Problem zu haben

Hast Du auch mal in der Fritz!Box geschaut, ob es dort Regeln außerhalb des NAT gibt, die evtl. den Traffic zwischen WAN und LAN blocken? Alternativ die beiden Ports nach außen mal freigeben und mit Telnet/Wireshark prüfen, wie weit Du damit kommst.

Wie jemand schon geschrieben hat: Die angezeigten Werte/Einstellungen in der GUI müssen nicht mit dem übereinstimmen was in der "running config" gesetzt ist. Das sollte so sein, aber je nach Bug muss es nicht sein.


Ich gebe Dir recht: Manche haben hier Deine Ausführungen nicht ganz gelesen oder verstanden. Aber gehe einfach mal davon, dass hier nicht nur Trottel unterwegs sind. Hättest Du die Weisheit mit Löffeln gefres..., dann müsstest Du hier nicht Fragen, sondern würdest das Troubleshooting selbst durchführen.


Cu,
Chris

 

[PHuV]

Du solltest Dir das selbst zu Herzen nehmen!
Nimm Telnet und verbinde Dich von außen(!) auf Deine DynDNS-Adresse und die unterschiedlichen Ports. Parallel sollte auf Deinen Zielrechnern im internen(!) Netz Wiresharks laufen und aufzeichen, was sie vom Router an Paketen kriegen (Ziel: 3389).

Das war der entscheidende Hinweis, und nun hab ich auch eine Idee. Bei uns in der Firma wird Telnet nach draußen blockiert. Kann ich also von hier aus nicht testen. Aber genau so werden dann wohl in der Firmenfirewall alle nicht bekannten Ports nach von innen nach außen blockiert, eben auch eine 3388 oder 3390, und dann kann das ja gar nicht funktionieren.

Danke für Eure Hilfe.

 

[worldoak]

Im ersten Bild ist es komisch aufgeführt: Da hast du 2x Server der auf verschiedene Ports hört. Gibt es den Server 2x im Netzwerk?

In der Regel, ist es besser wenn man den Port direkt weiterleitet und nicht einen Port rauf oder runter.

Wieso änderst du nicht den Eingangsport der jeweiligen maschinen um und musst diesen nur weiterleiten? Anweisungen dazu hast du ja bereits erhalten.

 

[PHuV]

Das ist die GUI, das heißt noch nicht, dass die Weiterleitung auch tatsächlich aktiv ist

Richtig. Aber dann dürfte das mit dem Standardport so auch nicht funktionieren, tut es aber. An sich kann man nach diversen Tests dann schon darauf verlassen, daß das, was da steht, auch aktiv ist.

Ergänzung (29. April 2015)

Im ersten Bild ist es komisch aufgeführt: Da hast du 2x Server der auf verschiedene Ports hört. Gibt es den Server 2x im Netzwerk?

Das war nur ein Testeintrag, ob am Server ein anderen Port ebenso scheitert.

In der Regel, ist es besser wenn man den Port direkt weiterleitet und nicht einen Port rauf oder runter.

Wieso änderst du nicht den Eingangsport der jeweiligen maschinen um und musst diesen nur weiterleiten? Anweisungen dazu hast du ja bereits erhalten.

Hatte ich ja bereits getan, was ich im Eingangspost auch geschrieben hatte.

Ich mußte mich jetzt damit behelfen, daß ich die externe Adresse über den Server eingebe, und nicht über das Firmennetz, und damit klappt die Verbindung, sei es als Port-Weiterleitung oder als anderer Port auf dem Anwendungrechner.

Nochmals danke an alle.

Übrigens kann ich den RDPWrap wirklich empfehlen. Mit ihm kann man viel einfacher den RDP-Port ändern, und vor allen Dingen kann man unter Windows 8.1 mit einem lokalen und remote Benutzer arbeiten.