Keien Portweiterleitung mehr nach Update auf FW 84.06.51

[knilix]

[Edit Novize: Abgetrennt von hier: FRITZ!Box 7390 Firmware 84.06.51 vom 26.04.2016]

Hallo,

hab heute (leider) ein Update meiner Fritzbox auf 06.51 gemacht. Leider weil nun sämtliche Portweiterleitungen nicht mehr funktionieren. Ich komm zwar noch Remote direkt auf die Fritzbox, aber sonst geht nix mehr.

Hab alle Portweiterleitungen mehrmals neu eingerichtet und auch die ganze Fritzbox auf Werkseinstellungen zurück gesetzt und nochmal komplett neu konfiguriert. Leider ohne Erfolg. Hat jemand einen Tipp für mich was ich noch probieren könnte oder ist das auch ein Bug in der neusten FW?

 

[KunterBunter]

Du könntest wieder zurückgehen auf die vorherige Version, um zu sehen, ob es dort dann auch auftritt. Falls ja, ist es kein Bug in der neuesten Firmware.

 

[knilix]

Geht beim zurückgehen auf eine vorherige Version die Config verloren oder kann man das auch "remote" machen?

 

[PeterPawn]

Ich kriege bei solchen Fragen immer eine Gänsehaut und kann mich des Eindrucks nicht erwehren, daß da von einer wirklich wirklich alten Version (die Portweiterleitungen auf die Box selbst oder auf andere Geräte, die sich nicht hinter "dev lan" befinden, geht seit 06.20 nicht mehr, wenn ich mich richtig erinnere) auf die 06.51 nach sehr langer Zeit ohne Änderungen aktualisiert wurde.

Wenn ich mich irre, um so besser ... dann hilft aber auch die Angabe, welches die vorherige Version denn nun war, ungemein und auch eine etwas genauere Beschreibung, was denn nun in der Firmware für so eine neu eingerichtete Portweiterleitung angezeigt wird (wohin die überhaupt gehen soll) und was davon in der ar7.cfg landet, wäre sicherlich nützlich.

Das kann bei einer falschen internen IP-Adresse (der Host, der Ziel der Freigabe sein soll, kann nicht identifiziert werden) schon losgehen (wäre nach Factory-Reset aber auch komisch) ... aber hier wird ja noch nicht einmal richtig deutlich, ob die Portweiterleitungen sich nicht eintragen lassen oder ob sie dann trotz erfolgreich vorgenommenem Eintrag nicht funktionieren.

Ich kann Ports in der 84.06.51 freigeben und die Daten kommen dort auch an - also ist es eher kein genereller Fehler in der Firmware und ein solcher wäre bestimmt auch dem einen oder dem anderen in diesem Thread in fast zwei Monaten schon mal aufgefallen.

Bleibt die L8-Vermutung und die kann man nur mit Fakten entkräften ...

 

[knilix]

Danke PeterPawn für deine Antwort. Nachdem ich eine Nacht drüber geschlafen und meinen Post nochmal gelesen habe, wird mir klar, dass ich für jemanden, der sich nicht den ganzen Tag mit diesem Thema beschäftigt hat, zu wenige Infos vermittelt habe.

Welche Version die Fritzbox vor dem Update hatte, kann ich leider nicht mehr sagen, gefühlt ca. 2,5 Jahre alt.

Die Portweiterleitungen lassen sich über die Weboberfläche ohne Probleme eintragen und werden anschließend auch angezeigt.

Portfreigabe bearbeiten

Portfreigabe aktiv für Andere Anwendungen
Bezeichnung TK Web
Protokoll TCP
von Port 80 bis Port 80

an Telefonanlage
manuelle Eingabe der IP-Adresse
192.168.10.254
an Port 80



Wenn ich allerdings dann versuche über die statische WAN-IP den Webserver per http zu erreichen bekomme ich nur einen ERR_CONNECTION_TIMED_OUT im Browser.

Andere Portweiterleitungen auf andere Ports und andere Zielhosts funktionieren ebenfalls nicht. Test per Telnet IP Port können keine Verbindung herstellen.

Wie kann ich prüfen was tatsächlich in der ar7.cfg ankommt? Kann diese dann ausgelesen werden?

Vielleicht sind wir nun ja auf Layer7 angekommen



UPDATE

Hab eben über das erstellen der Support Dateien folgende Config gefunden:


##### BEGIN SECTION forwards Configured forwardings
--- Configured Forwardings ---
vpn:internet:udp 0.0.0.0:500 0.0.0.0:500
vpn:internet:udp 0.0.0.0:4500 0.0.0.0:4500
normal:internet:tcp 0.0.0.0:492 0.0.0.0:492 0
normal:internet:tcp 0.0.0.0:3400 192.168.10.200:3400 0 # UTM VPN TCP
normal:internet:udp 0.0.0.0:3400 192.168.10.200:3400 0 # UTM VPN UDP
normal:internet:tcp 0.0.0.0:8080 192.168.10.200:4444 0 # UTM VPN WEB
normal:internet:tcp 0.0.0.0:80 192.168.10.254:80 0 # TK web
##### END SECTION forwards
##### BEGIN SECTION port_forwards IPv4 forwardings
--- Active IPv4 Portforwardings ---
internet
VPN UDP 192.168.10.1 500 "WAN-IP" 500 "VPN"
SELF TCP 192.168.10.1 492 "WAN-IP" 492 "0/normal"
FORW TCP 192.168.10.254 "WAN-IP" 80 "Telefonanlage"
FORW TCP 192.168.10.200 4444 "WAN-IP" 8080 "UTM VPN WEB"
FORW TCP 192.168.10.200 3400 "WAN-IP" 3400 "UTM VPN TCP"
IGDPROBE TCP 192.168.10.1 9 "WAN-IP" 9 "IGDPROBE4"
allow-only-from 255.255.255.255/32:9
VPN UDP 192.168.10.1 4500 "WAN-IP" 4500 "VPN"
FORW UDP 192.168.10.200 3400 "WAN-IP" 3400 "UTM VPN UDP"
mstv

 

[Ganzfix]

Kannst du denn die Telefonanlage über die lokale IP 192.168.10.254 erreichen?
Erscheint die Telefonanlage unter Heimnetz->Heimnetzübersicht -> Netzwerkverbindungen?
Ist dort der Name der Telefonanlage in blauer Schrift mit Link und führt dieser Link zur Telefonanlage?

Hast Du die Portfreigabe mit manueller Eingabe der IP-Adresse gemacht oder mit dem Namen des Gerätes? Falls mit dem Namen probier mal manueller Eingabe der IP-Adresse.

 

[knilix]

Intern klappt alles wunderbar.

Telefonanlage erscheint in blauer Schrift und der Link funktioniert auch.

Hatte auch schon per Eingabe der IP-Adresse versucht die Portregel anzulegen -> gleiches Verhalten.

 

[Ganzfix]

Was für eine Telefonanlage ist es denn? Bei Auerswald gibt es z.B. eine schwarze Liste, auf welche die Telefonanlage teilweise selbstständig IP-Adresse setzt.

 

[knilix]

An der Telefonanlage(AASTRA) liegt es glaub ich nicht...Dort wurde nichts geändert und bei einem zweiten Zielhost im internen Lan funktionieren die Weiterleitungen ebenfalls nicht

 

[Ganzfix]

Und du hast nicht zufällig noch eine weitere Firewall, welche dazwischen ist und vielleicht stört?

Oder wofür sind folgende Einträge:
FORW TCP 192.168.10.200 4444 "WAN-IP" 8080 "UTM VPN WEB"
FORW TCP 192.168.10.200 3400 "WAN-IP" 3400 "UTM VPN TCP"

 

[knilix]

Nein dazwischen hängt sonst nix mehr.

Diese Einträge sind Weiterleitungen auf einen anderen Zielhost im selben Netzwerk.

All diese Weiterleitungen haben eben vor dem Update der Firmware funktioniert. Daher war meine Vermutung, dass es vielleicht in BUG in der Version ist. Aber wie von [SIZE=2pt]PeterPawn[/SIZE] schon angemerkt, dann hätten wohl noch mehr Leute Probleme damit.

 

[PeterPawn]

Ich bin etwas irritiert ... nach meiner Kenntnis dürfte die Freigabe für Port 492 (auf die FRITZ!Box selbst => SELF) sich über das GUI nach dem Versuch mit den Werkseinstellungen gar nicht erstellen lassen. Wie wurde diese denn angelegt?

Bei den Tests erfolgt der Zugriff tatsächlich aus dem Internet oder aus dem LAN auf die WAN-IP? Bei letzterem sollte zwar "NAT-Hairpinning" stattfinden, aber da könnte es ja tatsächlich wieder sein, daß irgendwelche Routen für die Antworten der Geräte im LAN nicht funktionieren, weil diese Zugriffe natürlich mit einer LAN-IP ankommen würden.

