[Info] FRITZ!Box 7590 Laborserie 07.39 – Sammelthema

[kleinkariert]

Besteht denn irgendein dringender Grund, alle Clients von IKEv1 auf WireGuard umzustellen, zudem noch weit vor der Release? (Außer natürlich das ehrwürdige Alter vom IKEv1-Protokoll und den Clients, IPv6, Android 12 etc. pp. .)

WireGuard macht zwar einen unkomplizierten Eindruck, ist es aber an einer Stelle nicht wirklich.
Weil aber im normalen Modus unter Windows erst zum Start des Tunnels ein Netzwerkadapter installiert und ein Service gestartet werden muss, benötigt man für den eigentlich simplen Vorgang Admin-Rechte. Wer nicht gern im ständigen Admin-Modus arbeitet, aber auch nicht ständig selbigen bestätigen will, muss für den manuellen Start per GUI einen Hack installieren (LimitedOperatorUI). Damit kann man dann immer noch keinen Tunnel im Autostart oder per Batch starten, das erfordert wieder einen anderen Hack.

Die 7590 hat AES-Hardware für das IKEv1 und kann damit die CPU deutlich(?) entlasten, den Vorteil würde ich solange wie möglich nutzen.

 

[Silverio]

Das ist jetzt nur Spekulation da ich das nicht bis in die Tiefe verstehe...
Aber ist es nicht so, dass die IPSec Implementierung in den Fritzboxen nur ausschließlich ipv4 kann?
Wer also einen ds-light Anschluss hat, schaut in die Röhre?

 

[B612]

2 mal: Ja
Deshalb gibt es ja jetzt endlich Wireguard.

 

[Peter_Lehmann]

Ich möchte mal speziell auf den Beitrag von @kleinkariert eingehen.
edit: Obige Zeile geändert, damit der o.g. User nicht noch länger warten muss.

Wie ich schon des Öfteren erwähnt habe, betreibe ich seit ca. 2 Jahren ein (völlig privates) Wireguardnetz mit ggw. 8 in drei Ländern verteilten WG-Servern. Allerdings nicht auf meinem aktiven Router, sondern auf umgeflashten F!Bn vom Typ 4040 und 7412. Denke mal, dass ich somit ein klein wenig Erfahrung damit habe.

Was sind für mich die großen Vorteile von WG:

1. WG ist es "völlig egal", ob die Tunnelendpunkte über IPv4 oder IPv6 betrieben werden. Bei einer sachgemäßen Installation wird intern echter Dualstack genutzt, und das selbst im Tunnel. Damit gibt es für mich keinerlei Zwang, am veralteten IPv4 festzuhalten. Einige meiner Nutzer haben nur DSLite => keinerlei Probleme! Man merkt es nicht! Und mit einem guten DynDNS-Anbieter ist das auch kein Problem (ich nutze dynv6.com).
2. Im Gegensatz zum IPsec und anderen Verfahren erfolgt der Aufbau der Verbindung wirklich "blitzschnell", weil kein "Aushandeln" der Verfahren erforderlich ist. Das ist zu spüren, wenn ich (mit dauerhaft aktiviertem VPN auf dem Smartphone) mein heimisches WLAN verlasse, das Gerät automatisch die Mobilfunkverbindung nutzt, in der Stadt dann unser gut ausgebautes (unverschlüsseltes) Freifunknetz und dann auf der Rückfahrt wieder Mobilfunk und letztendlich das heimische WLAN.
   Mehrfach getestet: Auf der gesamten Fahrt gibt es keinerlei Abbrüche beim Telefonieren mit der AVM App FON. Mach das mal mit IPsec …
3. Auch wenn AVM jetzt endlich die HW-Verschlüsselung unter IPsec auf den aktuellen Spitzengeräten aktiviert hat, gibt es das ja nicht auf den schon etwas älteren Geräten. Selbst mit der schwachbrüstigen 7412 nutze ich meinen Uplink (knapp 40.000) fast vollständig aus. Und auf der wesentlich leistungsstärkeren 4040 kann ich immerhin meine 7 Tunnel gleichzeitig betreiben. Klart, auch hier bremst mich die Bandbreite meiner DSL-Verbindung.
4. Ich bin nicht mehr auf das veraltete IKEv1 angewiesen.
5. Für alle gängigen Betriebssysteme, von Linux, der WinDOSe, dem Apfelrechner bis zum Androiden gibt es stabil laufende Clients. Auf allen Systemen in wenigen Minuten installiert und ebenso schnell konfiguriert. Bei richtiger Konfiguration nutzen sogar alle Clients als DNS-Server meinen auf dem RasPi laufenden pi-hole und garantieren somit fast vollständige Werbefreiheit. Weil das alles so gut und störungsfrei funktioniert, sind alle meine "außerhäusig" betriebenen Geräte so konfiguriert, dass sie grundsätzlich über das VPN mit meinem Hausnetz verbunden sind. Selbst zu Hause - hat keinerlei Nachteil und dafür den großen Vorteil, dass ich das Aktivieren des VPN nicht vergessen kann. (Ich sage nur: unverschlüsselter Freifunk im Städtchen.)
   Ob man für den Windows-Client Admin-Rechte benötigt, weiß ich nicht. Ich nutze kein Windows. Auf jeden Fall kann ich unter Linux und Android die Verbindung grundsätzlich (natürlich nach korrekter Installation des WG-Clients) direkt als User starten, nutzen und beenden. Kann mir nicht vorstellen, dass das unter Windows nicht funktionieren soll.

