UltraVNC hinter SBS Server
Hallo
Ich arbeite erst seit kurzem mit Windows SBS 2003 und versuche nun folgendes (leider seit ein paar Tagen ):
Ich habe ein Moden/Router, welches mit dem Internet verbunden ist. Der SBS Server ist mit diesem Modem verbunden. Über die 2. Netzwerkkarte des SBS Servers ist ein Hub installiert, an welchem die verschiedenen Clients angeschlossen sind.
Nun möchte ich übers Internet auf einen Client mittels UltraVNC zugreifen. Ist dieser Client direkt am Router angeschlossen, funktioniert alles wunderbar. Ist jedoch der Server dazwischen, funktioniert ist nicht mehr. Ich glaube ich muss irgend eine Einstellung unter RAS/Routing vornehmen... habe aber leider keine Ahnung wie. Kann mir jemand einen Tipp geben? Client: XP, Server: SBS 2003 Standard.
Beispiel:
Ich habe einen Router (Modem) und dieser ist direkt mit dem "Client"-Computer (192.168.1.101) verbunden. Beim Router (192.168.1.1) habe ich die "Statische NAT-IP-Adresse:" auf diesen Client eingestellt. UltraVNC hat so funktioniert.
Nun schliesse ich den Server dazwischen. Ich erstelle wieder diese Statische NAT-IP Adresse, diesmal aber auf den Server (192.168.1.2). Die zweite Netzwerkkarte im Server hat die IP 192.168.10.100. Aus meiner Sicht weis nun der Router, das Anfragen an die öffentliche IP an den Server weitergeleitet werden müssen. Nun muss doch der Server noch wissen, dass er diese Anfrage an den Client (192.168.10.101) weiterleiten muss. Wo kann ich dies in SBS 2003 einstellen? Desweitern: Was meint ihr zur Sicherheit, falls ich dies so installiere?
Besten Dank für Eure Beiträge im Voraus.
Gruess
Nik
Ich arbeite erst seit kurzem mit Windows SBS 2003 und versuche nun folgendes (leider seit ein paar Tagen ):
Ich habe ein Moden/Router, welches mit dem Internet verbunden ist. Der SBS Server ist mit diesem Modem verbunden. Über die 2. Netzwerkkarte des SBS Servers ist ein Hub installiert, an welchem die verschiedenen Clients angeschlossen sind.
Nun möchte ich übers Internet auf einen Client mittels UltraVNC zugreifen. Ist dieser Client direkt am Router angeschlossen, funktioniert alles wunderbar. Ist jedoch der Server dazwischen, funktioniert ist nicht mehr. Ich glaube ich muss irgend eine Einstellung unter RAS/Routing vornehmen... habe aber leider keine Ahnung wie. Kann mir jemand einen Tipp geben? Client: XP, Server: SBS 2003 Standard.
Beispiel:
Ich habe einen Router (Modem) und dieser ist direkt mit dem "Client"-Computer (192.168.1.101) verbunden. Beim Router (192.168.1.1) habe ich die "Statische NAT-IP-Adresse:" auf diesen Client eingestellt. UltraVNC hat so funktioniert.
Nun schliesse ich den Server dazwischen. Ich erstelle wieder diese Statische NAT-IP Adresse, diesmal aber auf den Server (192.168.1.2). Die zweite Netzwerkkarte im Server hat die IP 192.168.10.100. Aus meiner Sicht weis nun der Router, das Anfragen an die öffentliche IP an den Server weitergeleitet werden müssen. Nun muss doch der Server noch wissen, dass er diese Anfrage an den Client (192.168.10.101) weiterleiten muss. Wo kann ich dies in SBS 2003 einstellen? Desweitern: Was meint ihr zur Sicherheit, falls ich dies so installiere?
Besten Dank für Eure Beiträge im Voraus.
Gruess
Nik
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 65836
Url: https://administrator.de/forum/ultravnc-hinter-sbs-server-65836.html
Ausgedruckt am: 26.04.2025 um 20:04 Uhr
9 Kommentare
Neuester Kommentar
Nein mit RAS/Routing hat das rein gar nichts zu tun ! Dein Szenario ist dieses hier:
Das Problem ist der NAT Prozess im Router bzw. dessen Port Forwarding Einstellung.
Wenn du das Port Forwarding im Router für VNC (Port TCP 5900) einrichtest dann musst du dort als lokale Zieladresse ja eine IP aus deinem Client Segment vorsehen, nämlich die die du remote administrieren willst.
Das Problem ist nun das diese ja in einem ganz anderen IP Netz liegt als der Router bzw. dessen LAN Interface selber.
Die Masse aller Consumer DSL Router kommt damit nicht klar und verweigert meist schon bei der Einrichtung des PFW strikt die Zusammenarbeit und das obwohl dieser Router natürlich eine statische Route zum Client IP Netz via Server in seiner Routing Tabelle eingetragen hat, er das Netz also sicher kennt.
Das ist ein generelles Firmware Problem dieser preiswerten DSL Router Systeme...leider. In Routern etwas höherer Preisklassen existiert dieses unsinnige Problem nicht.
Du hast also nur einen Workaround wenn du keine neue HW kaufen willst: Du machst eine VNC Session auf den Server und startest von diesem Wiederum eine VNC Session auf den Client. Nicht das Gelbe vom Ei... aber funktioniert !
Das Problem ist der NAT Prozess im Router bzw. dessen Port Forwarding Einstellung.
Wenn du das Port Forwarding im Router für VNC (Port TCP 5900) einrichtest dann musst du dort als lokale Zieladresse ja eine IP aus deinem Client Segment vorsehen, nämlich die die du remote administrieren willst.
Das Problem ist nun das diese ja in einem ganz anderen IP Netz liegt als der Router bzw. dessen LAN Interface selber.
Die Masse aller Consumer DSL Router kommt damit nicht klar und verweigert meist schon bei der Einrichtung des PFW strikt die Zusammenarbeit und das obwohl dieser Router natürlich eine statische Route zum Client IP Netz via Server in seiner Routing Tabelle eingetragen hat, er das Netz also sicher kennt.
Das ist ein generelles Firmware Problem dieser preiswerten DSL Router Systeme...leider. In Routern etwas höherer Preisklassen existiert dieses unsinnige Problem nicht.
Du hast also nur einen Workaround wenn du keine neue HW kaufen willst: Du machst eine VNC Session auf den Server und startest von diesem Wiederum eine VNC Session auf den Client. Nicht das Gelbe vom Ei... aber funktioniert !