Für einen Test würde ich das Problem in die zwei Richtungen zerlegen und an der FRITZ!Box mit einem Packetdump ermitteln, ob Pakete aus dem WAN sichtbar sind und diese auch auf dem LAN-Port weitergereicht werden. Das klappt u.U. nur für SYN-Pakete so richtig (wenn es um TCP geht), weil weitere Pakete (manchmal) nicht im Dump auftauchen (warum weiß ich nicht), wenn sie der "packet accelerator" (vermutlich zu sehr ) beschleunigt hat. Sind die Anfragen sichtbar, ist es vielleicht doch ein Problem der Antworten.

AVM hat mit Version 06.20 (wenn ich mich nicht im Zeitrahmen irre) tatsächlich einige weiterreichende Veränderungen in der Firmware in Bezug auf Portweiterleitungen vorgenommen. Unter anderem wird jetzt streng geprüft, daß das Ziel solcher Weiterleitungen sich tatsächlich hinter dem Interface "lan" (das ist eine Bridge, in der die Ethernet-Interfaces und das WLAN-Interface versammelt sind) befindet und damit geht eine Portweiterleitung weder in das Gastnetz noch (prinzipbedingt) an einen VPN-Client oder an die Box selbst. Daher verstehe ich den "SELF"-Eintrag nicht, ein solcher läßt sich (das aber schon länger als 06.20) eigentlich nur von Hand in die ar7.cfg eintragen. Daher staune ich, wie Dir das über das GUI gelungen sein mag. Oder hat AVM da bei der 06.51 die Zügel tatsächlich gelockert?

 

[knilix]

Ich bin etwas irritiert ... nach meiner Kenntnis dürfte die Freigabe für Port 492 (auf die FRITZ!Box selbst => SELF) sich über das GUI nach dem Versuch mit den Werkseinstellungen gar nicht erstellen lassen. Wie wurde diese denn angelegt?

Unter Internet->Freigaben->Fritzbox-Dienste-> TCP-Port für HTTPS den Port geändert und
unter Internet->Freigaben->Fritzbox-Dienste-> Internetzugriff auf die FritzBox über HTTPs aktivieren

Port 492 habe ich gewählt, weil ich diesen bereits in Doku und Links hinterlegt hatte.

Bei den Tests erfolgt der Zugriff tatsächlich aus dem Internet oder aus dem LAN auf die WAN-IP? Bei letzterem sollte zwar "NAT-Hairpinning" stattfinden, aber da könnte es ja tatsächlich wieder sein, daß irgendwelche Routen für die Antworten der Geräte im LAN nicht funktionieren, weil diese Zugriffe natürlich mit einer LAN-IP ankommen würden.

Ja es wird tatsächlich über die WAN-IP von einem(bzw. mehreren) anderen externen Anschlüssen versucht Verbindungen herzustellen. Leider alles ohne Erfolg.

AVM hat mit Version 06.20 (wenn ich mich nicht im Zeitrahmen irre) tatsächlich einige weiterreichende Veränderungen in der Firmware in Bezug auf Portweiterleitungen vorgenommen. Unter anderem wird jetzt streng geprüft, daß das Ziel solcher Weiterleitungen sich tatsächlich hinter dem Interface "lan" (das ist eine Bridge, in der die Ethernet-Interfaces und das WLAN-Interface versammelt sind) befindet und damit geht eine Portweiterleitung weder in das Gastnetz noch (prinzipbedingt) an einen VPN-Client oder an die Box selbst. Daher verstehe ich den "SELF"-Eintrag nicht, ein solcher läßt sich (das aber schon länger als 06.20) eigentlich nur von Hand in die ar7.cfg eintragen. Daher staune ich, wie Dir das über das GUI gelungen sein mag. Oder hat AVM da bei der 06.51 die Zügel tatsächlich gelockert?

Wie lässt sich der Sachverhalt mit Interface "lan" denn überprüfen? In der GUI finde ich dazu nichts. Alle Zielhosts hängen über einen unmanaged 8-Port- Switch am LAN1 der Fritzbox. Die Fritzbox erkennt sowohl den Switch, als auch die Hosts unter Heimnetz->Heimnetzübersicht->Alle Geräte.

 

[PeterPawn]

Ah ok ... das ist also die aktivierte Fernwartung - hätte ich auch erkennen können/sollen; manchmal hat man ein Brett mit Tomaten vor den Augen - das ist eine der Freigaben, die das FRITZ!OS noch auf die Box einrichtet (neben SIP, FTP, IPSec - jeweils wenn nötig).

