Route zu an Zweit-Router angeschlossenem Receiver klappt nicht mehr

Heart

Neuer User
Mitglied seit
9 Nov 2005
Beiträge
76
Punkte für Reaktionen
0
Punkte
6
Hallo,

ich habe hier eine FritzBox 7270 (192.168.178.1) als Hauptrouter im Einsatz. Per DLAN wird das DSL zum Zweit-Router (192.168.1.1 TP-Link mit openWRT) gebracht, an dem dann z.B. mein Sat-Receiver angeschlossen ist.

Ich habe bisher problemlos vom PC (der an der Fritzbox hängt) auf die IP des Sat-Receivers zugreifen können (openwebif enigma router), oder auch per ssh auf die Receiver IP. Von heute auf morgen klappt das nicht mehr :(

Ich habe hierzu auf der FritzBox eine statische Route angelegt und damit klappte das eigentlich immer wunderbar.

IPv4-Netzwerk . . . 192.168.1.0
Subnetzmaske . . . 255.255.255.0
Gateway . . . 192.168.178.134
IPv4-Route aktiv

Ich kann auch noch vom PC auf den Router selber pingen bzw. eine ssh Verbindung aufbauen (zu 192.168.1.1), aber eben nicht mehr zu 192.168.1.225 wo der Receiver hat.

Code:
➜  traceroute 192.168.1.225
traceroute to 192.168.1.225 (192.168.1.225), 30 hops max, 60 byte packets
 1  fritz.box (192.168.178.1)  0.467 ms  1.048 ms  1.230 ms
 2  192.168.178.134 (192.168.178.134)  30.588 ms  30.606 ms  30.595 ms
 3  192.168.178.134 (192.168.178.134)  30.582 ms  30.881 ms  30.871 ms
➜  ping 192.168.1.225      
PING 192.168.1.225 (192.168.1.225) 56(84) bytes of data.
From 192.168.178.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.178.134)
From 192.168.178.134 icmp_seq=1 Destination Port Unreachable
From 192.168.178.134 icmp_seq=2 Destination Port Unreachable
From 192.168.178.134 icmp_seq=3 Destination Port Unreachable
^C
--- 192.168.1.225 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2001ms
IPv4 WAN Status des openWRT Routers ist im Anhang zu finden.
 

Anhänge

  • openwrt.png
    openwrt.png
    15.9 KB · Aufrufe: 13
Zuletzt bearbeitet:
Subnetzmaske auf 255.255.0.0, würde ich mal auf rasch sagen...
 
Dann wären es keine zwei Subnetze mehr und damit kein Routing.
 
Solch profane Sachen wie einen Neustart des OpenWRT abzufragen, traut man sich ja fast nicht ... hast Du sicherlich gemacht.

Wenn der OpenWRT-Router bei Deinem Test für ein icmp-echo-request-Paket eine icmp-3/3-Antwort (port unreachable) schickt, dann ist das ja nicht weiter verwunderlich, wenn Du nicht im OpenWRT-Router generell das Pingen vom WAN (192.168.178.0/24 oder kleiner) auf das Ziel (192.168.1.225/32 oder kleiner) zugelassen hast. Wenn Du nur das Enigma2-OpenWebif (TCP/80 oder TCP/443, je nach Konfiguration) und den Dropbear (TCP/22) weitergeleitet hast, was soll denn der OpenWRT dann auf dein ping (ICMP) oder traceroute (UDP/ICMP ja nach System) antworten ? Für den ist Dein PC schlicht "der Böse aus dem WAN" und dem muß er ja nicht mitteilen, daß es die 192.168.1.225 bei ihm überhaupt gibt, außer Du hast wirklich die notwendigen Zugriffe als Portforwarding erlaubt oder den Receiver "nackig" ins WAN (des TP-Link) gestellt.

Vielleicht schaust Du besser noch einmal nach der OpenWRT-Konfiguration, die Route in der FB und der WAN-Status des TP-Link sind jedenfalls nicht die Ursache, da ist ja alles im Lot. Ansonsten braucht man schon einige Informationen zur OpenWRT-Konfiguration mehr ...
 
@PeterPawn Das verwunderliche ist ja, dass ich "außer openWRT von 12.x auf jetzt die aktuelle 14.x aktualisiert habe" und vorher ging es ja (beides, ssh auf receiver und openwebif per Browser).

Gehen wir die Sache andersrum an. Was müsste ich (wo) korrekterweise einstellen, damit ich webif + ssh auf den Receiver vom PC aus durchführen kann?

Vielen Dank!
 
Was müsste ich (wo) korrekterweise einstellen, damit ich webif + ssh auf den Receiver vom PC aus durchführen kann?
Du brauchst die schon erwähnten Portforwardings auf dem OpenWRT-Router, die Einrichtung ist hier beschrieben. Zusammengefaßt: TCP/22 für SSH, TCP/80 für HTTP und, wenn Du das verwendest, TCP/443 für HTTPS.

Wenn das vor dem Update des OpenWRT (das hattest Du in der ersten Meldung ja glatt unterschlagen ;)) ohne Portforwards funktioniert haben sollte, kann da praktisch keine Firewall auf dem WAN-Interface aktiv gewesen sein und dann stellt sich mir eigentlich die Frage, wozu dieser Router dann überhaupt gut war. Trennt der wirklich zwei Netze oder ist das mehr so ein "so ging es eben am einfachsten"-Fall ?
 
Danke @PeterPawn

Es ging zuvor wahrscheinlich problemlos, weil die openWRT Firewall überall auf "accept" stand, weil sie zuvor als AP diente (im selben Netz wie die FritzBox). Da ich so aber leider nicht das WLAN des openWRT nutzen kann (wpa2), habe ich dem openWRT Router eine eigenes Subnetz gegeben und betreibe dort nun ein eigenständiges WLAN Netz.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.