Was mach ich falsch?
Sorry, aber eigentlich alles ;)
1. NAT auf dem Router einschalten
2. Route auf dem Router einrichten: alle Pakete an 192.168.10.101 sind an 192.168.1.2 zu senden (ggf. Netzwerk-Route, z.B. 192.168.10.0/255.255.255.0 -> 192.168.1.2)
3. Port für VNC im NAT auf den Client weiterleiten (192.168.10.101/5900?)
4. Firewall oder gar NAT auf dem SBS aktiviert? -> Hol dir jemanden, der sich damit auskennt.
Nicht falsch verstehen, aber da besteht doch etwas mehr Lernbedarf, als ich hier schreiben mag.
Grüße, Steffen
@Nikkin
Du hast dir das Turorial von oben ja sicher durchgelesen, aber scheinbar nicht richtig verstanden...
Dann wiesst du also das dein Server ja schon Packete per se weiterreicht nämlich vom Router eben in das Client Segment. Er routet also alle deine Daten die vom Router oder Clientsegment kommen, ist also selber ein Router.
Das Problem ist die Port Weiterleitung im Internet Router. Die müsste um einen PC im Client Segment zu erreichen ja eine IP Zieladresse aus dem Clientsegment bekommen also ein IP Netz was am Router ja selber gar nicht angeschlossen ist und was der Router so gar nicht kennt. Deine Netze zwischen Router Verbindung und Clientsegment sind ja vollkommen unterschiedlich !
Das ist das Problem das die Masse der Consumer Router so eine lokale IP Weiterleitungs Adresse die, wie gesagt, NICHT im eigenen IP Netz liegt was der Router am eigenen LAN Port hat (denn es ist ja dein Clientsegment und damit hinter dem Server !) klarkommen.
Entweder nehmen sie die Adress Konfig gar nicht erst an oder sie führen die Weiterleitung nicht aus auch wenn der Router eine statische Route via Server (als Router) hat. Das ist also dein Problem was du auch niemals mit einer Konfig regeln kannst, denn das ist ein Fehler in der Firmware dieser Router !
Setzt du die IP Weiterleitung nun auf deine Server IP Adresse schickt der Router eingehende Packete an seinem DSL Port die die Portnummer TCP 5900 haben nun an diese Serveradresse. Die Portnummer bleibt aber erhalten und wenn der Server nun keinen Prozess/Applikation hat der auf Port TCP 5900 lauscht (wie VNC) schmeisst er das Packet sofort weg.
Fazit: Es bleiben nur 2 Lösungen:
a.) der doppelte VNC Hop über den Server mit VNC drauf und von dort wiedermit VNC zum Client wie oben beschrieben
b.) Den Server selber im NAT bzw. ICS Modus bei Windows laufen zu lassen und dann ein Port Forwarding dort nochmal auf dem Server zu konfigurieren was aber Probleme bereiten kann
Dafür gilt aber dann wieder Punkt 4. von smerlin oder.....die MS Knowledgebase !
Du hast dir das Turorial von oben ja sicher durchgelesen, aber scheinbar nicht richtig verstanden...
Dann wiesst du also das dein Server ja schon Packete per se weiterreicht nämlich vom Router eben in das Client Segment. Er routet also alle deine Daten die vom Router oder Clientsegment kommen, ist also selber ein Router.
Das Problem ist die Port Weiterleitung im Internet Router. Die müsste um einen PC im Client Segment zu erreichen ja eine IP Zieladresse aus dem Clientsegment bekommen also ein IP Netz was am Router ja selber gar nicht angeschlossen ist und was der Router so gar nicht kennt. Deine Netze zwischen Router Verbindung und Clientsegment sind ja vollkommen unterschiedlich !
Das ist das Problem das die Masse der Consumer Router so eine lokale IP Weiterleitungs Adresse die, wie gesagt, NICHT im eigenen IP Netz liegt was der Router am eigenen LAN Port hat (denn es ist ja dein Clientsegment und damit hinter dem Server !) klarkommen.
Entweder nehmen sie die Adress Konfig gar nicht erst an oder sie führen die Weiterleitung nicht aus auch wenn der Router eine statische Route via Server (als Router) hat. Das ist also dein Problem was du auch niemals mit einer Konfig regeln kannst, denn das ist ein Fehler in der Firmware dieser Router !
Setzt du die IP Weiterleitung nun auf deine Server IP Adresse schickt der Router eingehende Packete an seinem DSL Port die die Portnummer TCP 5900 haben nun an diese Serveradresse. Die Portnummer bleibt aber erhalten und wenn der Server nun keinen Prozess/Applikation hat der auf Port TCP 5900 lauscht (wie VNC) schmeisst er das Packet sofort weg.
Fazit: Es bleiben nur 2 Lösungen:
a.) der doppelte VNC Hop über den Server mit VNC drauf und von dort wiedermit VNC zum Client wie oben beschrieben
b.) Den Server selber im NAT bzw. ICS Modus bei Windows laufen zu lassen und dann ein Port Forwarding dort nochmal auf dem Server zu konfigurieren was aber Probleme bereiten kann
Dafür gilt aber dann wieder Punkt 4. von smerlin oder.....die MS Knowledgebase !

