Remotedesktop auf Server W2K3 hinter Fritzbox Fon WLAN

[Stefan-369]

Hallo Zusammen!

Bin bei meiner Suche im Netzt auf Euer Forum gestoßen. Ich hoffe, ich kann hier eine Antwort auf mein Problem finden.

Folgender Aufbau:
Fritzbox Fon WLAN
- ist DSL-Modem und IP-Router
- WLAN deaktiviert
- DHCP deaktiviert
- IP der Box geändert auf 192.168.179.1
- dyn DNS eingerichtet

hinter der Box hängt ein 24-port Switch und daran eine Server W2003 SP1 sowie diverse Clients (XP Pro SP2, z.T. auch Win 98 SE)

der Server ist ein Domänencontroller und übernimmt auch das
DHCP und das DNS.

Standardgateway ist die Fritzbox mit der geänderteen IP.

LAN läuft, Internet läuft.

Nun möchte ich von extern via Remotedesktopverbindung auf den W2K3 Server zugreifen, um Terminaldienste zu starten bzw. für die Fernwartung. Ich kriege aber keine Verbindung zustande. Es kommt erst gar nicht zur Anmeldung, die Verbindung von "draußen" kommt nicht zu stande.

Ich habe die Ports 3368 für MS Remote freigegeben und an die interne Server-IP geroutet.

Nun bin ich mit meinem Latei am Ende.

Ich danke Euch für Eure Hilfe.

Stefan

 

[gerdshi]

Nun möchte ich von extern via Remotedesktopverbindung auf den W2K3 Server zugreifen, um Terminaldienste zu starten bzw. für die Fernwartung. Ich kriege aber keine Verbindung zustande. Es kommt erst gar nicht zur Anmeldung, die Verbindung von "draußen" kommt nicht zu stande.

Ich habe die Ports 3368 für MS Remote freigegeben und an die interne Server-IP geroutet.

Tja, leider kann es so mit diesem Port nicht funktionieren.
Der richtige Port ist 3389.

Ich bin mir aber nicht sicher ob es eine gute Idee ist, sich auf die Authentifizierung und Verschluesselung von RDP zu verlassen.
Ich habe es bei Kunden ueber SSH bzw. VPN je nach Umgebung eingerichtet.

Gruss

 

[Stefan-369]

ups, Zahlendreher. Ich habe den Port 3389 freigegeben (hatte mich vertippt).
Geht trotzdem nicht. Thema Sicherheit: Ich bin da mit den anderen Programmen nicht vertraut. Vielleicht kannst Du mir - unabhängig von der Lösung meines Problems - dazu mal nen link schicken.

Rein zum Testen kann ich mal den Sichereitsaspekt vernachlässigen.
Kann es sein, dass die IP-Änderung das Problem ist??

 

[frank_m24]

Hallo,

möglicherweise ist das Subnetz 192.168.179.0/24 das Problem. Dieses Subnetz gehört zu den intern in der Box verwendeten:

# ifconfig -a
dsl       Link encap:Point-Point Protocol
          inet addr:192.168.179.1  P-t-P:192.168.179.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:828783 errors:0 dropped:0 overruns:0 frame:0
          TX packets:641533 errors:0 dropped:90 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:819341780 (781.3 MiB)  TX bytes:138962891 (132.5 MiB)

eth0      Link encap:Ethernet  HWaddr 00:04:0E:96:B6:8B
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:680372 errors:0 dropped:0 overruns:0 frame:0
          TX packets:840431 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:147279030 (140.4 MiB)  TX bytes:840147562 (801.2 MiB)

eth1      Link encap:Ethernet  HWaddr 00:04:0E:96:B6:8C
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Base address:0x2800

lan       Link encap:Ethernet  HWaddr 00:04:0E:96:B6:8B
          inet addr:192.168.178.1  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:655166 errors:0 dropped:0 overruns:0 frame:0
          TX packets:840421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:134144700 (127.9 MiB)  TX bytes:840145896 (801.2 MiB)

lan:0     Link encap:Ethernet  HWaddr 00:04:0E:96:B6:8B
          inet addr:192.168.178.254  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

...

Ich bin mir nicht sicher, aber wenn man ein 192.168.179er Subnetz einrichtet, wird wohl das Interface "lan" dahin umziehen: Dann hat man möglicherweise das Problem, dass Portweiterleitungen nicht dort ankommen, sondern auf "dsl" weitergeleitet werden.

Viele Grüße

Frank

 

[gerdshi]

Hi!

Zum 179-Netz - Aua!
Wenn das stimmt, das so eine Ueberlappung statt findet und die Firmware das nicht erkennt und selbst korrigiert.... :-Ö

