[Problem] Fritzbox LAN-to-LAN-VPN: Fern-Administration der anderen FB geht, aber nicht des daran angeschlossenen IP-Telephones

hl3

Neuer User
Mitglied seit
13 Jun 2020
Beiträge
14
Punkte für Reaktionen
0
Punkte
1
Die Situation:
Zwei Fritzboxen 7590 mit OS 7.12 sind über VPN (myfritz.net-DDNS) standardmäßig dauerhaft verbunden (LAN-to-LAN).
Jede FB hat einen eigenen DSL-Anschluß mit öffentlicher IPv4-Adresse.
Jedes LAN ("Heimnetzwerk") hat eine andere private IP-Adresse (x.x.x.0/24) und besteht aus der Fritzbox, einem Linux-PC und einem stationären IP-Telephon (Snom D345), die beide direkt an der FB angeschlossen sind.
Zugriff auf das Webinterface der FB über das Internet (https) ist in den FB deaktiviert.

Fast alles funktioniert:
(1.) Stationäre IP-Telephonie einwandfrei.
(2.) Smartphone kann sich per WLAN und VPN über die eine Fritzbox mit der anderen Fritzbox verbinden und von dort ins WWW bzw. (mit FritzApp Fon) ins Telephonnetz gehen, also ganz ohne Mobilfunk/SIM-Karte.
(3.) Jeder PC kann *beide* FB und das IP-Telephon im *eigenen* privaten LAN administrieren.

Was noch nicht funktioniert, ist
(4.) die Administration des IP-Telephones im jeweiligen LAN durch den PC im jeweils *anderen* LAN:
Wenn ich die private LAN-IP-Adresse des Telephones im Browser eingebe, kommt nicht einmal das Login-Fenster.
Der Browser sucht, bricht aber nach einer Weile ab, weil der http(s)-"Server nicht erreichbar" ist.

Also:
PC1 kann FB1, FB2 und Fon1 administrieren, aber nicht Fon2.
PC2 kann FB1, FB2 und Fon2 administrieren, aber nicht Fon1.

Ich frage mich (und euch):
Brauche ich Portfreigaben an den FB? (Bisher keine.)
Muß ich FB-Filter öffnen? (Alle IP-Telephone haben das FB-Profil "Gesperrt", damit sie nicht eigenmächtig fragwürdige Verbindungen ins Internet aufbauen.)
Fehlt in den PC der VPN-Client? (Ich dachte, der erübrigt sich bei einem LAN-to-LAN-VPN, und der http-VPN-Zugriff vom PC auf die andere *FB* funktioniert ja.)
Statische FB-Routen dürften nichts bringen, da jede FB im selben IP-Netz ("Heimnetzwerk") liegt wie sein angeschlossenes IP-Telephon.
 
Da fehlt wohl die Information im "entfernten" Netz, wohin die Daten gehen sollen.
Probiere es mal, bei den Netzwerkeinstellungen der "entfernten" F!B eine Route in das "nahe" Netz einzurichten. Hierbei ist die "entfernte" F!B der Gateway.
 
Vollzitat, von darüber, gemäß Boardregeln entfernt by stoney
Deinem Rat folgend (sofern ich ihn denn richtig verstand), habe ich in der entfernten FB eine statische Route zum privaten LAN der nahen Fritzbox eingerichtet, mit der privaten Adresse der entfernten FB als Gateway. "Erfolg": Jetzt ist auch die entfernte FB nicht mehr zu erreichen (das entfernte IP-Telephon ebenfalls nicht). Zuvor hatte ich versucht, als Gateway nicht die entfernte FB einzutragen (weil mir das zirkulär erschien und ich daher schon den Absturz kommen sah), sondern die nahe FB. Das wurde aber von der FB nicht zugelassen (Abbruch mit Fehlermeldung).

Ich bin nicht überrascht, denn statische Routen dürften, wie ich schon in der letzten Zeile der Problembeschreibung bemerkte, nur dann sinnvoll sein, wenn mit einem Netzwerk kommuniziert werden soll, das *hinter* der entfernten FB liegt, d. h., wenn insgesamt 3 private Netzwerke beteiligt sind und das mittlere von ihnen überbrückt werden muß. So wird es auch von AVM deutlich genug beschrieben.

