[Problem] Fritzbox vergisst(?) seit neuestem Portfreigaben

[daubsi]

Hallo,

ich habe seit etwa 10 Tagen nach der Umstellung von DSL16 auf VDSL100 (1&1/Telekom) folgendes Problem:

Die FB agiert bei mir eigentlich nur als "dummer Router". Alle Dienste, die ich ins Internet anbieten möchte, kommen von einem nachgelagerten Server, den ich auf der FB als "Exposed Host" angegeben habe. Diese Config fahre ich seit Jahren ohne Probleme!

Nun kommt es ca. 3-4x pro Woche zu folgendem Fehlerbild. Fritzbox loggt, "DSL antwortet nicht" und verbindet sich neu.
Die Internetzugriffe sind auch nach dem Reconnect so schnell wie sie sein sollen (knapp 95MBit). Ich bin von aussen telefonisch erreichbar (= Incoming SIP funktioniert) ABER, alle meine Dienste sind aus dem Internet nicht mehr erreichbar! Ich bekomme beim Versuch auf 22, 443, etc. zuzugreifen sofort einen "Destination host unreachable" von der Fritzbox an die Adresse ins Internet.
Von "Innen nach Aussen" funktioniert alles top! Ich habe die volle VDSL Geschwindigkeit. Lediglich die eingehenden (und extern inittierten) Verbindungen sind beeinträchtigt.
Sobald ich einen DSL Reconnect über die FB Oberfläche einleite, ist der Spuk vorbei und alles ist sofort wieder erreichbar!

Fritzbox 7390, Firmware 06.83, an Broadcom 177.173, VDSL2 17a G.Vector (ITU G.993.5) Line-ID: 1UND1.DEU.DTAG.AOCV2

Die DSL Reconnects sind zwar nervig, aber an sich ja kein Problem, wenn danach wieder alles geht. Es scheint jedoch als würde sich die FB "verschlucken" und vergessen, dass sie die Pakete an den Exposed Host schicken muss. Nach einem DSL Reconnect geht es dann wieder!

Die Tests zur Analyse erfolgten von einem Root Server eines Bekannten aus dem Internet. Bei den "Port probes" habe ich es mehrfach gemacht, damit ich nachher im PCAP auch was finde.
Meine Anfrage beim AVM Support hatte erstmal die "Standardantworten" zur Folge: Anderes Kabel probieren, Störabstand hochsetzen usw. Aber die Probleme haben m.E. damit gar nichts zu tun, denn wie oben geschrieben, geht "im Grunde" alles einwandfrei, full speed und man sieht in den Captures glasklar (siehe Screenshots am Ende des Post), dass der "Destination host unreachable" von der FB gesendet wird. (Der "Destination Host" 192.168.0.1, der als exposed Host eingetragen ist, ist selbstverständlich "reachable"!). Zumal dass es nach einem DSL Reconnect sofort wieder alles geht!

Die Tests erfolgten von der IP 136.243.xx.xx.

[~] daubsi@fex $ ping server.home.xxx.xxx

PING server.home.xxx.xxx (217.84.211.205) 56(84) bytes of data.

64 bytes from pD954D3CD.dip0.t-ipconnect.de (217.84.211.205): icmp_seq=1 ttl=57 time=28.9 ms

64 bytes from pD954D3CD.dip0.t-ipconnect.de (217.84.211.205): icmp_seq=2 ttl=57 time=29.3 ms

64 bytes from pD954D3CD.dip0.t-ipconnect.de (217.84.211.205): icmp_seq=3 ttl=57 time=29.1 ms

64 bytes from pD954D3CD.dip0.t-ipconnect.de (217.84.211.205): icmp_seq=4 ttl=57 time=28.9 ms

64 bytes from pD954D3CD.dip0.t-ipconnect.de (217.84.211.205): icmp_seq=5 ttl=57 time=29.1 ms

…

…

^C