Ich möchte natürlich zwei "Nachteile" nicht unerwähnt lassen:

1. Wenn ein Client (nicht ein anderer WG-Server!) mit einem WG-Server verbunden ist, dann bekommt er nach einer Änderung der Srv-IP (nach der sinnfreien Zwangstrennung …) keine automatische Verbindung zum WG-Server. Beim Klapprechner kann man das mit einem kleinen Script umgehen, welches dauernd die IP mit der letzten bekannten IP vergleicht und bei Änderung die Verbindung mal ganz kurz trennt. Beim Androiden hilft dann eben nur ein kurzes manuelles Trennen in der WG-App.
2. Wireguard verwendet zwar modernste Kryptoverfahren. Und es wurde auch schon von mehreren Firmen und fachkundigen Usern geprüft. Aber es gibt meines Wissens ggw. noch kein offizielles Audit. Das bedeutet, dass WG gegenwärtig noch nicht für eingestufte Daten verwendet werden darf. Aber die von uns zu übertragenden Daten sind ja nicht als GEHEIM, sondern nur als "Pillepalle-Privat" eingestuft. Eine Fritz!Box ist ja auch keine SINA-Box!

Noch einmal:
Ich schreibe über meine guten Erfahrungen mit WG-Servern in Form eigenständiger Geräte. Ich weiß nicht, was alles an Funktionen, Konfigurationsmöglichkeiten und sonstigen Features AVM bei der WG-Integration in die F!B schon und/oder letztendlich anwendet. (IMHO: Und ich selbst würde auch nie ein VPN auf einem Gerät nutzen, wo Dritte einen wie auch immer gearteten Zugriff haben - aber hier schlägt wohl wieder mein ehemaliger extrem strenger beruflicher Hintergrund zu. Auf die Zusendung von diversen Aluhüten bitte ich zu verzichten.)
Aber für Nutzer und Tester (!) diverser BETA und Labor-Versionen sehe ich das Probieren dieser schönen neuen Funktion als eine sinnvolle und spannende Sache an. Wer nicht mit Fehlern und bestimmten "Effekten" umgehen kann oder will, der sollte ja auch keine LABOR und BETA testen.



vy 73 de Peter

 

[B612]

die großen Vorteile von WG:

Die Ursache für deinen 3. Vorteil ist dass IPSEC nur einen Kern benutzt und WG alle. Also bei der 4040 sind das 4 und bei der 7412 noch 2.

 

[feelfree]

nur einen Kernel benutzt

Ich habe hier einen kurzen Moment gebraucht bis ich verstanden habe was Du meinst. Kern oder Core, aber nicht Kernel.

[Edit Novize: Beitrag wieder hergestellt - Vandalismus wird nicht geduldet]

 

[Peter_Lehmann]

Nun ja, den (Linux-)Kernel darf man schon mal mit dem (Prozessor-)Kern bzw. Core verwechseln.
Trotzdem, beim ersten Einsatz von Wireguard war die Bandbreite der Tunnel im Vergleich zu IPsec schon überraschend.
Ich bleibe dabei, die Vorteile überwiegen.

 

[erik]

Aber ist es nicht so, dass die IPSec Implementierung in den Fritzboxen nur ausschließlich ipv4 kann?
Wer also einen ds-light Anschluss hat, schaut in die Röhre?

Ausgehende VPN-Verbindungen funktionieren auch an ds-light Anschlüssen. Ansonsten stimmt, was du schreibst.

@Peter_Lehmann Da habe ich noch einen Fehler in der Konfig, denn beim Wechsel vom Heimnetz zum Mobilnetz und umgekehrt verliert die Fritz Fon App die Verbindung, und wenn sich die IPv6 des Servers ändert, muß ich den zweiten Server, der keinerlei öffentlich erreichbare IP hat, manuell neu starten (via Steckdose in der Cloud), damit die Verbindung wieder steht.

 