@steffen
Also (1) wäre damit erledigt.
Meinst Du bei Nr. (2) mit Router den Server
(als Router)? Wo finde ich dies im SBS 2003?
Zu (3): Wo leite ich die PortNr im SBS 2003
weiter?
Also (1) wäre damit erledigt.
Meinst Du bei Nr. (2) mit Router den Server
(als Router)? Wo finde ich dies im SBS 2003?
Zu (3): Wo leite ich die PortNr im SBS 2003
weiter?
Im Moment weis dein Router, das das Netz 192.168.1.0/24 (also 0-255) intern ist. Der Router weis nicht, das auch das Netz 192.168.10.0/24 intern ist. Der Router würde also Paket mit der IP 192.168.10.101 in Internet senden (Default Route).
Deshalb muß auf dem Router eine weiterer Eintrag im Routing Table gemacht werden (Netzwerk Route): Alle Pakete an das Netz 192.168.10.0/24 sind an 192.168.1.2 weiterzuleiten. Oder (Host Route): Alle Pakete an 192.168.10.101/32 sind an 192.168.1.2 weiterzuleiten.
Auf dem SBS ist eigentlich nichts weiter einzustellen, denn der kennt ja die beiden Netze.
Zum Schluss noch eine Anmerkung:
Du machst dann aber KEIN klassisches Routing Szenario mit deinem Server wie im o.a. Tutorial beschrieben ist, sondern du NATest 2mal nämlich einmal mit dem Server zum Routersegment und dann einmal mit dem Router ins Internet. IP technisch eher suboptimal da fehlerträchtig und nicht gerade performant aber was solls, wenn es denn jetzt alles klappt ist ja alles gut !!! Never touch a running system...
Bitte dann
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!!
Du machst dann aber KEIN klassisches Routing Szenario mit deinem Server wie im o.a. Tutorial beschrieben ist, sondern du NATest 2mal nämlich einmal mit dem Server zum Routersegment und dann einmal mit dem Router ins Internet. IP technisch eher suboptimal da fehlerträchtig und nicht gerade performant aber was solls, wenn es denn jetzt alles klappt ist ja alles gut !!! Never touch a running system...
Bitte dann
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!!