--- server.home.xxx.xxx ping statistics ---

76 packets transmitted, 76 received, 0% packet loss, time 75017ms

rtt min/avg/max/mdev = 28.745/29.146/29.586/0.288 ms

[~] daubsi@fex $ nc server.home.xxx.xxx 4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx 4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx4444

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx 443

Ncat: No route to host.

[~] daubsi@fex $ nc server.homexx.xxx 143

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx25

Ncat: No route to host.

[~] daubsi@fex $ nc server.home.xx.xxx 22

Ncat: No route to host.

Dann habe ich auf der FB die Packet Captures von den folgenden Interfaces gezogen: „Erste Internetverbindung“, „Schnittstelle0_internet“, „Schnittstelle1_mstv“, „Routing_Schnittstelle“ und „NIC_vdsl“. Alle zeigen übereinstimmend, dass die Pakete von aussen an der FB ankommen, aber diese dann mit "Destination host unreachable" antwortet. Beim Packet dump an der internen LAN Schnitstelle sieht man keine Pakete für die entsprechenden Ports. Der "ICMP Destination host unreachable" kommt also wirklich von der FB und nicht von einem hinterliegenden Rechner.

Ist jemandem dieses Problem schon mal begegnet und hat eine Lösung?

//edit by stoney: [CODE] Tag [/CODE] gesetzt

 

[Xeno24]

Hi,

habe seit langem ebenfalls exakt das selbe Problem. Sehr nervig. Vor ein paar Monaten habe ich zu dem Problem noch garnichts im Internet gefunden. Nun, nach einer neuen Suche, immerhin mal deinen Beitrag. Das PRoblem ist also bei mir nicht Einzelfall.
Ich habe mir ein wenig beholfen, indem ich die Fritzbox an eine Zeitschaltuhr gehängt habe. Damit mache ich einmal am Tag den Strom für eine Minute weg und dann wieder ran. Damit tritt das Problem deutlich seltener auf. Leider tritt es alle 1-3 Wochen immernoch ab auf. Es ist also nicht ganz weg, sondern nur seltener.
Hast du zufällig mittlerweile eine Lösung oder dauerhaften Workaround gefunden? Scheint mir ein Bug in der Software zu sein. Mit meiner alten Fritzbox (DSL16) hatte ich das Problem nicht.

Grüße
Xeno

 

[NDiIPP]

Fritzbox 7390, Firmware 06.83

Die Betaversion 06.84-55355 behebt dieses Problem vielleicht:
http://download.avm.de/fritzbox/beta/wartung/

Internet:
- Behoben - Bei Portfreigaben ändert sich sporadisch der externe Port
- Behoben - kein Hinzufügen von IPv4-Portfreigaben für Geräte mit IPv4 und IPv6 an Internetanschlüssen ohne IPv6

 

[HabNeFritzbox]

Schaut mal unter Sicherheit, ob die Freigabe dort noch gelistet ist.

Schickt an AVM sonst mal ein Ticket samt Support Datei.

Weiß nicht wieso man unbedingt nicht benötigte Ports weiterleiten lassen möchte.

Mit konkreten Freigaben habe ich seit Jahren keine Probleme. Und wenn Freigaben ständig wechseln könnte man auch selbstständige Freigaben zulassen für das Gerät wie z.B. eine X-Box.

 

[Xeno24]

Hast die Beta schonmal ausprobiert?

Ich nutzte exposted Host damit ich nicht bei jedem Test gleich was neu in der Fritzbox konfigurieren muss. Ich arbeite in der IT. Da testet man oft . Für alle immer von hand in der Fritzbox weiterletien zu müssen wäre sehr umständlich. Deshalb gibts ja die Funktion Exposed host.