[kleinkariert]

@Peter_Lehmann
Habe ich Jehova gesagt?
Ich habe hier nichts gegen WG im Allgemeinen, sondern nur im Speziellen vorgebracht, wo es um das vergleichsweise verkorkste Handling unter Windows geht. Außerdem habe ich die Frage gestellt, wieso man schon alle VPNs lange(?) vor der Release auf WG umstellen muss. Aktuell kann ich nur Clients und (wieder mit der aktuellen Inhaus) andere 7590(AX) verbinden, das ist für mich noch kein Startschuss für die große Migration auf WG.
Natürlich habe ich im Moment auch keinen heftigen DS-Light-Leidensdruck, wo ich weitaus unaufgeregter bleiben kann.

P.S. Ich warte noch darauf, dass du speziell auf meinen Beitrag #261 eingehst.

 

[rstle]

Die Neugierde war zu groß. Habe mir doch nochmal die Labor drauf geschoben,
die DNS Server geändert, seitdem keine Reboots mehr
und auch sonst keine Fehler außer der Led Anzeige in den Rufnummern festgestellt.
Leider funktioniert VPN (Ipsec) nicht mehr. Nur IPv4 aktiv wie unter 7.29.
Auch Löschen und Neueinstellung bringen nichts. Fehlermeldung VPN Server nicht gefunden.
Mein Fehler oder in der Labor generell?

====================
Ursache gefunden: Multisimkarten iin meinen Smartphones gegenseitig gewechselt. 2. Karte offenbar nicht für alles freigegeben deshalb auch kein SMS Empfang.
Mal sehen was der Anbieter meint.

 

[B612]

Trotzdem, beim ersten Einsatz von Wireguard war die Bandbreite der Tunnel im Vergleich zu IPsec schon überraschend.
Ich bleibe dabei, die Vorteile überwiegen.

Da gegen wollte ich auch nichts sagen. Ich wollte das noch untermalen und begründen.

 

[rosi67]

FB 7590 mit 07.39-94326 als Client angeschlossen, Terminkalendar mit Termineinstellung am 23.03.2022 klingelt heute am 01.02.2022 ?
Kennt jemand dieses Problem ?

evtl taucht dieses Problem auch bei der Labor auf ?

 

[flinty]

rosi67: Die 07.39-94326 ist Inhaus. Bist im falschen Thread gelandet...

 

[stoney]

und egal ob Labor oder Inhouse (auch wenn ich das im Titel nicht auffinden kann - aber dafür gibt es ja einen extra Thread, welcher diese Unstimmigkeiten eig. mal klären sollte), ist beides keine Release - aber zumindest zur Labor kann man ja problemlos Feedback geben

 

[diezehe]

Nachdem Peter_Lehmann sehr schön beschrieben hat, was er mit WG alles macht, habe ich es sofort auch ausprobiert:
Leider ist Wireguard derzeit scheinbar nicht kompatibel mit der FritzFon App auf IOS: Die App findet mit aktiviertem WG die FritzBox nicht (App ist eingerichtet und funktioniert im lokalen Netz ohne aktiviertes WG-VPN)

 

[Benares]

Habe ich auch schon festgestellt. Auch der Aufruf er FB-Homepage endet auf einer Anmeldeseite mit Benutzername und Kennwort, wie wenn man von extern käme.

 

[Peter_Lehmann]