Dann würde ich tatsächlich wie skizziert vorgehen und über die Paketmitschnitt-Möglichkeit der FRITZ!Box ("1. Internet-Verbindung" und "lan" parallel aufzeichnen) mal nachschauen, ob die Pakete auf der FRITZ!Box bereits versanden oder doch noch ins LAN gelangen.

Wenn ich die Fehlerbeschreibung richtig verstanden habe, ist ja die Box selbst tatsächlich erreichbar, d.h. die Freigabe von 492 als HTTPS-Port funktioniert auch wirklich und damit fällt auch die Frage einer falschen WAN-Adresse weg.

Könntest Du mal in der ar7.cfg (Sicherung oder Support-Daten) nach dem Abschnitt mit der Konfiguration der "brinterfaces" schauen und den hier einstellen? Allerdings nur dann, wenn die eingehenden Pakete tatsächlich im Mitschnitt für "lan" nicht auftauchen sollten.

 

[knilix]

Dann würde ich tatsächlich wie skizziert vorgehen und über die Paketmitschnitt-Möglichkeit der FRITZ!Box ("1. Internet-Verbindung" und "lan" parallel aufzeichnen) mal nachschauen, ob die Pakete auf der FRITZ!Box bereits versanden oder doch noch ins LAN gelangen.

Hab über die Capture Version nun mal die beiden Schnittstellen aufgezeichnet, mir Wireshark installiert und ich versteh ziemlich genau Bahnhof Hier hört leider mein Verständnis auf. Ich seh eine viele Einträge in beiden Dateien welche ich über die IPs irgendwie in Zusammenhang bringen kann.

Nach was muss ich schauen?

Hier noch der Auszug aus der "brinterfaces" aus der Support Datei:

brinterfaces {
name = "lan";
dhcp = no;
ipaddr = 192.168.10.1;
netmask = 255.255.255.0;
dstipaddr = 0.0.0.0;
interfaces = "eth0", "ath0", "ath1", "wdsup0", "wdsup1",
"wdsup2", "wdsup3", "wdsup4", "wdsdw0",
"wdsdw1", "wdsdw2", "wdsdw3", "wdsdw4";
dhcpenabled = yes;
dhcpstart = 192.168.10.100;
dhcpend = 192.168.10.175;
no_dnsd_static = no;
is_guest = no;
is_hotspot = no;
multicast_snooping = yes;
} {
name = "lan:0";
dhcp = no;
ipaddr = 169.254.1.1;
netmask = 255.255.0.0;
dstipaddr = 0.0.0.0;
dhcpenabled = yes;
dhcpstart = 0.0.0.0;
dhcpend = 0.0.0.0;
no_dnsd_static = no;
is_guest = no;
is_hotspot = no;
multicast_snooping = yes;
} {
name = "guest";
dhcp = no;
ipaddr = 192.168.179.1;
netmask = 255.255.255.0;
dstipaddr = 0.0.0.0;
interfaces = "guest4", "guest5", "guest_ct*", "guest_st*";
dhcpenabled = yes;
dhcpstart = 0.0.0.0;
dhcpend = 0.0.0.0;
no_dnsd_static = yes;
is_guest = yes;
is_hotspot = no;
multicast_snooping = yes;
}

 

[PeterPawn]

Ok, die Frage nach den brinterfaces zielte darauf ab, ob da event. das (auch erst später irgendwann dazugekommene) Gastnetz an LAN4 event. aktiviert ist und der Switch dann an LAN4 steckt. Das würde ggf. nicht sofort auffallen (hängt von den Internet-Diensten ab, die von den LAN-Clients genutzt werden) und da wäre dann kein eingehender Verkehr (ins Gastnetz) machbar. Leider ist das bei der 7390 nicht so deutlich zu sehen in der ar7.cfg, wie bei den VR9-Modellen (wo die einzelnen eth-Ports aufgeführt sind).

In dem Paketmitschnitt von der externen Schnittstelle müßtest Du ja ein eingehendes Paket (TCP/SYN) für die öffentliche IP-Adresse der FRITZ!Box mit dem fraglichen Port als Ziel sehen können, Absender ist der verwendete externe Client mit irgendeinem zufälligen Port. Wenn schon das Paket nicht ankäme, wäre es wieder ein externes Problem ... die Box kann eben nichts weiterleiten, was bei ihr (warum auch immer) nicht ankommt. So ganz simpel und "gewöhnlich" kann ja Deine WAN-Konfiguration auch nicht sein, wenn Du von einer statischen Adresse auf dieser Seite schreibst (oder ich habe es falsch verstanden).