Ich hab jetzt mal probiert zusätzlich zum Exposted Host noch eine Freitgabe explizit für POrt 22 zu machen. Die greift dann zuerst. Musste dazu aber auf dem nachgelagerten Gerät eine zweite IP definieren, da auf die slebe IP die Fritzbox nicht zulässt. Mal sehen, ob ich im Fehlerfall auf diese Freigabe dann noch draufkomme. <Damit könnte ich dann das PRoblem immerhin manuell aus der Ferne beheben (Fritzboxreboot). Aktuell bin ich für 24 STunden ausgesperrt, wenn das PRoblem wiedermal auftritt..

Xeno

 

[NDiIPP]

Hast die Beta schonmal ausprobiert?

Dazu müsste ich eine 7390 haben die ich als Router betreibe. Warum testet du das nicht?

Vor einiger Zeit hatte ich das Problem jedenfalls mal mit der Firmware 6.80 und 6.83, das Problem war imo auch bekannt und wurde mit neueren Firmwareversionen behoben (mit Ver. 6.90) welche es aber für die 7390 nicht gab.
Nun gibt es eben (endlich) diese "Wartungsversion" 6.84 für die 7390 die vielleicht auch dieses bekannte Problem mit den Portfreigaben über das neue PCP-Protokoll behebt:
https://www.ip-phone-forum.de/threads/fb7390-portfreigaben-schliessen-sich-selbstständig.296841/

 

[stoney]