Im vorliegenden Fall gibt es aber nur zwei private Netzwerke: das der nahen FB und das der entfernten FB. Diese sind per LAN-to-LAN-VPN verbunden, und dann heißt es immer so schön: Nun können Sie "mit jedem (Heim-)Netzwerkgerät aus einem Netzwerk auf jedes andere Heim-Netzwerkgerät im anderen Netzwerk zugreifen" (Dennis Rühmer, "FRITZ!Box - Der umfassende Ratgeber", 1. Aufl. 2019, Seite 310). Schön wär's, aber ganz so einfach ist es wohl nicht (immer).
 
Zuletzt bearbeitet von einem Moderator:
Mögliche Lösung: Ich vermute, daß ich in dem IP-Telephon die FB zwar als Zeitserver, aber noch nicht als IP-Gateway eingetragen habe, da ich das bisher (vor der VPN-Verbindung der beiden privaten LANs) nicht brauchte. Das kann ich aber erst in den nächsten Tagen ausprobieren, da ich das entfernte Telephon gegenwärtig nicht fernsteuern kann.
 
Alle IP-Telephone haben das FB-Profil "Gesperrt", damit sie nicht eigenmächtig fragwürdige Verbindungen ins Internet aufbauen.
Da auch das entfernte Netz aus Sicht der FRITZ!Box "Internet" ist, liegt hier auch das Problem. Entweder die Telefone sollen nur lokal zugreifen dürfen (auch ein Zugriff per PC auf ein Telefon braucht natürlich für die Antworten das "Recht", diese auch zu senden) ... dann paßt doch das gezeigte Verhalten exakt. Oder es soll ein entfernter Zugriff möglich sein (hier ist der PC ja auch nicht als Client im lokalen Netz, wie er es bei einer eigenen Verbindung per VPN-Client wäre), dann muß man den eben auch zulassen.

Abgesehen davon sollte es ja nun nur eine Fingerübung sein, den Telefonen einfach mal den Zugriff zu gestatten ... funktioniert es dann wie erwartet, ist die Ursache schon gefunden.

BTW: Wer schreibt denn beim VPN von AVM immer wieder etwas von statischen Routen? Wo findet man denn das:
So wird es auch von AVM deutlich genug beschrieben.
?

Eigentlich spielen beim AVM-VPN Routen überhaupt keine Rolle, solange die FRITZ!Box sowohl VPN-Endpoint als auch Gateway ist - wenn die Pakete für ein entferntes Netz es erst einmal bis zu FRITZ!Box schaffen und die VPN-Verbindungen die richtigen "Selektoren" verwenden in den "accesslist"-Statement, braucht es nicht eine einzige weitere Einstellung ... nicht einmal dann, wenn man über das VPN zu einer Box auch eine weitere (hinter diesem "Vermittler") erreichen will. Und statische Routen haben da erst gar nichts verloren, weil das FRITZ!OS nur die Einrichtung von Routen zuläßt, die über "dev lan" laufen ... und genau da hängt das VPN nicht dran (sondern am "dev dsl").
 
Zuletzt bearbeitet:
BTW: Wer schreibt denn beim VPN von AVM immer wieder etwas von statischen Routen? Wo findet man denn das:
?
Eigentlich spielen beim AVM-VPN Routen überhaupt keine Rolle, solange die FRITZ!Box sowohl VPN-Endpoint als auch Gateway ist - wenn die Pakete für ein entferntes Netz es erst einmal bis zu FRITZ!Box schaffen und die VPN-Verbindungen die richtigen "Selektoren" verwenden in den "accesslist"-Statement, braucht es nicht eine einzige weitere Einstellung ... nicht einmal dann, wenn man über das VPN zu einer Box auch eine weitere (hinter diesem "Vermittler") erreichen will. Und statische Routen haben da erst gar nichts verloren, weil das FRITZ!OS nur die Einrichtung von Routen zuläßt, die über "dev lan" laufen ... und genau da hängt das VPN nicht dran (sondern am "dev dsl").
Das findet man z. B. hier: https://avm.de/service/fritzbox/fri...P-Netzwerke-hinter-einer-FRITZ-Box-zugreifen/
Abgesehen davon sollte es ja nun nur eine Fingerübung sein, den Telefonen einfach mal den Zugriff zu gestatten ... funktioniert es dann wie erwartet, ist die Ursache schon gefunden.
Die erste "Fingerübung" endete damit, daß nun nicht mal mehr die entfernte FB erreichbar ist. Deshalb kann die nächste "Fingerübung" erst in den nächsten Tagen (nach persönlichem Aufsuchen der entfernten FB) stattfinden. -- Aber ja: daß es evtl. an dem "Gesperrt"-Profil der IP-Telephone liegen könnte, hatte ich schon in der Problembeschreibung vermutet. Oder, wie in meiner vorigen Nachricht gemeldet, an dem fehlenden Eintrag eines IP-Gateway im IP-Telephon selbst. Mal sehen. Jedenfalls erst mal danke für den Beistand. Ich werde dann kurz berichten.
 
