FRITZ!Box 7390 Labor-Firmware Version 06.36-32422 vom 12.02.2016

[mattberlin]

Ja mei, und wenn der 1und1-Code nicht geht, dann konfiguriert man eben manuell.

 

[andreas_c]

Meine Box läuft mit 1&1 DSL und VoIP ohne Probleme.

 

[gsm_bts]

Hallo,
nachdem ich dem AVM Support 2x die Support-Daten geschickt hatte (siehe #11), habe ich eine spezielle Firmware von denen bekommen. Wahrscheinlich auf Basis der 6.36-32422 mit "1und1" und "otwo" im Namen. Meine 7390 ist ja ursprünglich von 1&1, aber seit ca. 2 Jahren bin ich bei der Telekom und die lief damit auch bisher 1a! Auch VoIP mit der Telekom ging ohne Probleme.
Leider hat sich bei mir auch mit dieser speziellen Beta-Firmware das Fehlerbild nicht geändert: nach ca. 6h ging kein Internet mehr, bzw. kam im Browser "..nicht erreichbar". Zugriff auf die Box nur per IP-Adresse möglich und dort waren alle Verbindungen ins Internet "grün", aber es ging definitiv (LAN & WLAN) nichts mehr! Ich habe dann wieder vor dem Stecker-ziehen die Support-Daten abgezogen und nachher AVM geschickt. Da sind noch einige Hausaufgaben zu machen!
Was ich auch noch festgestellt habe ist, dass in der DSL-Übersicht bei "Spektrum" kein Upload-Bereich (normalerweise grün) dargestellt wurde! Upload war aber vorhanden und bei meinem Annex J mit ca. 2 Mbit/s im erwarteten Rahmen (bei 5,6 Mbit/s im Downlink). Ist sicher nur ein Schönheitsfehler!
Bevor Anfragen zu der Firmware kommen: AVM bat mich diese Beta-Version nicht weiterzugeben und das werde ich auch respektieren.
Mich wundert nur, dass kein anderer User das Problem hat
Meine Box hat die AVM Art.-Nr. 2000 2470 und ist schwarz...
Ich bin jetzt jedenfalls wieder per Recovery auf die 6.30 zurück und habe die Sicherung wieder eingespielt.

 

[Resistor]

Ich kann mir im Zusammenhang mit dem von mir beobachteten Phänomen
der nicht möglichen Einrichtung der 1&1-VoIP-Telefonie vorstellen, dass
voll funktionierende Fritzboxen mit Software 6.30 nach Updates mit Betas
zwar weiter einwandfrei funktionieren, aber eben nicht, wie von mir beobachtet,
wenn eine nie in Betrieb gewesene Box von einer sehr frühen Software-Version
gleich auf die aktuelle Beta geflasht wird und auch vorher keine Zugangsdaten für
Internet und Telefonie enthielt.
Wie ja auch manche geupdateten Boxen erst wieder sauber laufen, wenn man
ein Werksreset durchführt und alle Daten neu eingibt.

bis denn, BEN

 

[amatör]

Mich wundert nur, dass kein anderer User das Problem hat

Ich habe erhebliche Probleme mit dem DNS, die auch nach einem Reset weg sind. Namenauflösung funktionieren mal, mal nicht oder bekommen einen Timeout. Bisher hat sich die Familie gelegentlich mit einem Reset der Fritzbox beholfen. Nachdem ich heute etwas Zeit hatte und das Problem auch wieder auftrat, bin ich auf dieses DNS-Problem gestoßen.

Da ich erst an allgemeines Konfigurationsproblem bei mir glaubte, hatte ich es zuerst hier gepostet.

Was meinen Verdacht aber nun auf die Fritzbox lenkt, ist die Tatsache, dass DNS-Anfragen für dieselbe Domain einen Timeout bekommen, die kurz zuvor noch beantwortet wurde. Sieht so aus als verrennt sich die Fritzbox mit ihrem DNS-Cache oder so.

Alternativ zu einem Box-Reset scheint auch das Ändern der DNS-Einstellungen zu helfen. Danach läuft es erst mal wieder (egal was genau ich ändere). Vielleicht probierst du das auch mal? Keine Ahnung, ob unsere Probleme zusammenhängen, aber ich könnte es mir vorstellen.

Ach ja: ich habe eine Standard-7390 aus dem Handel (also keine UI).

 

[peter_altherr]

Bei meiner (ungebrandeten) 7390 im IP-Client-Betrieb tritt das gleiche Verhalten auf. Nach ein paar Stunden Betrieb legt sich die DNS "schlafen". Zugriff auf die Box per Eingabe der lokalen IP geht und nach einem Neustart über die WebGUI läuft auch alles wieder normal für ne Weile. Die vorherige Beta hatte dieses Verhalten nicht.

 

[amatör]

Welche DNS-Server bei dir? Ich habe es mal per Feedback gemeldet.

 

[erik]

... 7390 im IP-Client-Betrieb ... DNS ...

Da komme ich nicht mit. Beim Betrieb als IP-Client hat doch die Box mit DNS nichts zu tun und der Zugriff erfolgt sinnvollerweise immer über die IP:gruebel:

 

[peter_altherr]

Im WebGUI der 7390 kann ich an zwei Stellen DNS-Server angeben, unter:

1. Internet - Zugangsdaten - Reiter Internetzugang - Verbindungseinstellungen. Da steht bei mir als primärer DNS-Server 192.168.178.1 und als Sekundärer 8.8.8.8.

2. Internet - Zugangsdaten - Reiter DNS-Server. Da steht bei mir für IPv4 die 8.8.8.8 und die 8.8.4.4 und für IPv6 die 2001:4860:4860::8888 und die 2001:4860:4860::8844

Mit diesen Einstellungen gab es bis zur in diesem Thread besprochenen FW keine Probleme und die hier zickt rum.

 

[Joe_57]

Setz die Optionen doch mal auf die empfohlene Einstellung zurück.
Vielleicht mag die Labor-Version ja keine Google-Server. :noidea:

Joe

 

[thtomate12]

Die Einträge in dem zusätzlichen Tab sollten gewinnen, an die anderen Einträge kommt man nur bei einer statischen IP-Adresse dran.
Wieso kümmerst du dich um DNS an dem IP-Client?

 

[erik]

Ich schreibe bei den beiden DNS-Einträgen immer zwei mal die IP des Routers rein, dann nutzt die Fritzbox nach dem Übernehmen nur den einen DNS-Server.
Wenn man 0.0.0.0 als zweiten DNS schreibt wird das nicht so übernommen.

 

[Riverhopper]

2. Internet - Zugangsdaten - Reiter DNS-Server. Da steht bei mir für IPv4 die 8.8.8.8 und die 8.8.4.4 und für IPv6 die 2001:4860:4860::8888 und die 2001:4860:4860::8844

nur mal ne Verständnisfrage, wozu benötigstst man bei der FritzBox im IP-Client-Mode eine DNSv6 Namensauflösung ?

eine IPv6-Configuration macht bei einer FritzBox im IP-Client Mode IMHO nur dann Sinn, wenn man von Außen auf die Box zugreifen will, d.h. beim Hauptrouter eine IPv6 Freigabe auf die IP-Client FB, alternativ "MyFritz IPv6 Portforwarding" auf die IP-Client-FB, eingerichtet hat oder haben will.

nur sehe ich noch keinen Nutzwert für DNSv6 Client-Config bei IP-Client FB ?

LG Riverhopper

 

[peter_altherr]

Ich benötige es eigentlich nicht. Hab halt die Daten dort eingetragen, weil die WebGUI das anbietet. Der Vollständigkeit halber sozusagen.

Werd aber mal probieren, wie sich die Box verhält, wenn ich als DNS auschliesslich die Adresse der Routerbox eintrage.


Update 25.02.16: Änderung des DNS auf die IP der Routerbox hat leider nichts am Verhalten geändert. Clients, die per WLAN an der IP-Client-Box hängen kriegen nach einer Weile keine Namensauflösung mehr.

 

[Blackfire]

Seit dieser Version trennt AVM den IPSec VPN mit meinem Auerswald COMfortel 2600 IP nicht mehr nach einer Stunde, Super.

 

[mattberlin]

Ja, es sind 24000 s, allerdings wurde das schon vor einigen Versionen eingeführt.

 

[PeterPawn]

Ja, es sind 24000 s

Und ich möchte noch darauf hinweisen, daß diese regelmäßigen Schlüsselwechsel im IPSec-Standard ja nicht als Selbstzweck eingeführt wurden (sondern als Maßnahme gegen unerwünschte Lauschangriffe auf der Basis kryptographischer Analysen bei sehr lange verwendeten Schlüsseln oder sehr viel mit demselben Schlüssel bearbeiteten "cipher text") ... somit schwächt die Verwendung ein und desselben Schlüssels für eine lange Zeit (und 8h sind recht lang an dieser Stelle) und/oder eine beliebig große Datenmenge die Sicherheit so einer VPN-Verbindung insgesamt.

Das ist sicherlich für den Konsum von Katzenvideos vom heimischen NAS auch unterwegs noch gar kein Problem ... aber damit degeneriert dann ein VPN nach und nach zu dem, was sich hinter diesem Begriff tatsächlich nur verbirgt - ein "virtuelles privates Netzwerk", bei dem die Aspekte Sicherheit und Vertraulichkeit der übertragenen Daten zunehmend in den Hintergrund treten bzw. unter die Räder geraten.

Wenn man nur auf die generelle Möglichkeit des Zugriffs abstellt und einem diese Gesichtspunkte per se egal sind, kann man auch gleich die FRITZ!Box entsprechend entlasten und durch den Verzicht auf Verschlüsselung den maximal möglichen Durchsatz so einer VPN-Verbindung weiter erhöhen. Den dazu benötigten "Selektor" mit der Bezeichnung "esp-null-sha/ah-no/comp-no/no-pfs" hat AVM sogar in der ipsec.cfg noch vorgesehen - damit lassen sich (zwischen zwei FRITZ!Box zumindest) VPN-Verbindungen einrichten, bei denen jeder auf dem Transportweg der Datenpakete problemlos auch den Inhalt der übertragenen Daten mitlesen kann.

Einen Unterschied zu einer verschlüsselten VPN-Verbindung erkennt man im GUI nicht und selbst mit Shell-Zugang müßte man wohl gezielt danach suchen, damit das auffällt. Zumindest als "Ansatz" für eine "backdoor" würde ich das schon sehen ... denn wer so etwas als Kunde/Nutzer tatsächlich sehenden Auges verwenden will, bräuchte mindestens mal eine "handgeschöpfte" VPN-Konfiguration und wer das auf die Reihe kriegt, der könnte sich auch die passende ipsec.cfg wohl noch selbst basteln. Da wird man sich ja zumindest noch seine Gedanken über den "use case" so eines Eintrags machen und die Frage stellen dürfen, was so ein Selektor in einer offiziell freigegebenen Version 06.51 überhaupt zu suchen hat bzw. wann der vielleicht doch verwendet wird.

Insofern verstehe ich auch AVM nicht so richtig, wenn man dort jetzt I14Y-Probleme auf einem Weg zu lösen versucht, der alles andere als sicher ist ... aber glücklicherweise ist die tatsächliche "life time" so einer "security association" immer noch Verhandlungssache zwischen den beiden Peers und so kann man immer noch darauf setzen, daß die Gegenstelle schon "vernünftiger" ist als eine FRITZ!Box - wenn diese dann auch standardkonform eine kürzere Lifetime akzeptiert und umsetzt, was ich selbst nicht getestet habe.

Das war ja wohl nur im Zusammenspiel mit dem Android-Client überhaupt problematisch, jetzt gilt aber für alle GUI-konfigurierten VPN-Verbindungen für Benutzer, daß dort "LT8h/esp-all-all/ah-none/comp-all/no-pfs" verwendet wird und die Frage, warum da kein PFS zum Einsatz kommen soll, treibt mich ebenso um ... nun kann man offenbar beim avmike keine Mischung aus Proposals mit und ohne PFS konfigurieren (zumindest schlußfolgere ich das aus dem außerhalb des "proposals"-Arrays liegenden "pfs"-Parameter), aber dann muß/sollte AVM eben das auch noch als Auswahlpunkt zur Verfügung stellen im GUI. Jetzt wird jedenfalls wegen bestimmter VPN-Clients die Sicherheit für alle anderen gezielt geschwächt (das hatten wir bei RC4 für TLS beim GUI ab 06.0x schon mal) ... was PFS ist und warum es essentiell für eine (anzunehmende) Sicherheit der Verbindung ist, steht anderswo im Internet oft genug beschrieben.

Wenigstens verzichtet AVM aber darauf, beim Einrichten einer FRITZ!Box-zu-FRITZ!Box-Verbindung sofort auf die 8-Stunden-Selektoren zu setzen ... dort kommt mit dem standardmäßigen "esp-all-all/ah-none/comp-all/pfs" sogar eine Liste von Proposals zum Einsatz, der man weitgehend Beifall zollen könnte (angesichts des Fehlens eines passenden Co-Prozessors und der Balance zwischen Security und Durchsatz), wenn denn da nicht weiterhin DES mit MD5 erlaubt wäre, was auch nicht mehr so richtig zeitgemäß ist.

MD5 ist inzwischen 25 Jahre alt und Kollisionsangriffe darauf sind bekannt - das ist hier genau der Verwendungszweck, der damit angegriffen werden kann (HMAC) ... im Gegensatz zu "preimage attacks", wie z.B. auf die "Urform" eines Kennworts.

 

[The Grinch]

Ist das jetzt für den Normalsterblichen Nutzer einer Fritz!Box überhaupt relevant, muss er sich jetzt einen Aluhut basteln,
oder ist es Jammern auf hohem Niveau?

Ich versteh jedenfalls davon nur Bahnhof, und sehe auch keinen direkten Zusammenhang zu einer Labor-FW und deren Funktion oder deren Fehlern.

 

[mattberlin]

Fakt ist jedenfalls, dass der VPN-Neuaufbau nach 1 h sehr hinderlich ist, wenn man ein Handy als IP-Telefon an der Box betreiben will.

 

[PeterPawn]

@The Grinch:
Zumindest ist es ein "Makel" (in meinen Augen), den AVM in die Firmware eingebaut hat, den man bei einer Labor-Version noch konstatieren kann und den es ggf. zu beseitigen gilt.

@mattberlin:
Das mag für die Verwendung einer VPN-Verbindung für IP-Telefonie tatsächlich zutreffen, wobei der postulierte "Neuaufbau" (und damit eine wie auch immer geartete Unterbrechung selbst eines Telefonats) gar nicht notwendig ist und erfolgen muß, wenn der avmike (meinetwegen in Zusammenarbeit mit dem Client beim Peer, weil der natürlich auch falsch umgesetzt sein kann) in der Lage wäre, die verwendete SA einfach sauber zu erneuern - das machen mehrere andere IPSec-Implementierungen vor.

Aber selbst bei einer Unterbrechung würde wegen eines speziellen Anwendungsfalls einer VPN-Verbindung jede andere VPN-Verbindung (mit 8h Lifetime und ohne PFS) ebenfalls geschwächt. Die naheliegendste (und aufwändigste) Lösung wäre sicherlich die feiner abzustufende Einstellung bei VPN-Verbindungen durch den Benutzer - das machen andere Geräte weitaus besser. Selbst wenn sich dadurch die bisher ziemlich einfache Art und Weise der Einrichtung etwas komplizierter gestalten könnte (nicht muß, denn das würde als Option vollkommen ausreichend sein), ist es erstens ein Armutszeugnis, daß das Rekeying mit Android-Clients so gar nicht klappen will bei AVM (andere kriegen es auch auf die Reihe) und dann zu einer unsicheren Variante zu greifen, ist keine logische Entscheidung und hoffentlich eine, die irgendwann mal überdacht wird.

So wie die Sicherheit von der LAN-Seite wichtiger wurde, weil der Router immer mehr ins Zentrum des Interesses rückt (als Zentrale des Heimnetzes), so wird auch immer öfter aus der Ferne mit Smartphones per VPN auf ihn zugegriffen. Da gehört dann eben eine voll funktionsfähige VPN-Implementierung ins Pflichtenheft und nicht (typischer "agiler" Ansatz) irgendetwas Zusammengewursteltes ... Hauptsache, es funktioniert irgendwie zum Zeitpunkt der "Abgabe". Und wie fragil das Ganze ist und wie schlecht es sich mit wechselnden Versionen von Clients verträgt, wenn man zugunsten eines Anwendungsfalls vom Standard abweicht, konnte man (oder besser kann man immer noch) an den weiterhin bestehenden Problemen mit einigen Android-Versionen und am "54-Minuten-Problem" deutlich sehen.

Insofern gehört für mich auch solche "Fundamentalkritik" zu einem Firmware-Thread und ggf. auch zu einer Labor-Version ... das kann in wechselnden Threads angesprochen werden (und wurde es auch ab und an schon), weil es eben bei allen derzeit aktuellen Versionen entsprechend vermurkst ist. Wenn dann hier festgestellt wird (so die Ursache für das "Super" in #35 tatsächlich die längere Lifetime ist, weil das Telefon sich als IPSec-Client an der Box anmeldet unter einem Benutzerkonto), daß irgendeine Änderung einen positiven Effekt hat/haben soll, muß man auch die anderen Auswirkungen solcher Änderungen aufzeigen dürfen (oder es zumindest versuchen dürfen, vielleicht habe ich es ja auch nur schlecht beschrieben).

Das, was jetzt noch bei einigen dafür sorgt, daß eine VPN-Verbindung (irgendwie) funktioniert, kann beim nächsten Smartphone/Tablet auch jedem, der es jetzt noch begrüßt, auf die Füße fallen, wenn das neue Gerät dann eben wieder standardgemäß arbeitet und mit solchen Kunstgriffen wie dem verfrühten Rekeying bei AVM dann nicht mehr klarkommt oder seinerseits eben darauf besteht, daß die 8 Stunden nur ein Vorschlag sind, mit dem der Client nicht einverstanden sein muß.