Ich könnte bei wirklich erkennbarem Bedarf (vll kann/will @PeterPawn seine Expertiese zu dem vorliegenden Fall bzw zu den zweien, wovon ich nicht überzeugt bin, damit bei Fall #2 genau das selbe Problem mit dem selben Eigenleben zu 100% im Setup sowie mit identischen Konfigurationen und Netzwerkgeräten ganz zufällig genau so auf noch einer zweiten F!B 7390 identisch vor sich hin werkelt, zum Besten geben)
eine oder auch zwei 7390 mit beiden FW Versionen auf die geannten Probleme testen, allerdings fehlt bei beiden Frageposts die nicht unrelevanten Screenshots des Menüpunktes "Internet > DSL-Informationen" von Übersicht und DSL.

Da die 7390 eher in der Theorie als in der Praxis mit einem VDSL2 Vectoring Profil zufriedenstellend zurecht kommen soll

Spoiler: OT war schon im Eifer getippt und war mir zu schade es zu löschen

was man die letzten Jahre noch so über die 7390 als Neuigkeiten kommunizierte, war es in allen anderen Bereichen der 7390 bis auf die nicht jedem bekannte DECT-Repeaterfunktion oder dem HW-TOT der immer wieder abrauchenden üblichen Verdächtigen Bauteile der 7390 Platine, welche einem so lange und treu gedient hat und welche eines Frühs mit einem komischen, immerwiederkehrenden gleichen Blinkverhalten der LEDs, eine Bootschleife signalisiert, da beim initialisieren des Treibers des/eines defekten Bauteils mit dem Fehler des nicht starten könnens des ersten dadurch nicht funktionsfähigen Controllers (je nach Defekt, ist die Lichtorgel unterschiedlich im Verhalten) hängt und was man da, ggf. wie machen kann, wenn man die Hoffnung hat, das bis dato treue Gerät wieder auf die "Beine" bekommen kann und was es diesbezüglich dann an Einschränkungen geben kann/wird.

müssen diese Daten zu den jeweiligen Problem-Anschlüssen bekannt sein.
Um

Beide Fälle vergleichen zu können, da es ja schon den ein oder anderen Post bezüglich solcher/änlicher Probleme gab, kann man ja ggf aus einem schon existierenden Beitrag mit ähnlichen Problemen und den nötigen angehängten Infos, eine Verbindung mit diesen hier herstellen und erst mal ohne (vieleicht) unnötige Tests Dritter dem Problem bei der doch in die Tage gekommenen 7390, welche ihre besten Jahre hintersich und von AVM zum sterben verurteilt wurde (beim hinzufügen auf die EOS/EOL Liste der Berliner) auf die Schliche zu kommen.
​

Ich wollte eh mal aus Spaß und Neugierde eine 7390 an meinem Anschluss nach Upgrade von 50k VDSL > 100k VVDSL testen um mir selbst das Verhalten dieser i.V.m. Vectoring selbst anzuschauen/testen, bislang habe ich davon auch nur gelesen.

BTW: gab es bislag Berichte über die 7390 an einer Broadcom 176.29 mit aktivem Vectoring?

 

[Vanisch1]

Ich habe dieses Problem auch, dass ich nach einem ipwechsel nicht mehr mit meiner dynamischen Adresse auf meine mycloud komme.

Ich muss dann erst in die Fritzbox, freigaben, dyndns und dann neu speichern.
Werde die neue Firmware mal testen.

 

[Xeno24]

Leider scheint es die neue Version noch immer nicht als Stable zu geben. Die Fritzbox meldet noch immer, dass meine v06.83 noch die neueste Version wäre.
Ich habe aber mal spaßeshalber zusätzlich zum Exposed Host noch eine manuelle Freigabe (nur für SSH auf das selbe Ziele) hinterlegt. Ich hatte die Hoffnung, dass sobald der Fehler wieder auftritt dann wenigstens noch die manuelle Freigabe funktioniert. Bisher ist das Problem aber nicht mehr aufgetreten. Ggf. wäre das also ein Workaround. Man muss aber tricksen, da man als Zielgerät für die Freigabe nicht die selbe IP wie für den schon existierenden Exposed Host verwenden kann. Ich habe mir also einfach auf meinem Ziel eine zweite IP (IP-Alias) angelegt.

 

[NDiIPP]

Leider scheint es die neue Version noch immer nicht als Stable zu geben. Die Fritzbox meldet noch immer, dass meine v06.83 noch die neueste Version wäre.

Vielleicht wäre es stattdessen ergiebiger auf Godot zu warten?

 

[JWiemann01]

Vielleicht wäre es stattdessen ergiebiger auf Godot zu warten?

Der ist aber auch nicht gekommen


Gesendet von iPhone mit Tapatalk

 

[NDiIPP]

Ach...

 

[daubsi]

Hallo,

zunächst: danke für die vielen Antworten! Ich habe jetzt erst per Zufall gesehen, dass es Antworten gibt! Hatte die ersten Wochen immer mal geschaut, aber da gab es noch nichts und irgendwie kam IMHO gestern die erste Notification Mail...

Daher bitte ich um Nachsicht, das ich bislang also mich nicht mehr gemeldet habe...

Das ist ja hochinteressant, dass ich nicht der Einzige mit dem Problem bin... Ich hatte schon befürchtet, da wäre was ganz böse verkonfiguriert an meiner Home IT. Ich bin auch in der IT tätig, und bastel immer mal gerne rum ;-)

Was hat sich bei mir getan:

Also: Zunächst kann ich sagen, dass das Problem offenbar nicht auf die 7390 beschränkt ist! Ich habe die Providerbox FB4612 nun drangehangen und habe dort das gleiche Verhalten beobachten können. Die DSL Discos sind seitdem weitaus seltener und ich habe einen besseren DSL Sync. Hin und wieder kommt es aber dennoch vor, dass ich Discos habe (Meistens dann gleich 2h in Folge alle paar Minuten - zumindest i.d.R. Nachts), und jedesmal schlägt mein Alarm zu, dass die Ports von Aussen nicht erreichbar sind!

