8
Port Forwarding in anderes Subnetz
Hallo,
ich habe 2 Router, die beide mit der LAN seite an meinem 1. netz hängen (10.50.x.x).
Der 1. Router (Linksys WRT320n dd-wrt) ist mit dem internet verbunden und logischerweise als haupt gateway an allen pcs konfiguriert. Ausserden hat eine static route für das 2. netz.
Der 2. Router (Netgear WGR614v7, ein richtig mises teil) ist über den WAN port an ein 2. netz (192.168.128.x) angebunden in dem er die statische ip 192.168.128.1 besitzt.
Das hat den zweck das PCs im 2. netz von aussen erreichbar sein sollen, aber selber nicht ins inet können und nicht aufs 1. netz zugreifen können.
Auf einem PC(192.168.128.2) ist nun UltraVNC installiert, auf das ich vom 1. netz auch ohne probleme zugreifen kann.
Nun will ich aber auch aus dem Internet per vnc sehen was sache ist, also habe ich einfach im 1. router den port 5900 für vnc an die adresse 192.168.128.2 weitergeleitet, ohne erfolg.
Port forwarding im allgemeinen funktioniert ins 1. netz (z.B. 3306 an 10.50.0.1 für MySQL), nicht aber ins 2. netz.
Nun ist die frage wie ich den 1. router dazu bringe die pakete aus dem internet ins 2. netz weiterzuleiten.
MfG
Joel
ich habe 2 Router, die beide mit der LAN seite an meinem 1. netz hängen (10.50.x.x).
Der 1. Router (Linksys WRT320n dd-wrt) ist mit dem internet verbunden und logischerweise als haupt gateway an allen pcs konfiguriert. Ausserden hat eine static route für das 2. netz.
Der 2. Router (Netgear WGR614v7, ein richtig mises teil) ist über den WAN port an ein 2. netz (192.168.128.x) angebunden in dem er die statische ip 192.168.128.1 besitzt.
Das hat den zweck das PCs im 2. netz von aussen erreichbar sein sollen, aber selber nicht ins inet können und nicht aufs 1. netz zugreifen können.
Auf einem PC(192.168.128.2) ist nun UltraVNC installiert, auf das ich vom 1. netz auch ohne probleme zugreifen kann.
Nun will ich aber auch aus dem Internet per vnc sehen was sache ist, also habe ich einfach im 1. router den port 5900 für vnc an die adresse 192.168.128.2 weitergeleitet, ohne erfolg.
Port forwarding im allgemeinen funktioniert ins 1. netz (z.B. 3306 an 10.50.0.1 für MySQL), nicht aber ins 2. netz.
Nun ist die frage wie ich den 1. router dazu bringe die pakete aus dem internet ins 2. netz weiterzuleiten.
MfG
Joel
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 162537
Url: https://administrator.de/contentid/162537
Printed on: April 20, 2024 at 03:04 o'clock
8 Comments
Latest comment
Hallo,
du muss entweder im 1. Router die Route zu dem 192.168.128.xer-Netz eintragen (Gateway 2. Router), dann können aber geg. alle in das Netz. Oder du machst das Port-Forwarding auf die IP des 2. Routers im 1. Netz und richtest auf dem 2. Router ein weiteres Portforwarding ein.
Gruß
Filipp
du muss entweder im 1. Router die Route zu dem 192.168.128.xer-Netz eintragen (Gateway 2. Router), dann können aber geg. alle in das Netz. Oder du machst das Port-Forwarding auf die IP des 2. Routers im 1. Netz und richtest auf dem 2. Router ein weiteres Portforwarding ein.
Gruß
Filipp
Die Route hat er ja eingetragen wie man oben lesen kann.... Und alle aus dem Netz 10.50.0.0 /16 können ja auch ins 2te Netz was ja gewollt ist.
Der Sinn ist ja das nur Nutzer aus dem 2ten Netz nicht ins 10.50.0.0 /16er Netz kommen, was die NAT Firewall im NG zum 192.168.2.0er Netz ja auch sicher verhindert.
In so fern ist also alles korrekt !
Die Kardinalsfrage die sich stellt ist ob der Port Forwarding Prozess im DD-WRT eingehende Pakete an nicht lokale IP Adressen forwarden kann ?
Die meisten billigen Consumer Router können das auch trotz einer evtl. vorhandenen statischen Route im PFW Router nicht. Bei DD-WRT würde man aufgrund der gehobenen guten Features von DD-WRT erstmal etwas anderes vermuten aber sicher ist das keineswegs ! Bzw. das DD-WRT Wiki schweigt dazu...
Fazit: Nimm einen Wireshark Sniffer und sieh dir das an, ob die aus dem Internet eingehenden TCP 5900er Pakete vom DD-WRT mit einer 192.168.2.2er IP Zieladresse sauber im 10.50.0.0er LAN geforwardet werden.
Nur dann kannst du ganz sicher sein das nicht hier schon dein Problem liegt.
Wenn du einen ungemangeten Switch hast ist das ggf. schwer zu sehen mit dem Sniffer, da du dazu einen Monitoring Port benötigst. Ggf. hast du noch irgendwo einen alten Hub den du zwischen Router und Wireshark Sniffer schleifen kannst ?
Andernfalls kannst du dir mit einem kleinen Trick helfen:
Ersetze temporär die NG Gurke mit dem Sniffer PC der genau diese NG Router IP hat und pinge den DD-WRT einmal an damit dessen MAC am DD-WRT bekannt ist.
Dann startest du einen Wireshark hier oder alternativ den MS NetMonitor und checkst ob die geforwardeten VNC Frames korrekt ankommen bzw. wie oben beschrieben geforwardet werden.
Zum Querchecken, um wirklich ganz sicher zu gehen, schliesst du das Sniffer Konstrukt nochmal direkt am DD-WRT LAN Port an um zu sehen ob, und mit welcher IP denn überhaupt das Port Forwarding gemacht wird.
Kommen sie nicht an, scheiterst du genau an diesem Problem und dann gibt es keine andere Lösung als einen Router der damit umgehen kann. Davon gibt es aber nur sehr wenige !
Ein simpler Workaround ist dann immer ganz einfach:
Nachteil: Der 10.50.0.0er VNC PC muss immer an sein auch wenn keiner da ist...
Der Sinn ist ja das nur Nutzer aus dem 2ten Netz nicht ins 10.50.0.0 /16er Netz kommen, was die NAT Firewall im NG zum 192.168.2.0er Netz ja auch sicher verhindert.
In so fern ist also alles korrekt !
Die Kardinalsfrage die sich stellt ist ob der Port Forwarding Prozess im DD-WRT eingehende Pakete an nicht lokale IP Adressen forwarden kann ?
Die meisten billigen Consumer Router können das auch trotz einer evtl. vorhandenen statischen Route im PFW Router nicht. Bei DD-WRT würde man aufgrund der gehobenen guten Features von DD-WRT erstmal etwas anderes vermuten aber sicher ist das keineswegs ! Bzw. das DD-WRT Wiki schweigt dazu...
Fazit: Nimm einen Wireshark Sniffer und sieh dir das an, ob die aus dem Internet eingehenden TCP 5900er Pakete vom DD-WRT mit einer 192.168.2.2er IP Zieladresse sauber im 10.50.0.0er LAN geforwardet werden.
Nur dann kannst du ganz sicher sein das nicht hier schon dein Problem liegt.
Wenn du einen ungemangeten Switch hast ist das ggf. schwer zu sehen mit dem Sniffer, da du dazu einen Monitoring Port benötigst. Ggf. hast du noch irgendwo einen alten Hub den du zwischen Router und Wireshark Sniffer schleifen kannst ?
Andernfalls kannst du dir mit einem kleinen Trick helfen:
Ersetze temporär die NG Gurke mit dem Sniffer PC der genau diese NG Router IP hat und pinge den DD-WRT einmal an damit dessen MAC am DD-WRT bekannt ist.
Dann startest du einen Wireshark hier oder alternativ den MS NetMonitor und checkst ob die geforwardeten VNC Frames korrekt ankommen bzw. wie oben beschrieben geforwardet werden.
Zum Querchecken, um wirklich ganz sicher zu gehen, schliesst du das Sniffer Konstrukt nochmal direkt am DD-WRT LAN Port an um zu sehen ob, und mit welcher IP denn überhaupt das Port Forwarding gemacht wird.
Kommen sie nicht an, scheiterst du genau an diesem Problem und dann gibt es keine andere Lösung als einen Router der damit umgehen kann. Davon gibt es aber nur sehr wenige !
Ein simpler Workaround ist dann immer ganz einfach:
- VNC TCP 5900 Forwarding am DD-WRT auf die Rechner IP im 10.50.0.0er LAN zu machen und von dort aus dann wieder eine lokale VNC Verbindung auf den 192.168.2.2er Host auszuführen.
Nachteil: Der 10.50.0.0er VNC PC muss immer an sein auch wenn keiner da ist...
danke, werd ich mal ausprobieren.
hab hier einen w2008r2 server im 1. netz, währe also nicht das problem, allerdings bin ich immer den eleganteren lösungen zugeneigt^^
hab hier einen w2008r2 server im 1. netz, währe also nicht das problem, allerdings bin ich immer den eleganteren lösungen zugeneigt^^
Mh komisch.
Ich habe mal den NG abgemacht und den läppi mit der entsprechenden ip drann getan und wireshark angemacht.
wenn ich dann von meinem handy (über gprs) eine vnc verbindung herstellen will scheint der dd-wrt die Pakete weiterzuleiten.
Hier mal ein foto von dem sniffer pc (10.50.0.6)
http://img848.imageshack.us/i/vncportforward.png/
Ich habe mal den NG abgemacht und den läppi mit der entsprechenden ip drann getan und wireshark angemacht.
wenn ich dann von meinem handy (über gprs) eine vnc verbindung herstellen will scheint der dd-wrt die Pakete weiterzuleiten.
Hier mal ein foto von dem sniffer pc (10.50.0.6)
http://img848.imageshack.us/i/vncportforward.png/
Hallo,
wie hast du denn überhaupt verhindert, dass die PCs aus Netz 2 in's Internet können?
Die eingehende TCP-Verbingung hat ein 109.52.... IP, die wohl aus dem Internet ist. Geg. erhält also der VNC-PC die Anfrage, kann aber die Antwort nicht zurückrouten. Ich verstehe allerdings nicht, warum die IP nicht durch die des 1. Routers ersetzt wird. Ich war davon ausgegangen, ein NAT stattfindet, und damit die ursprüngliche Source-IP maskiert wird.
Der Zugriff von Netz 1 aus funktioniert aber, hast du geschrieben? Du kannst also von 10.50.0.x eine VNC-Verbindung zu 192.128.128.2:5900 aufbauen, korrekt?
Nächster Schritt: auf dem VNC-PC mal den tcpdump machen, ob die Requests auch dort wirklich noch ankommen. Wenn ja: Mit welcher Source-IP?
Meine Variante mit "Router 1 macht PortFW auf Router2 und der PortFW auf PC" finde ich immer noch gut.
Gruß
Filipp
wie hast du denn überhaupt verhindert, dass die PCs aus Netz 2 in's Internet können?
Die eingehende TCP-Verbingung hat ein 109.52.... IP, die wohl aus dem Internet ist. Geg. erhält also der VNC-PC die Anfrage, kann aber die Antwort nicht zurückrouten. Ich verstehe allerdings nicht, warum die IP nicht durch die des 1. Routers ersetzt wird. Ich war davon ausgegangen, ein NAT stattfindet, und damit die ursprüngliche Source-IP maskiert wird.
Der Zugriff von Netz 1 aus funktioniert aber, hast du geschrieben? Du kannst also von 10.50.0.x eine VNC-Verbindung zu 192.128.128.2:5900 aufbauen, korrekt?
Nächster Schritt: auf dem VNC-PC mal den tcpdump machen, ob die Requests auch dort wirklich noch ankommen. Wenn ja: Mit welcher Source-IP?
Meine Variante mit "Router 1 macht PortFW auf Router2 und der PortFW auf PC" finde ich immer noch gut.
Gruß
Filipp
das ungewöhnliche an dieser version ist ja das der 2. router eben genau andersherum angeschlossen ist als das "normalerweise" der fall ist.
eben mit der wan seite ans 192.168.128.x , sodass das netz eben eine sackgasse ist.
aus dem 1. netz (10.50.x.x) ists ja alles kein problem
ps. der router muss eingehenden paketen nichtmal seine ip aufzwängen, wenn der entsprechende pc ihn als gateway benutzt kommen die eh wieder über ihn zurück.
wenn aber nun der 2. router damit probleme hat, weil die netgear firmware ihrerseits in ihrer tabelle die rückroute ebenfalls mit der internet ip versieht, kanns natürlich nicht gehen, weil der NG kein gateway kennt, bzw. dieses auf seiner WAN seite vermutet.
ich merk schon, ich sniffe gleich mal ein bisschen rum...
eben mit der wan seite ans 192.168.128.x , sodass das netz eben eine sackgasse ist.
aus dem 1. netz (10.50.x.x) ists ja alles kein problem
ps. der router muss eingehenden paketen nichtmal seine ip aufzwängen, wenn der entsprechende pc ihn als gateway benutzt kommen die eh wieder über ihn zurück.
wenn aber nun der 2. router damit probleme hat, weil die netgear firmware ihrerseits in ihrer tabelle die rückroute ebenfalls mit der internet ip versieht, kanns natürlich nicht gehen, weil der NG kein gateway kennt, bzw. dieses auf seiner WAN seite vermutet.
ich merk schon, ich sniffe gleich mal ein bisschen rum...
Leider ist dein geposteter Screenshot unbrauchbar. Mal abgesehen davon das es hier eine eigene Bilder Upload Funktion gibt die uns externe Zwangslinks erspart..... 
Wichtig wäre zu sehen WELCHE Mac Adresse der DD-WRT Router in das Packet gepflanzt hat !
Die IP Adressierung ist ja absolut korrekt wie man sehen kann.
Im Layer 2 Teil muss dort allerdings die Mac Adresse des LAN Ports des NG drinstehen, damit dieser auch das Paket bekommt und ins 192.168.128er Netz weitersenden kann.
Temporär muss beim Sniffern dort die Mac vom Sniffer drinstehen. (Der ist ja jetzt dein Pseudorouter. Deshalb der Ping vom Sniffer an den DD-WRT um dessen Mac Adresse in den ARP Cache zu bekommen !!)
Erst dann weisst du das vom DD-WRT alles sauber adressiert wird.
Wenn du jetzt den Weg weiterverfolgst, dann kommt das Paket mit der 128.2er IP am Client an und der beantwortet das indem er es zurücksendet an die 109.x.x.x IP von remote.
Dafür hat er vermutlich aber nun kein Port Forwarding konfiguriert, und das paket bleibt an der NAT Firewall am WAN Port des NG hängen.
Du musst hier also zwingend eine Port Weiterleitung vom Source Port des 109er Absenders auf die IP des DD-WRT senden, denn sonst bleibt das Antwort Paket hängen.
Da hinreichend bekannt sind wie mies die NetGear Router sind wird der keine NAT Session Tabellen Eintrag für das Paket erzeugen, da sein Absender NICHT im lokalen IP Netz (LAN Port) des NG ist (hat ja einen 109er stat einer 10er IP)
Böser Buhmann ist also hier wie immer mal wieder der NG !!
Du kannst das auch umgehen indem du die IP am NG in einen sog. DMZ Host verwandelst im Setup und auf die IP des DD-WRT forwardest.
Damit macht man dann das Scheunentor ganz weit auf für den .128.2er Host.
Da NG aber eben miese und unintelligente Produkte verkauft wird das vermutlich deine einzige Option sein....sofern er das überhaupt supportet ?!
Wichtig wäre zu sehen WELCHE Mac Adresse der DD-WRT Router in das Packet gepflanzt hat !
Die IP Adressierung ist ja absolut korrekt wie man sehen kann.
Im Layer 2 Teil muss dort allerdings die Mac Adresse des LAN Ports des NG drinstehen, damit dieser auch das Paket bekommt und ins 192.168.128er Netz weitersenden kann.
Temporär muss beim Sniffern dort die Mac vom Sniffer drinstehen. (Der ist ja jetzt dein Pseudorouter. Deshalb der Ping vom Sniffer an den DD-WRT um dessen Mac Adresse in den ARP Cache zu bekommen !!)
Erst dann weisst du das vom DD-WRT alles sauber adressiert wird.
Wenn du jetzt den Weg weiterverfolgst, dann kommt das Paket mit der 128.2er IP am Client an und der beantwortet das indem er es zurücksendet an die 109.x.x.x IP von remote.
Dafür hat er vermutlich aber nun kein Port Forwarding konfiguriert, und das paket bleibt an der NAT Firewall am WAN Port des NG hängen.
Du musst hier also zwingend eine Port Weiterleitung vom Source Port des 109er Absenders auf die IP des DD-WRT senden, denn sonst bleibt das Antwort Paket hängen.
Da hinreichend bekannt sind wie mies die NetGear Router sind wird der keine NAT Session Tabellen Eintrag für das Paket erzeugen, da sein Absender NICHT im lokalen IP Netz (LAN Port) des NG ist (hat ja einen 109er stat einer 10er IP)
Böser Buhmann ist also hier wie immer mal wieder der NG !!
Du kannst das auch umgehen indem du die IP am NG in einen sog. DMZ Host verwandelst im Setup und auf die IP des DD-WRT forwardest.
Damit macht man dann das Scheunentor ganz weit auf für den .128.2er Host.
Da NG aber eben miese und unintelligente Produkte verkauft wird das vermutlich deine einzige Option sein....sofern er das überhaupt supportet ?!
hab nochmal die mac adresse (hatte sniffing gespeichert) mit der vom läppi verglichen, die stimmt.
hab dann mal auf dem 192.168.128.2 PC gesnifft, da ich wie du die vermutung hatte das der NG nicht weis wie er die antwortpakete weiterleiten soll, aber am host pc kommt nichtmal was an (aus dem inet. ausm 1. netz selbst geht es.)
Ich vermute der NG schmeisst die pakete einfach auf die müllhalde, da er sich nicht erklären kann wie pakete aus einem ihm fremden subnetz bei ihm eintrudeln können.
wenn ich aus dem 1. netz connecte ist das natürlich kein problem den da isser ja selber mitglied.
also würde das port forwarding, welches ich glaub ich schon getestet hab auch nicht gehen.
eine andere möglichkeit wäre noch dem NG eine static route für alle ihm unbekannten netzte (0.0.0.0) einzurichten, das ist jedoch nicht möglich (fehlermeldung), und bleibt zu bezweifeln ob er so intelligent ist das es funktioniert
edit.
ich glaub nicht das es möglich ist, aber wenn der dd-wrt geforwardete pakte maskieren würde und ip durch seine ersetzen würde müsste es gehen
hab dann mal auf dem 192.168.128.2 PC gesnifft, da ich wie du die vermutung hatte das der NG nicht weis wie er die antwortpakete weiterleiten soll, aber am host pc kommt nichtmal was an (aus dem inet. ausm 1. netz selbst geht es.)
Ich vermute der NG schmeisst die pakete einfach auf die müllhalde, da er sich nicht erklären kann wie pakete aus einem ihm fremden subnetz bei ihm eintrudeln können.
wenn ich aus dem 1. netz connecte ist das natürlich kein problem den da isser ja selber mitglied.
also würde das port forwarding, welches ich glaub ich schon getestet hab auch nicht gehen.
eine andere möglichkeit wäre noch dem NG eine static route für alle ihm unbekannten netzte (0.0.0.0) einzurichten, das ist jedoch nicht möglich (fehlermeldung), und bleibt zu bezweifeln ob er so intelligent ist das es funktioniert
edit.
ich glaub nicht das es möglich ist, aber wenn der dd-wrt geforwardete pakte maskieren würde und ip durch seine ersetzen würde müsste es gehen