Zu Sicherheit.
Mit einem Link kann ich leider nicht helfen, aber hier im Forum wird beschrieben wie man in der FBF ein SSH-Server einbauen kann und dort wurde mehrmals beschrieben wie man Ports umleiten kann.
Und die Authentifizierung kann per Password oder per Schluesselpaar (unsymetrische Verschluesslung) erfolgen.
Zu VPN wird es noch hariger. Die Box nicht die erste Wahl fuer VPN-Passtrough - Offiziell ist sie zwar fuer IP-SEC-Passthrough freigegeben, dennoch beklagen sich viele Leute das es nicht funktioniert wenn - wie war das frank_m24 genau, du hast glaube ich mehr Erfahrung damit - keine NAT-T Unterstuetzung im IP-SEC-Server da ist.
Allerdings brauchst dafuer eigentlich ein IP-SEC-Server und der ist bei Win2k3 nicht dabei.
VPN-PPTP (ist bei W2k3 dabei) funktioniert bei vielen Leuten eingehend auch nicht. Andererseits behauptet AVM, das sie fuer PPTP auch nicht offziell freigegeben ist. Ich kann zwar den Fehler nicht nachvolziehen, aber...
Wollte nur schildern, das fuer VPN-Passthrough bessere Router gibt. ;-)

Aber eigentlich sollte SSH reichen. Abgesehen von der FBF integration, gibt es openSSH fuer Windows der sehr stabil und zuverlaessig laeuft.
Ah, hier doch ein link ;-) http://freessh.org/windows.html

Am sonsten fuer Testzwecke - klar, kannst du erst mal auf eine Verschluesselung verzichten. Unterschaetze aber nicht die "dunkle Seite der Macht". ;-) Du wirst ueberascht sein wie schnell "sie" arbeitet und dich "finden" wird.

Gruss

 

[frank_m24]

Hallo,

Zum 179-Netz - Aua!
Wenn das stimmt, das so eine Ueberlappung statt findet und die Firmware das nicht erkennt und selbst korrigiert.... :-Ö

Richtet man auf einem Standard Linux oder Windows PC zwei Netzwerkkarten im gleichen Subnetz ein, dann versuchen die Beiden ihr Glück immer nur auf einer von beiden - unabhängig davon, ob ein Netz dahinter hängt oder nicht. Von daher ist es nicht abwegig.

Richtig ist allerdings, dass die Box üblicherweise warnt, wenn man Adressen zu vergeben versucht, die intern benutzt werden (z.B. beim 180er Subnetz, die für den DNS Proxy benutzt werden). Und wenn man "Alle Computer befinden sich im selben IP-Netzwerk" deaktiviert, dann ist das 179er Netz für die USB Schnittstelle. Vielleicht spukt das auch noch irgendwo rum?

Viele Grüße

Frank

 

[Stefan-369]

So, nun hab ich den Fehler gefunden:

War im Wesentlichen meine Unachtsamkeit.
Dadurch, dass ich den IP-Bereich im xxx.xxx.179.x-er Bereich umgezogen habe, habe ich die werkseitigen Vorgaben nicht verändert. Will sagen, die Voreinstellungen auf der Seite Portfreigaben. Dort standen noch schön die 178er Defaults. Und da sie alle gleich aussahen, hab' ich mir da auch nichts weiter bei gedacht und nicht an meine Umzugsaktion gedacht. Auf deutsch: den Wald vor Bäumen nicht gesehen. So ist das, wenn man 4 Tage lang nur draufschaut und sich festbeisst... ;-).

Danke an alle.
Was bleibt, ist das Thema Sicherheit. Da es sich um eine Fillialanbindung von außen handelt, muss ich da mal sehen, was eine gute Lösung ist. Ich bin mal ganz naiv davon ausgegangen, dass es bei der Terminalserver-Lösung via RDP 5.2 schon sicher zur Sache geht. Werde mich da mal weiter aufschlauen.

Nochmals danke für Eure Hilfe und einen schönen Restabend!

 

[gerdshi]

Hallo!

Richtet man auf einem Standard Linux oder Windows PC zwei Netzwerkkarten im gleichen Subnetz ein, dann versuchen die Beiden ihr Glück immer nur auf einer von beiden - unabhängig davon, ob ein Netz dahinter hängt oder nicht. Von daher ist es nicht abwegig.

Ja gut. Den technische Hintergrund aller Ehre.
Aber es ist nicht gerade Kundenfreundlich ein Endprodukt zu verkaufen und dann zu sagen - ach ihr wusstet nicht, das ihr detailierte Kentnisse vom Aufbau der FBF bzw. PCs mit mehr als eine Netzwerkkarte braucht, um es einzurichten?! Na dann habt ihr Pech gehabt.
Daher hoffe ich/gehe davon aus, das AVM diesen Fehler nicht gemacht hat. ;-)
IMHO!

Als Informatiker ist fuer mich die Erklaerung plausibel, aber irgendwann sehen wir den Wald vor lauter Baeume nicht mehr und machen dann das Leben der Benutzer mit solche Kleinigkeiten nicht gerade einfacher. ;-)

Gruss