edit: Es geht hier um das Thema Wireguard und Fon-App (#275 und 269. Ich war da wohl zu langsam ... .

Vermutlich liegt das (ggw. noch?) am Routing oder ähnlichen Einstellungen. Kann mir vorstellen, dass das einfach noch nicht korrekt ist, in diesem Zustand.
Ich kann und will aber auch diese Firmware nicht installieren und mit euch testen (das erste Mal seit vielen Jahren keine LABOR!). Mitte Dezember hat mich das erstmalig das DLM erwischt und von 116.800 auf ganze 80.000 gedeckelt. Jetzt bin ich wenigstens schon im Laufe der Wochen zuerst auf 90.000 und jetzt auf glatte 100.000. Da darf ich mir keinen Fehler erlauben.

Ich will mich noch einmal wiederholen: Die Fon-App und Wireguard arbeiten perfekt (!) zusammen. Und ich denke oder hoffe mal, dass das hier auch noch kommen wird.

In meinem Setup arbeiten ja insgesamt 8 VPN-Server (LAN2LAN). In der F!b habe ich für jeden der 7 Tunnel einen UDP-Port zum WG-Server für IPv4 und IPv6 freigegeben bzw. geöffnet (ankommende Erreichbarkeit). Das wird bei einem auf der F!B laufenden WG-Server vermutlich nicht erforderlich sein. Und in den Netzwerkeinstellungen habe ich für jeden Tunnel und für jedes Netz entsprechende statische Routen angelegt.
Die an den jeweiligen WG-Servern direkt "angebundenen" Clients (Laptops und Smartphones) verbinden sich mit den WG-Client-Programmen (oder Apps) mit dem vorgesehenen WG-Server. <= Das ist die Verbindung, die ja dann auch für die Fon-App genutzt wird. (Kann das überhaupt die ATM-Variante - ich weiß das nicht!)

Das Ganze muss sehr gut durchdacht sein, hinsichtlich IP-Bereiche, DDNS-Namen und den jeweiligen Schlüsseln. Und das für jede einzelne Verbindung. In meinem Fall sind das 10 Blatt mit entsprechenden Daten, das kann man nicht mehr "aus dem Kopf".

Funktionieren denn wenigstens schon die Tunnel vom Smartphone zur F!B? Ist das Netz vom Smartphone aus anzupingen und was zeigt ein "ip a s" auf dem Smartphone? (Ja, dazu benötigt man ein Konsolenprogramm wie "Termux" auf dem Gerät und man muss sich auch ein klein Wenig auf der Linux-Konsole auskennen.)
Sehr zu empfehlen ist auch, auf den Clients mal einen Dienst wie whatismyip.com aufzurufen - mal ohne Tunnel (also in diesem Fall über die Mobilfunkverbindung und nicht etwa WLAN) und dann einmal mit aktiviertem Tunnel. Im zweiten Fall muss dann die (WAN-)IP der F!B angezeigt werden. Und auch die eigene F!B muss mit ihrer internen IP erreicht werden. Erst wenn das alles funktioniert, sollten solche Themen wie das Telefonieren behandelt werden.

Ich bin gern bereit, mir auch mal Konfigurationen (speziell Client) anzusehen und bei diesem Thema Hilfe zu leisten.
Aber es sollte dann einer von euch ein extra Thema aufmachen, denn sonst verwässern wir diesen Thread und werden vlt. auch noch von der Obrigkeit wegen des [OT] abgemahnt.

vy 73 de Peter

 

[Thomas5]

Peter, das hatte ich vor einigen Seiten schon mal beschrieben. Kurzform: Tunnel steht und funktioniert, Ping geht, Fritz!Fon-App findet die Box, nach Anmeldung Fehler "(606) - Action Not Authorized."

 

[Peter_Lehmann]

... nach Anmeldung Fehler "(606) - Action Not Authorized."

Das kommt mir irgendwie bekannt vor!
Deshalb meine Frage: Funktioniert die App, wenn du selbige im Heimnetz - also im eigenen WLAN - nutzt?

Erklärung:
Ich habe hierbei folgendes Problem:
Bis zur Version 2.3.x hat bei mir diese App etliche Jahre völlig problemlos funktioniert. Und zwar sowohl im Heimnetz und selbstverständlich auch über mein VPN (in grauer Vorzeit AVM-IPsec und seit ~2019 (?) Wireguard). Immer und überall, im Auto und auch im Ausland (Dänemark).
Mit der V. 2.4.x BETA kam erstmals keine Anmeldung mehr zustande. Das zieht sich hin, bis zur aktuellen V. 2.5.1, welche ich gestern wie alle anderen vorher erschienenen Versionen getestet habe. Und zwar, völlig egal, ob ich im WLAN oder übers VPN komme.
Deinstalliere ich die gerade getestete Version (auch auf der F!B) und installiere ich die alte 2.3.0, funktioniert es wieder so, wie all die Jahre. (BTW: Nochmals Danke an den Forenuser, der mir diese Version bereitgestellt hat. AVM hat selbige angeblich nicht mehr.)
Selbstverständlich melde ich das nach jedem Test sofort und sehr ausführlich an AVM. Auch mit dem erstellten Protokoll und ich biete auch jedes Mal aktive Mithilfe bei der Fehlersuche an (Wireshark ist mein Freund). Aber bis auf die automatische Mail, dass AVM sich aktiv kümmern wird, ist von AVM leider nie wieder etwas zu hören. Das ist ein Verhalten, was ich von AVM in den 2 Jahrzehnten wo ich deren Produkte nutze, noch nicht erlebt habe! (Und jetzt habe ich dieses das erste Mal öffentlich geschrieben. Musste einfach sein!)

vy 73 de Peter

 

[Thomas5]

Ja, im WLAN funktioniert die App. (Hatte ich auch schon geschrieben…) Habe ich auch alles an AVM gemeldet, aber leider auch noch keine Reaktion.