Anfragen aus dem Internet werden geblockt
Hallo,
Ich habe bereits mehrfach gesucht und auch div. Varianten versucht, leider ohne Erfolg.
Nun zu meinem Problem
Wir haben 2 Netzwerke:
1. Ein Netzwerk PRIVAT - 192.168.100.* mit Internetanschluss Gateway 192.168.100.2 = FB 7170
mit Route > 192.168.178.0 (255.255.255.0) via Gateway 192.168.100.254
2. Ein Netzwerk GESCHÄFT - 192.168.178.* mit Internetanschluss Gateway 192.168.178.1 = FB 7170 (hier läuft eine no-ip Adressierung)
mit Route > 192.168.100.0 (255.255.255.0) via Gateway 192.168.178.254
Jedes Netz hat einen eigenständigen DHCP, die dauerhaft vorhandene PCs habe ich aber mittels static IP ausserhalb der DHCP Bereiche konfiguriert.
Zur Verbindung der beiden Netze habe ich einen Linksys WRT54G V1.1 mit der Firmware DD-WRT (v24 sp2) dazwischen geklemmt.
WAN - 192.168.178.254
LAN1 - 192.168.100.254
Ich kann ins jeweils andere Netz pingen, ich komme auf das im anderen Netz vorhandene Netzwerklaufwerk und den Drucker und ich komme auch auf die jeweils im anderen Netz vorhandene Konfigurationsseite der FritzBox.
Was nicht geht ist dass ich via Internet z.B. auf die Configseite der FB 7170 PRIVAT (IP: 192.168.100.2) zugreife. Der Weg auf diese Config führt aber über die FB 7170 GESCHÄFT (IP: 192.168.178.1) da hier die no-ip Adressierung läuft. Auf der 192.168.100.2 FB PRIVAT geht es aufgrund des Anbieters nicht.
Der Weg der Anfrage ist also
Internet > FB 7170 (IP: 192.168.178.1) > WRT54G V1.1 > FB 7170 (IP: 192.168.100.2) via Beispielport 460
Leider bleibt die Anfrage vermutlich bei dem WRT54G V1.1 hängen. Auf seine Configseite (Beispielport 461) komme ich ohne Probleme.
Ich habe in der FB 7170 GESCHÄFT (IP: 192.168.178.1) die festgelegten Ports weitergeroutet auf die jeweilige IP Adresse und auch im WERT54G habe ich sie zu Testzwecken weitergeleitet, leider ohne Erfolg.
Lustiger Weise war es ganz am Anfang mal möglich aus dem Internet auf die Seiten zuzugreifen, jetzt musste ich das Gerät aber zurücksetzen und es funktioniert nicht mehr.
Es versteht sich von selbst, dass der WRT54G V1.1 im ROUTER Modus läuft und die FIREWALL deaktiviert ist.
Hat noch jemand einen Tipp für mich?
Ich danke euch schon mal für eure Hilfe!
Liebe grüße
Rocky
Ich habe bereits mehrfach gesucht und auch div. Varianten versucht, leider ohne Erfolg.
Nun zu meinem Problem
Wir haben 2 Netzwerke:
1. Ein Netzwerk PRIVAT - 192.168.100.* mit Internetanschluss Gateway 192.168.100.2 = FB 7170
mit Route > 192.168.178.0 (255.255.255.0) via Gateway 192.168.100.254
2. Ein Netzwerk GESCHÄFT - 192.168.178.* mit Internetanschluss Gateway 192.168.178.1 = FB 7170 (hier läuft eine no-ip Adressierung)
mit Route > 192.168.100.0 (255.255.255.0) via Gateway 192.168.178.254
Jedes Netz hat einen eigenständigen DHCP, die dauerhaft vorhandene PCs habe ich aber mittels static IP ausserhalb der DHCP Bereiche konfiguriert.
Zur Verbindung der beiden Netze habe ich einen Linksys WRT54G V1.1 mit der Firmware DD-WRT (v24 sp2) dazwischen geklemmt.
WAN - 192.168.178.254
LAN1 - 192.168.100.254
Ich kann ins jeweils andere Netz pingen, ich komme auf das im anderen Netz vorhandene Netzwerklaufwerk und den Drucker und ich komme auch auf die jeweils im anderen Netz vorhandene Konfigurationsseite der FritzBox.
Was nicht geht ist dass ich via Internet z.B. auf die Configseite der FB 7170 PRIVAT (IP: 192.168.100.2) zugreife. Der Weg auf diese Config führt aber über die FB 7170 GESCHÄFT (IP: 192.168.178.1) da hier die no-ip Adressierung läuft. Auf der 192.168.100.2 FB PRIVAT geht es aufgrund des Anbieters nicht.
Der Weg der Anfrage ist also
Internet > FB 7170 (IP: 192.168.178.1) > WRT54G V1.1 > FB 7170 (IP: 192.168.100.2) via Beispielport 460
Leider bleibt die Anfrage vermutlich bei dem WRT54G V1.1 hängen. Auf seine Configseite (Beispielport 461) komme ich ohne Probleme.
Ich habe in der FB 7170 GESCHÄFT (IP: 192.168.178.1) die festgelegten Ports weitergeroutet auf die jeweilige IP Adresse und auch im WERT54G habe ich sie zu Testzwecken weitergeleitet, leider ohne Erfolg.
Lustiger Weise war es ganz am Anfang mal möglich aus dem Internet auf die Seiten zuzugreifen, jetzt musste ich das Gerät aber zurücksetzen und es funktioniert nicht mehr.
Es versteht sich von selbst, dass der WRT54G V1.1 im ROUTER Modus läuft und die FIREWALL deaktiviert ist.
Hat noch jemand einen Tipp für mich?
Ich danke euch schon mal für eure Hilfe!
Liebe grüße
Rocky
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 268469
Url: https://administrator.de/contentid/268469
Ausgedruckt am: 19.11.2024 um 20:11 Uhr
7 Kommentare
Neuester Kommentar
Es ist klar das das nicht funktionierne kann.
Soweit hast du in deiner lokalen Installation alles genau richtig gemacht. Das zeigt ja auch das das lokale Netzwerk perfekt funktioniert.
Leider bist du trotz der guten Beschreibung oben recht unpräzise was den Zugriff auf das Netzwerk von Remote anbetrifft.
Du sagst immer "via Internet" das kann bei der FB ja via VPN oder via Port Forwarding sein.
Wir raten hier also mal das du via VPN zugreifst, wie es üblich und auch sicher ist.
Vermutlich hast du hier dann nur den VPN Zugriff auf die FB in .178.0 /24 nur auf diese FB eingerichtet ?! Wenn du dann am aktivierten VPN Client Rechner mal ein route print eingibst um die die Routing Tabelle des Rechners anzusehen wirst du erkennen das dort vermutlich nur einzig die Route ins .178.0er Netz drinsteht und die ins .100.0er Netz fehlt.
Letztlich bedeutet das das einzig nur das .178.0er Netz in den Tunnel geroutet wird. Da kannst du dann machen was du willst, das .100.0er Netz wirst du so niemals errreichen ! Der WRT oder irgendwelche sinnfreien Ports hat damit auch nichts zu tun und kann das logischerweise unmöglich fixen.
Die Lösung ist aber kinderleicht:
Du musst dem VPN Client beim Dialin nur mitgeben, das er beide Netze hinter dem VPN Tunnel hat bzw. deine beiden Netze durch den VPN Tunnel routet.
Das AVM VPN Portal hat eine entsprechende Anleitung für dich wie man das im Handumdrehen löst:
http://bingo.avm.de/de/Service/FAQs/FAQ_Sammlung/15136.php3
Wenn du das umsetzt funktioniert das einwandfrei.
route print und auch Traceroute oder Pathping sind als Tools hier wieder deine besten Freunde
Soweit hast du in deiner lokalen Installation alles genau richtig gemacht. Das zeigt ja auch das das lokale Netzwerk perfekt funktioniert.
Leider bist du trotz der guten Beschreibung oben recht unpräzise was den Zugriff auf das Netzwerk von Remote anbetrifft.
Du sagst immer "via Internet" das kann bei der FB ja via VPN oder via Port Forwarding sein.
Wir raten hier also mal das du via VPN zugreifst, wie es üblich und auch sicher ist.
Vermutlich hast du hier dann nur den VPN Zugriff auf die FB in .178.0 /24 nur auf diese FB eingerichtet ?! Wenn du dann am aktivierten VPN Client Rechner mal ein route print eingibst um die die Routing Tabelle des Rechners anzusehen wirst du erkennen das dort vermutlich nur einzig die Route ins .178.0er Netz drinsteht und die ins .100.0er Netz fehlt.
Letztlich bedeutet das das einzig nur das .178.0er Netz in den Tunnel geroutet wird. Da kannst du dann machen was du willst, das .100.0er Netz wirst du so niemals errreichen ! Der WRT oder irgendwelche sinnfreien Ports hat damit auch nichts zu tun und kann das logischerweise unmöglich fixen.
Die Lösung ist aber kinderleicht:
Du musst dem VPN Client beim Dialin nur mitgeben, das er beide Netze hinter dem VPN Tunnel hat bzw. deine beiden Netze durch den VPN Tunnel routet.
Das AVM VPN Portal hat eine entsprechende Anleitung für dich wie man das im Handumdrehen löst:
http://bingo.avm.de/de/Service/FAQs/FAQ_Sammlung/15136.php3
Wenn du das umsetzt funktioniert das einwandfrei.
route print und auch Traceroute oder Pathping sind als Tools hier wieder deine besten Freunde
...und deine Daten dann vollkommen ungeschützt für alle sichtbar im Internet übertragen...???
OK, deine Entscheidung !
Es geht natürlich auch mit Port Forwarding. Du musst dann aber Port Translation machen also einen PFW Eintrag in der FB mit
Damit werden dann eingehende TCP 8088 Pakete als TCP 80 auf die FB Privat geforwardet.
OK, deine Entscheidung !
Es geht natürlich auch mit Port Forwarding. Du musst dann aber Port Translation machen also einen PFW Eintrag in der FB mit
- Eingehend TCP 8088 forwarden auf ausgehend 192.168.100.1 Port TCP 80
Damit werden dann eingehende TCP 8088 Pakete als TCP 80 auf die FB Privat geforwardet.
Die Firewall im WRT solltest du ausschalten, denn die brauchst du da ja nicht wirklich. Normal ist sie das eigentlich auch, wenn man den WRT im Router Modus (kein NAT) betreibt !
Ich glaube aber das das Problem ein ganz anderes ist....
Plaziere einen Wireshark Sniffer im Geschätsnetz und mache den Zugriff via PFW auf die Privat FB.
Hier solltest du nun ein TCP 80 Paket sehen was als Absender IP die IP des remoten Clients hat, also vermutlich einen öffentliche und als Ziel IP die der Privat FB.
Was jetzt passiert ist das die Geschäfts FB das via WRT54 an die Privat FB forwardet. Dort kommt das Paket auch an aber das Antwort Paket an die öffentliche IP des Clients schickt die Privat FB nun nicht via Geschäfts FB zurück an den Client sondern routet sie selber ins Internet.
Der Wireshark sollte dir also zeigen das gar keinen Antwort mehr via Geschäfts FB zurückgeht an den Client.
Dadurch das es direkt vi Privat FB ins Internet geht kommt das Antwort Paket am Client mit einer anderen Absender IP (die Provider IP des Privat Routers) am Client an und die Session dort bricht sofort ab.
Die Privat FB hat ja nur eine statische Route ins Geschäfts Netz und eine default zum Provider, sie muss das paket also direkt ins Internet routen.
Am TCP Stack des remoten Clients bewirkt dieser IP Adress Mismatch der Absender IP aber den sofortigen Session Abbruch.
Fazit: Hat dein Client eine öffentliche IP ist das so nicht lösbar, es sei denn die öffentliche IP befindet sich immer in einem und derselben Range. Wenn du also wechselnde Client IPs hast die aus dem 89.x.x.x IP Umfeld kommen, dann könntest du eine statische Route auf der Privat FB konfigurieren ala:
Ziel: 89.0.0.0, Maske: 255.0.0.0, Gateway: 192.168.178.1
Das würde dann alle Absender IPs bzw. Ziel IPs an der Privat FB über die Geschäfts FB senden und dann würde es wieder klappen !
Andere Lösung: VPN damit umgehst du das problem auch.
Ich glaube aber das das Problem ein ganz anderes ist....
Plaziere einen Wireshark Sniffer im Geschätsnetz und mache den Zugriff via PFW auf die Privat FB.
Hier solltest du nun ein TCP 80 Paket sehen was als Absender IP die IP des remoten Clients hat, also vermutlich einen öffentliche und als Ziel IP die der Privat FB.
Was jetzt passiert ist das die Geschäfts FB das via WRT54 an die Privat FB forwardet. Dort kommt das Paket auch an aber das Antwort Paket an die öffentliche IP des Clients schickt die Privat FB nun nicht via Geschäfts FB zurück an den Client sondern routet sie selber ins Internet.
Der Wireshark sollte dir also zeigen das gar keinen Antwort mehr via Geschäfts FB zurückgeht an den Client.
Dadurch das es direkt vi Privat FB ins Internet geht kommt das Antwort Paket am Client mit einer anderen Absender IP (die Provider IP des Privat Routers) am Client an und die Session dort bricht sofort ab.
Die Privat FB hat ja nur eine statische Route ins Geschäfts Netz und eine default zum Provider, sie muss das paket also direkt ins Internet routen.
Am TCP Stack des remoten Clients bewirkt dieser IP Adress Mismatch der Absender IP aber den sofortigen Session Abbruch.
Fazit: Hat dein Client eine öffentliche IP ist das so nicht lösbar, es sei denn die öffentliche IP befindet sich immer in einem und derselben Range. Wenn du also wechselnde Client IPs hast die aus dem 89.x.x.x IP Umfeld kommen, dann könntest du eine statische Route auf der Privat FB konfigurieren ala:
Ziel: 89.0.0.0, Maske: 255.0.0.0, Gateway: 192.168.178.1
Das würde dann alle Absender IPs bzw. Ziel IPs an der Privat FB über die Geschäfts FB senden und dann würde es wieder klappen !
Andere Lösung: VPN damit umgehst du das problem auch.