Hast Du ein solches Paket identifiziert, müßte es - mit genau derselben Absenderadresse und auch demselben Port (vom Absender) - auch im Mitschnitt auf der LAN-Seite zu sehen sein, jetzt aber nicht mehr mit der öffentlichen IP der FRITZ!Box als Ziel, sondern mit der internen Adresse des betreffenden Hosts (und ggf. dem geänderten Port, wenn da kein 1:1-Mapping erfolgt). Ist dieses Paket nicht zu finden, hat es die FRITZ!Box ihrerseits verschluckt.

Bis zu diesem Punkt würde ich erst einmal testen ... wobei es sich m.E. jetzt etwas weiter vom Thema der Firmware-Version entfernt und ich Dir vorschlagen würde, das in einen eigenen Thread zu verlagern ... der kann dann auch einen aussagekräftigeren Titel erhalten und wird von anderen mit ähnlichen Problemen in Zukunft dann auch noch leichter gefunden.

 

[knilix]

Hallo,

danke fürs Abtrennen bzw. das erstellen eines extra Threads.

So wie es aussieht, liegt es wohl nicht an der Fritzbox oder der OS Version. Hab eine andere Fritzbox vom gleichen Modell, aber mit älterer Software probiert. Gleiche Config eingespielt.

Ebenfalls habe ich in der Zwischenzeit eine komplett neue FB gekauft und auch mit dieser ändert sich das Verhalten nicht.

Anruf der Buisness-Hotline der Telekom hilft auch nicht weiter...geben keinen weiteren technischen Support, wenn kein Router der Telekom zu Einsatz kommt. Diesen habe ich nun bestellt, wird wohl ein Zyxel. Ich bin gespannt.

Sonst das übliche, Leitung geprüft und OK, Telefonie usw. und Internetzugang klappt ja weiter.

Ich bin ratlos...

 

[Ganzfix]

So wie es aussieht, liegt es wohl nicht an der Fritzbox oder der OS Version. Hab eine andere Fritzbox vom gleichen Modell, aber mit älterer Software probiert. Gleiche Config eingespielt.
Ebenfalls habe ich in der Zwischenzeit eine komplett neue FB gekauft und auch mit dieser ändert sich das Verhalten nicht.

Hast du denn die Konfiguration mal komplett manuell neu eingegeben? Wenn der Fehler irgendwie doch an der Konfiguration liegt, könnte der Fehler natürlich auch bei einem anderen Modell auftreten.

Es könnte sich also um ein KKK (Klassisches Konfigurations-Kuddelmuddel) handeln. Um einen definierten, sauberen Zustand eines Routers zu erreichen, ist ein PoR gefolgt von einem Werksreset mit anschließender Neueingabe der Konfiguration sehr zu empfehlen.

PoR (Power On Reset) damit meint man einen Reset durch die Stromlosmachung des Routers für mindestens 1 Minute. Empfohlen werden aber mindestens 5 bis 15 Minuten. Dabei sollen alle Kabel einschließlich Netzteil, USB, Telefon etc. abgezogen werden, sodass der Router losgelöst, frei und unverkabelt ist.

 

[knilix]

Hallo,

ja die Einstellungen wurden jeweils komplett von Hand neu eingetragen. Selbes Problem bestand bei der original verpackten Fritzbox.

Inzwischen habe ich auch die Rückmeldung von AVM, dass die Konfiguration in Ordnung ist und funktionieren muss.

 

[PeterPawn]

Verrätst Du uns noch, was die Auswertung des Packetdumps ergeben hat (wenn Du sie vorgenommen hast)? Kommt da nun ein Paket auf der FRITZ!Box an? Wenn die Suche jetzt vor der FRITZ!Box weitergeht, würde man ja auf "nein" tippen ... aber es würde späteren Lesern sicherlich helfen, wenn der Grund für diese Verlagerung der Suche erkennbar wäre - denn wenn ich es richtig verstehe (auch ich bin ja aufs "Interpretieren" des hier Geschriebenen angewiesen), geht es ja jetzt weg von der Vermutung, es hätte mit der FRITZ!OS-Version oder der FRITZ!Box-Konfiguration zu tun.

Wenn das nicht der Fall ist, wäre wohl auch das Update kaum die Ursache und dann ist der komplette Thread-Titel irreführend. Um anderen (mit ähnlichen Problemen) da eine Unterscheidung zu ermöglichen, wäre es schon wichtig, die neu gewonnenen Erkenntnisse und die Schlußfolgerungen daraus auch hier aufzuführen.