Ich habe mir inzwischen so geholfen, dass ich auf meinem Root-Server bei einem kommerziellen Anbieter ein PHP Script angelegt habe, was einen socket Connect zu Port 22 zu Hause aufmacht und entsprechend OK/ERROR etc. zurückmeldet. Dieses Script auf dem Remote-Server wird alle 10min von meinem Homeserver aufgerufen und das Ergebnis ausgewertet. Tritt mehrmals in Folge ein ERROR auf, dann wird über einen REST API Call ein Reconnect der FB ausgelöst und danach geht es wieder. Ist eine arge Bastelei, aber funktioniert einwandfrei und seitdem ist das Thema für mich auch nicht mehr wirklich ein Problem...
Ich hänge das Script mal an diesen Post an, vlt. kann es jemandem helfen oder inspiriert zu einer professionelleren Lösung.

Zu den Fragen aus dem Thread:

"
Schickt an AVM sonst mal ein Ticket samt Support Datei.

Weiß nicht wieso man unbedingt nicht benötigte Ports weiterleiten lassen möchte.

Mit konkreten Freigaben habe ich seit Jahren keine Probleme. Und wenn Freigaben ständig wechseln könnte man auch selbstständige Freigaben zulassen für das Gerät wie z.B. eine X-Box.
"

Hatte ich hier im Post nicht erwähnt, aber natürlich habe ich bei AVM einen Call aufgemacht. Der Mitarbeiter hat mich aber nur das übliche "Stecken sie mal das Kabel neu" machen lassen und sich für meine Diagnose nicht interessiert. Als ich ihm dann eigenständig meine Ergebnisse und PCAPs/Screenshots geschickt habe, war er ganz irritiert und meinte nur "Das habe ich doch gar nicht angefragt, wieso schicken sie mir sowas" und "So oder so, die FB7390 ja eh alt ist und Updates wirds eh nicht mehr geben" (sinngemäß). Das war das erste Mal, dass ich so eine unbrauchbare (und im Wortlaut auch noch deutlich) flappsigere Reaktion von AVM bekommen habe und habe auch ein entsprechende Bewertung hinterlassen.

Warum man das möchte? Lernen! Wie Xeno24 bin ich auch in der IT tätig und habe hinter der FB eine "richtige" L7 FW eines namhaften Herstellers stehen, die bei mir den Zugang ins Heimnetz regelt. Dabei geht es nur zum Teil um einen "besseren" Schutz ggü der FB, sondern vor allem auch, dass man da am Puls der Zeit der Technik bleibt und sich mit den Produkten auseinander setzt. Die FB sitzt sozusagen "vor" meinem Netz und macht nicht mehr als den PPPoE Connect und das VoIP (das lege ich ggf. auch nochmal hinter die Firewall mit einer zweiten FB und einer Koppelung).

Interessant finde ich nun also, dass das Problem offenbar nicht auf die 7390 beschränkt ist, sondern auch bei der 4612 auftritt. Vielleicht somit ein modell-unabhängiger Bug in FritzOS? Das Problem hat sich bei mir immer nur dann gezeigt, wenn die DSL Verbindung von aussen terminiert wird (also durch irgendwelche Netzprobleme o.ä.), aber nie, wenn die FB von sich aus z.B. den täglichen nächtlichen Reconnect macht.

 

[PeterPawn]

dann wird über einen REST API Call ein Reconnect der FB ausgelöst

Ehe am Ende jemand verwirrt ist, zwei "Korrekturen" (oder "Bemerkungen") meinerseits ... das TR-064-Interface (auch IGD/IGD2 gehört irgendwie dazu, wurde/wird zumindest von demselben Gremium "verabschiedet") hat eigentlich mit "REST" (als Architektur-Ansatz) gar nichts zu tun (HTTP verwenden auch noch andere (echte) Protokolle oder Interfaces und in diesem Falle ist es eben TR-064 als Standard mit SOAP als Protokoll) und eine FRITZ!Box 4612 gibt es auch nicht wirklich, auch wenn diese gleich zweimal erwähnt wird (was den einfachen Tippfehler unwahrscheinlicher werden läßt) - vermutlich ist die FRITZ!Box 7412 gemeint.

 

[daubsi]

Beides korrekt - sorry ;-)
Man sollte nur eine Sache zugleich machen...

 