Das findet man z. B. hier
Vollkommen andere Konstellation ... das hat mit dem VPN per se auch nichts mehr zu tun. Da geht es darum, daß hinter einer anderen FRITZ!Box noch ein weiteres Subnetz zu finden ist, das über einen anderen Router im LAN dieser Box zu erreichen ist:

LAN A ---> FRITZ!Box A <--- VPN ---> FRITZ!Box B <--- LAN B ---> Router <--- LAN B2

Hier muß tatsächlich in FRITZ!Box B dann eine Route für "LAN B2" eingetragen werden ... aber da geht der Traffic ja dann auch tatsächlich über das "dev lan" dieser Box (da kann man auch eine Route per GUI legen) und nicht über eine VPN-Verbindung. In FRITZ!Box A muß dafür nichts weiter geändert werden, als die "accesslist", die zusätzlich den Traffic für "LAN B2" in den Tunnel senden muß.

Wo wäre denn bei Dir dieses "LAN B2"? Es gibt keins ... Du hast ein "LAN A" (bei FRITZ!Box A) und ein "LAN B" (bei FRITZ!Box B) und keine weiteren IPv4-Netze - jedenfalls nach der Erzählung in #1.
 
Vollkommen andere Konstellation ... das hat mit dem VPN per se auch nichts mehr zu tun. Da geht es darum, daß hinter einer anderen FRITZ!Box noch ein weiteres Subnetz zu finden ist, das über einen anderen Router im LAN dieser Box zu erreichen ist:

LAN A ---> FRITZ!Box A <--- VPN ---> FRITZ!Box B <--- LAN B ---> Router <--- LAN B2
Genau, sage ich doch.
Wo wäre denn bei Dir dieses "LAN B2"? Es gibt keins ... Du hast ein "LAN A" (bei FRITZ!Box A) und ein "LAN B" (bei FRITZ!Box B) und keine weiteren IPv4-Netze - jedenfalls nach der Erzählung in #1.
Ja, eben. Deshalb habe ich von Anfang an bezweifelt, daß eine statische Route in MEINEM Fall Sinn macht (siehe #1, letzte Zeile) und das dann noch mal in #3 (Abs. 2 und 3) erläutert. Der "Erfolg" der ersten Fingerübung hat das wohl auch bestätigt.
 
Hmmm, mal so als Denkanstoß:
In einer Gigaset Go Box gibt es einen Haken, der es überhaupt erst erlaubt aus „anderen“ Netzen auf diese zuzugreifen.
Gibt es so einen Haken im Snom vielleicht auch?
Statischen Routen sind allerdings in keinem Fall von Nöten.

Gruß S
 
Deshalb habe ich von Anfang an bezweifelt
Warum machst Du es dann trotzdem?

Egal ... war eher eine rhetorische Frage.

Und mir kam es eher darauf an, auch künftigen Lesern noch einmal ganz klar zu machen, daß statische Routen bei nicht funktionierenden VPN-Verbindungen bei AVM eigentlich nie die Ursache sind, weil das AVM-VPN eben nicht über das "normale" Linux-Routing konfiguriert wird, sondern immer über "dev dsl" gehen muß, weil das VPN Bestandteil des AVM-eigenen WAN-Stacks ist.
 
In einer Gigaset Go Box gibt es einen Haken, der es überhaupt erst erlaubt aus „anderen“ Netzen auf diese zuzugreifen.
Gibt es so einen Haken im Snom vielleicht auch?
Ich versuch's erst mal mit dem Eintrag der privaten IP-Adresse der entfernten FB als "IP-Gateway" im entfernten Snom-Telephon. Der Default ist <blank>.

Snom schreibt dazu: "This setting shows the IP address of the default IP gateway (NOT the VoIP gateway). It is the address to which the packets get routed when the desired packet address is not in the current subnet. Setting up this parameter is mandatory in order to reach an external network [...] e.g. <192.168.0.1>, <10.0.0.1>."

Ob das im Rahmen der vorliegenden VPN-Konstellation etwas bringt, werde ich sehen und, falls nicht, ggf. weiter suchen.
 
Warum machst Du es dann trotzdem?
Auf Vorschlag eines anderen Mitgliedes (siehe #2), als "Fingerübung" ;-)
Und mir kam es eher darauf an, auch künftigen Lesern noch einmal ganz klar zu machen, daß statische Routen bei nicht funktionierenden VPN-Verbindungen bei AVM eigentlich nie die Ursache sind, weil das AVM-VPN eben nicht über das "normale" Linux-Routing konfiguriert wird, sondern immer über "dev dsl" gehen muß, weil das VPN Bestandteil des AVM-eigenen WAN-Stacks ist.
Wie die erste Fingerübung zeigte, können statische Routen bei nicht funktionierenden VPN-Verbindungen bei AVM sehr wohl die Ursache sein, nämlich wenn sie gesetzt werden, wo sie nichts zu suchen haben. Aber eben das meinst ja zu Recht auch du, und es zu wissen, ist in der Tat wichtig.
 
Wie gesagt ... war rein rhetorisch als Frage.

Aber noch ein Tipp dazu ... wenn man so etwas einrichtet, wie Du das derzeit im Sinn hast, hat es sich bewährt, zumindest für diese Zeit dann doch die "Fernwartung" (aka den HTTPS-Zugriff auf das GUI einer FRITZ!Box von der WAN-Seite) zu aktivieren. Darüber kann man dann sowohl falsche VPN-Konfigurationen wieder korrigieren, als auch falsche LAN-Einstellungen (hier gehören die Routen dazu) weiterhin ändern.

Wer es ansonsten nicht braucht (weil er auch keine FRITZ!Apps von unterwegs benutzt), kann es danach ja wieder deaktivieren.
 
Aber noch ein Tipp dazu ... wenn man so etwas einrichtet, wie Du das derzeit im Sinn hast, hat es sich bewährt, zumindest für diese Zeit dann doch die "Fernwartung" (aka den HTTPS-Zugriff auf das GUI einer FRITZ!Box von der WAN-Seite) zu aktivieren. Darüber kann man dann sowohl falsche VPN-Konfigurationen wieder korrigieren, als auch falsche LAN-Einstellungen (hier gehören die Routen dazu) weiterhin ändern.
Ja, das war mir inzwischen auch schon aufgegangen: der (https-)"Zugang aus dem Internet" als zweiter, zusätzlicher Weg außerhalb des VPN-Tunnels, falls dieser nicht mehr funktioniert. Aber nun ist es natürlich zu spät, da ich an die entfernte FB nicht mehr rankomme, um diesen Zugang vorübergehend freizuschalten. Für den VPN-Tunnel ist er nicht notwendig und sollte daher normaler Weise sicherheitshalber deaktiviert werden.
Wer es ansonsten nicht braucht (weil er auch keine FRITZ!Apps von unterwegs benutzt), kann es danach ja wieder deaktivieren.
Auch um von unterwegs mit der FritzApp Fon über WLAN zu telephonieren, wird dieser "Zugang aus dem Internet" zur heimischen FB nicht benötigt, da es sicherer über VPN geht.
 
da es sicherer über VPN geht
Ist das so? Gibt es dafür auch eine Begründung oder ist das mehr axiomatisch? Gilt das generell oder nur bei FRITZ!Boxen und wenn nur bei den AVM-Produkten, war das dann schon immer so, seit es den externen HTTPS-Zugriff und VPN in der Firmware gibt?

Per se sind die Protokolle für beide Optionen weder sicher noch unsicher (auch wenn sie mit "Sicherheit" als Ziel designt wurden) ... es kommt immer auf die konkrete Implementierung und sogar auf die korrekte An-/Verwendung an und wenn es für eine VPN-Verbindung kein PFS (Perfect Forward Secrecy) gibt, ist diese einer HTTPS-Verbindung mit PFS deutlich unterlegen hinsichtlich der "Sicherheit".

Wenn ich mich nicht mächtig "vertestet" habe, verwenden z.B. die "conntype_user"-Verbindungen, wenn sie mit der originalen AVM-Firmware eingerichtet werden, eben ein Proposal-Set, das kein PFS zuläßt (LT8h/esp-all-all/ah-none/comp-all/no-pfs) - um mal ein Beispiel zu nennen bzw. einen Aspekt herauszugreifen, wo das AVM-VPN sogar "unsicherer" ist als der Zugriff auf das GUI, wo wenigstens PFS ausgehandelt werden kann (ab TLS 1.3 dann ohnehin zwingend erforderlich).

Solche pauschalen Aussagen sind daher - ohne nähere Spezifikation, worin dieses "sicherer" bestehen soll bzw. auf welche Aspekte es sich im Einzelnen bezieht - mit äußerster Vorsicht zu genießen und ohne konkreten Vergleich von Vor- und Nachteilen auch ziemlich witzlos.

EDIT: BTW ... die FRITZ!App Fon für IP-Telefonie funktioniert (afaik) gar nicht über die HTTPS-Schnittstelle auf dem WAN-Interface (ich habe jedenfalls noch keine neuen TR-064-Interfaces dafür gefunden), da wäre VPN tatsächlich die Lösung, denn auch ein "Anmeldung aus dem Internet erlauben" für ein eingerichtetes Konto eines IP-Telefons, verwendet natürlich hier nicht das GUI bzw. den HTTPS-Zugriff, sondern stinknormal SIP. Aber es gibt ja auch noch einige andere Apps, die TR-064 von extern benutzen ... auch von AVM und die FRITZ!App Fon ist nur eines von mehreren Angeboten.
 
Zuletzt bearbeitet:
Solche pauschalen Aussagen sind daher - ohne nähere Spezifikation, worin dieses "sicherer" bestehen soll bzw. auf welche Aspekte es sich im Einzelnen bezieht - mit äußerster Vorsicht zu genießen und ohne konkreten Vergleich von Vor- und Nachteilen auch ziemlich witzlos.
Den Hauptnutzen der FritzApp Fon sehe ich darin, daß ich über ein fremdes WLAN irgendwo auf der Welt eine sichere Verbindung zur heimischen FB herstellen und von dort aus mit meinem heimischen Tarif, also praktisch kostenlos, telephonieren kann, z. B. aus Asien "Ortsgespräche" in Deutschland führen kann. Das tue ich über die selbe VPN-Verbindung zwischen Smartphone und FB, die ich auch für's Surfen etc. unterwegs verwende, und so wird es auch von AVM als sicherste und kostengünstigste Lösung empfohlen.

Für diesen Zweck brauche ich keinen https-"Zugang aus dem Internet" zum Web Interface der FB, also habe ich den deaktiviert. Denn jeder überflüssige Zugang ist eine zusätzliche Angriffs- und damit Schwachstelle. Mehr wollte ich damit nicht sagen; das war hier meine (implizite) "Spezifikation" gemäß Problembeschreibung, siehe Nachricht #1 Punkt "(2.)" zur funktionierenden Smartphone-Anbindung.

Die Diskussion genereller Vor- und Nachteile beim Vergleich zwischen VPN und https-Verschlüsselung würde das Thema sprengen, zumal es diverse Varianten gibt. (Der pre-shared key der FB ist eine eher bescheidene VPN-Lösung.) Der größte Risiko-Faktor ist menschliches Versagen; jeder "geheime" Schlüssel wird wertlos, wenn er nicht geheim gehalten wird.
 
Ich glaube, wir reden aneinander vorbei oder Du solltest mal etwas konkreter werden und die Versionsnummer (und die Plattform) für die von Dir verwendete FRITZ!App Fon benennen.

Welche Version ist es denn genau, die Dir das hier ermöglicht?
Den Hauptnutzen der FritzApp Fon sehe ich darin, daß ich über ein fremdes WLAN irgendwo auf der Welt eine sichere Verbindung zur heimischen FB herstellen und von dort aus mit meinem heimischen Tarif, also praktisch kostenlos, telephonieren kann [...]
Wenn es Dir generell um VPN-Verbindungen geht und Du die mit einem anderen Programm oder gar dem OS des verwendeten Gerätes eingerichtet hast, kann man das vielleicht noch nachvollziehen ... dann ist diese "sichere Verbindung" aber nicht der FRITZ!App Fon geschuldet (und kann folglich auch nicht deren Hauptnutzen sein - zumindest nicht, wenn es um die "Herstellung" der Verbindung geht, höchstens als "Benutzung" einer solchen), sondern dem anderen Programm oder dem OS.

Und wenn es Dir nur um die FRITZ!App Fon geht, liegst Du auch wieder richtig, daß man mit der tatsächlich nur über eine VPN-Verbindung arbeiten kann, solange man sich nicht direkt im WLAN der betreffenden FRITZ!Box aufhält.

Nur was hat das alles damit zu tun, ob man (oder Du) nun eine VPN-Verbindung oder den WAN-seitigen Zugriff auf das GUI verwendet und was davon sicherer ist?

Bei der Nutzung der FRITZ!App Fon bleibt Dir eben gar nichts anderes übrig, als eine VPN-Verbindung zu benutzen ... ebenso, wenn Du über den heimischen Internet-Zugang mit einem Mobilgerät von unterwegs surfen willst (oder irgendetwas anderes im "Internet" benutzen). Das sind alles gar keine Anwendungsfälle für den WAN-Zugriff auf das GUI - diese Szenarien funktionieren nur über eine VPN-Verbindung.

Ich hatte aber in #13 geschrieben, daß es noch andere Apps (auch von AVM) gibt, deren Nutzung durchaus auch über das GUI von der WAN-Seite Sinn ergibt und daß man den Fernzugang wieder deaktivieren sollte (weil die Aussage zu Minimierung von Angriffsflächen durchaus richtig ist), wenn man keine dieser Apps nutzt und damit auch aus dem WAN keinen Zugriff auf das TR-064-Interface (das eben auch "hinter" dieser WAN-Freigabe des GUI hängt) braucht.

Daraufhin hast Du dann versucht zu erklären, daß man den ohnehin besser gar nicht benutzen sollte, weil VPN ja sicherer sei (eben auch explizit als "Begründung"):
Auch um von unterwegs mit der FritzApp Fon über WLAN zu telephonieren, wird dieser "Zugang aus dem Internet" zur heimischen FB nicht benötigt, da es sicherer über VPN geht.
und Du hast das dann deinerseits meine allgemeiner gefaßten "Apps" sogar noch auf die FRITZ!App Fon verkürzt, bei der eben der Fernzugriff auf das GUI gar keine Rolle spielt bzw. spielen kann - im Gegensatz zu anderen Apps, die ggf. sogar automatisch über die TR-064-Funktionen den Fernzugang aktivieren.

Die FRITZ!App Fon hat mit dem GUI gar nichts am Hut (gut, das Telefonbuch wird über eine URL geladen, die nicht über TR-064, sondern über den "normalen" Server läuft) und die kann man auch nicht einfach als "normalen" SIP-Client für irgendwelche anderen Server konfigurieren oder als Client für einen externen Zugriff (also über WAN) auf einen SIP-Account einer FRITZ!Box benutzen - wo stellt sich bei dieser App da die Frage, ob man nun GUI über TLS oder VPN verwenden sollte? Wenn es nur eine Option gibt (nämlich VPN), ist es auch vollkommen egal, ob bzw. wie sicher eine andere Option wäre. Da wäre also nicht "da es sicherer über VPN geht" die korrekte Aussage, sondern "da es nur über VPN geht" (wenn man sich nicht direkt im (W)LAN befindet und bei Verwendung der FRITZ!App Fon).

Oder hat AVM inzwischen für irgendeine Plattform eine Beta-App der "Fon" herausgebracht, die selbst (wie die MyFRITZ!-App) eine VPN-Verbindung für eine App einrichtet? Ich habe trotz intensiver Suche (per Google und bei AVM direkt auf der Seite) nichts davon gefunden. Das automatische Anlegen einer Identität für diese App (unter System/FRITZ!Box-Benutzer/Apps) hat mit dem Einrichten einer eigenen VPN-Verbindung (wie in der MyFRITZ!-App) nichts zu tun und selbst die Android-Beta von AVM verspricht nichts, was darüber hinausginge.

Damit wäre ich wieder bei meiner Eingangsfrage, welche Version der FRITZ!App Fon von AVM denn in der Lage ist, eine VPN-Verbindung (und ich gehe mal davon aus, daß es eine solche ist, wenn Du von "sichere Verbindung" und "herstellen" schreibst) einzurichten oder wenigstens aufzubauen/zu aktivieren, wenn sie feststellt, daß sie sich nicht im WLAN der Box befindet. Das wäre sicherlich ein Traum für viele App-Benutzer, die derzeit immer noch selbst (oder mit anderer Software, die entsprechende "Events" bietet) für die Aktivierung der VPN-Verbindung sorgen müssen.
 
Ich glaube, wir reden aneinander vorbei
Den Eindruck habe ich auch. Ich möchte das Thema nicht sprengen und daher auf die von dir angesprochenen, weiteren Punkte nicht näher eingehen.
Die FritzApp Fon stellt die VPN-Verbindung nicht selbst her, aber sie kann genutzt werden, um über diese Verbindung zu telephonieren. (Deshalb das "und" in der von dir beanstandeten Formulierung. Aber auf grammatische Haarspaltereien möchte ich mich hier nicht einlassen. Die Sache dürfte klar genug sein, und ich sehe keinen Sinn darin, sich darüber zu streiten.)
Nur was hat das alles damit zu tun, ob man (oder Du) nun eine VPN-Verbindung oder den WAN-seitigen Zugriff auf das GUI verwendet und was davon sicherer ist?
Eben: Für die FritzApp Fon brauche ich den (https-)"Zugang aus dem Internet" nicht, und darum sehe ich keinen Sinn, ihr nur für die FritzApp Fon zu aktivieren. (Für den Zugang zum Web Interface der FB bleibe ich dabei, daß VPN sicherer ist als https, jedenfalls in der hier thematisierten Situation, da es die Angriffsfläche wesentlich reduziert.) Ob die Aktivierung des https-Zuganges für andere FritzApps sinnvoll oder notwendig sein könnte (wie du angedeutet hattest), darüber habe ich nichts gesagt, weil es nicht zum hier gestellten Problem gehört. Jedenfalls für die FritzApp Fon macht es keinen Sinn: darum ging es mir insofern, und das findest du ja nun auch.
Wie ich schon sagte: Die Diskussion genereller Vor- und Nachteile beim Vergleich zwischen VPN und https-Verschlüsselung würde hier das Thema sprengen. Soweit überhaupt ein Vergleich möglich ist (gesichert wird da jeweils auch Verschiedenes), bevorzuge ich VPN. Ich glaube auch, daß ich damit die herrschende Meinung (und AVM) auf meiner Seite habe. Aber entscheiden muß es jeder selbst.
 
Du verkennst wichtige Punkte ... so richtete sich mein Hinweis:
Wer es ansonsten nicht braucht (weil er auch keine FRITZ!Apps von unterwegs benutzt), kann es danach ja wieder deaktivieren.
gar nicht explizit an Dich. Das ist hier nämlich keine 1:1-Diskussion, die sich ausschließlich um Dein Problem drehen muß oder auch nur sollte. Das können/dürfen/sollen auch andere Leser später noch zur Kenntnis nehmen, wenn sie mit einem ähnlichen Problem auf der eigenen Suche nach einer Lösung sind.

Und es ist/sei Dir selbstverständlich unbenommen, meinen Hinweis an diese späteren Leser noch (korrekt) zu kommentieren. Nur wirst Du eben auch weiterhin entsprechenden Widerspruch ernten, wenn diese Kommentare dann (fachlich) falsch oder zumindest "fragwürdig" sind. Und genau das sind sie, wenn sie zwar meine Aussage "weil er auch keine FRITZ!Apps von unterwegs benutzt" zitieren, dann aber darauf verweisen wollen, daß generell das VPN dem TLS-Zugriff auf das GUI von der WAN-Seite vorzuziehen wäre und das obendrein noch mit dem Bezug auf eine AVM-App, die mit dem Zugriff auf das GUI gar nichts am Hut hat.

Danach dann darauf zu verweisen, daß das Thema hier mit einer etwas tiefergehenden Begründung (bzw. überhaupt erst mal einer, denn ein "da es sicherer über VPN geht" ist ja nichts anderes, als eine unbegründete Behauptung, also nicht mal eine glaubhafte These) gesprengt würde oder eine im Kern falsche Aussage als Streit über grammatikalische Feinheiten darzustellen (das Zitat in #17 habe ich mir ja nicht ausgedacht, ich habe nur die falschen Zusammenhänge/Behauptungen gekennzeichnet), ist schon einigermaßen schwach ... und dann noch auf die "herrschende Meinung (und AVM)" zu verweisen:
Ich glaube auch, daß ich damit die herrschende Meinung (und AVM) auf meiner Seite habe.
, macht es nur noch peinlich. Wenn's wenigstens noch konkretes "name dropping" wäre oder irgendetwas, wo man den Urheber Deiner Meinung erkennen könnte (auch "AVM" ist schon herb "allgemein") - aber so ist das nur noch ein: "Aber der Lehrer hat das auch gesagt."

Immerhin war AVM bis vor kurzem sogar noch der Meinung (oder zumindest war es im Support oder in der Knowledge-Base die "herrschende"), daß eine VPN-Verbindung mit der AVM-Firmware nur dann möglich wäre, wenn beide Seiten bei einer solchen Verbindung auch über eine IPv4-Adresse verfügen ... wie das trotzdem geht, wenn nur eine der beiden eine solche hat, konnte man dann (lange vor der Änderung der KB bei AVM und vor ein paar Änderungen, die das dann in neueren Versionen auch ohne "Handarbeit" ermöglichten) hier im IPPF lesen.

Ein Verweis auf "AVM" oder auf "herrschende Meinung" ist also nur eine Seifenblase ... oder u.U. eben auch nur "nachgeplappert" ohne das passende Hintergrundwissen (das kann man bei Dir mangels Bereitschaft zur Begründung nur schwer einschätzen - es mag sogar "Kompendien" geben, in denen das so dargestellt wird) und dann sollte man ggf. künftig nicht so einfach aufs Eis marschieren (und wenn's einem noch so wohl geht) - und ich sehe meine "Aufgabe" hier auch darin zu verhindern, daß Dir andere Leser ohne weiteres auf diesem Weg (oder in dieser Annahme) blind folgen, nur weil es bei AVM vielleicht "so gesagt" wird.

Und die von Dir propagierte Entscheidungsfreiheit jedes Einzelnen an dieser Stelle setzt eben - da es hier nicht nur um Mode oder "Geschmacksfragen" geht - auch das Wissen um die tatsächlichen Vor- und Nachteile der jeweiligen Lösung voraus ... warum willst Du das den künftigen Lesern denn vorenthalten?

Wenigstens die eine oder andere Quelle kann man ja - auch ohne das Thema hier zu sprengen - angeben ... dann können sich die Leser selbst ein Bild von der Seriosität der dort getroffenen Aussagen machen. Schließlich gibt es heutzutage an jeder zweiten Ecke irgendeinen "Fakten-Check" ... warum sollte man den nicht auch mal für die (pauschale) Aussage, daß VPN sicherer wäre als der externe TLS-Zugriff aufs GUI bei einer FRITZ!Box, machen?
 
Deine Formulierung "keine FRITZ!Apps" ist nach üblichem Verständnis gleichbedeutend mit "überhaupt keine FRITZ!App", und das impliziert nach üblichem Verständnis "auch nicht die FRITZ!App Fon". Ich kann aber sehr wohl die FritzApp Fon OHNE den https-Zugang verwenden und habe nie etwas anderes behauptet. Insofern weise ich noch einmal auf die von Anfang an erfolgreiche Smartphone-Anbindung über VPN in der Problembeschreibung (Nachricht #1) hin. Ob es evtl. auch anders und evtl. sogar besser ginge (mit oder ohne https-"Zugang aus dem Internet"), hat DICH interessiert, aber nicht MICH. Ich vertraue insofern auf eine vorteilhafte Beurteilung von VPN, die ich für die seit langem zu Recht herrschende halte.

Dir das hier noch näher zu begründen, lehne ich schlicht ab, weil es nicht zum Thema gehört und es dafür anderswo haufenweise Quellen und passendere Diskussionen gibt. Jedenfalls ist es meine Sache, ob ich mich auf eine Diskussion einlasse, die ich an dieser Stelle für unpassend und fruchtlos halte. Ich glaube auch nicht, daß anderen Lesern damit gedient wäre, die sich für das Thema, wie es von mir formuliert wurde, interessieren. Das "peinlich" zu finden, bleibt dir unbenommen.
 
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.

IPPF im Überblick

Neueste Beiträge