[NDiIPP]

Vielleicht somit ein modell-unabhängiger Bug in FritzOS?

Nicht nur vielleicht, der Bug ist doch imo schon lange bekannt (auch schon vor dem 26. März 2018) bei den 6.8xer Versionen wo doch das PCP-Protokoll für Portweiterleitungen erst eingeführt wurde, vgl. dazu auch die entsprechenden Changelogs (dürfte ja für einen ITler eigentlich kein Problem sein):

Ausschnitt aus https://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/info_de.txt,
https://download.avm.de/fritzbox/fritzbox-7560/deutschland/fritz.os/info_de.txt,
https://download.avm.de/fritzbox/fritzbox-7580/deutschland/fritz.os/info_de.txt oder auch
https://download.avm.de/fritzbox/fritzbox-7590/deutschland/fritz.os/info_de.txt:

# Weitere Verbesserungen im FRITZ!OS 6.90
[...]
- **Behoben:** PCP-Portfreigaben konnten sich sporadisch verstellen
[...]

edit
Und auch in den 6.84er Wartungsbetas wird im Changelog ein behobenes Problem bezüglich Portweiterleitung erwähnt, siehe schon Beitrag #3. Warum probiert eigentlich bis jetzt von den betroffenen keiner diese Firmware aus?

Das Problem hat sich bei mir immer nur dann gezeigt, wenn die DSL Verbindung von aussen terminiert wird (also durch irgendwelche Netzprobleme o.ä.), aber nie, wenn die FB von sich aus z.B. den täglichen nächtlichen Reconnect macht.

Dabei ist nicht (nur) zwischen "innen" und "außen" zu unterscheiden sondern auch zwischen einem DSL-Resync und einem PPPoE-Reconnect.

Interessant finde ich nun also, dass das Problem offenbar nicht auf die 7390 beschränkt ist, sondern auch bei der 4612 auftritt.

Was soll das für eine Box sein? Ein einfacher Zahlendreher kann das doch schon nicht mehr sein... Eine 7312 kannst du damit imo nicht meinen da diese aufgrund der alten Firmware von diesem Bug imo nicht betroffen ist (und auch kein VDSL unterstützt)...Vielleicht eine 7412? Wenn ja, für die gibt es mittlerweile auch eine 6.84er "Wartungsbeta" die es auszuprobieren lohnt (und dank Dualboot bei der 7412 sogar relativ gefahrlos).

 

[daubsi]

Hallo,

kurzes Update. Habe inzwischen seit mehreren Wochen die "06.84-55354 PLUS" für meine 7412 drauf. Heute ist das Problem mit den beschriebenen Konsequenzen erneut aufgetreten.
Die Beta-Firmware scheint das Problem also nicht behoben zu haben.

 

[Vanisch1]

Vollzitat entfernt by stoney

Auch bei mir seit kurzem wieder das gleiche Problem. Port wird einfach geändert.

 

[tobmaster1985]

Bei mir trat das Problem dieses Wochenende erst wieder auf, FW ist die 6.85.

Mal sehen welche Antworten ich vom AVM "Support" erhalte...

Offenbar hat sich AVM dem Trend anderer Hersteller angeschlossen und hat seit der 6.80er die Software eher schlechter, als besser gemacht..

 

[Guitarrero]

Ich muss das Thema nochmal hochschieben. Selbst in der 7.01 Firmware auf der 7490 mit 1und1 als Provider trifft mich das Problem jetzt vermehrt.
Bei einem normalen 24 Stunden reconnect läuft alles ohne Fehler aber sobald beim reconnect mal PPOE Fehler dabei ist, entfernt er meine Portweiterleitung, dann erstellt er sie neu aber vertauscht Ports intern mit extern.
Ich war vorher bei der Telekom und hatte das Problem nie. Wahrscheinlich weil sie den 24 Stunden reconnect nicht mehr haben.