Fritz!App Fon verbindet sich nicht mit FB 7490

FritzchenWitz

Neuer User
Mitglied seit
5 Dez 2018
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
Hallo IPPF-Expert(inn)en,

ich betreibe eine Fritzbox 7490 (Fw 7.01) im LAN, d.h. nicht als DSL-Router. Internet, WLAN, Switching, Firewall übernehmen andere Geräte. Die Fritzbox ist lediglich meine Telefonanlage und funktioniert als solche seit Jahren einwandfrei. Das einzige Problem, dass mich in den Wahnsinn treibt:

Die Fritz!App Fon möchte sich weder unter Verwendung eines Android-, noch unter Einsatz eines iOS-Handys mit der Fritzbox verbinden, sondern meint, die Fritzbox nicht finden zu können - auch dann nicht, wenn ich in Fritz!App Fon unter Settings die IP-Adresse der Fritzbox angebe.

Routing-, Firewall- oder DNS-Probleme schließe ich aus, denn wenn ich CSipSimple verwende funktioniert alles einwandfrei. CSipSimple lässt sich manuell konfigurieren. Fritz!App Fon macht irgend nen Autoconfig-Hokuspokus, der über Subnetzgrenzen hinweg zu scheitern scheint.

Nur wenn ich das WLAN an der Fritzbox aktiviere und die Handys (Android und iPhone) darüber - quasi direkt - mit der Fritzbox verbinde, findet die Fritz!App Fon die Fritzbox, registriert sich und ich kann problem telefonieren. Meine Hoffnung - wenn ich mich so einmal registriert habe, vielleicht klappts dann auch aus einem anderen Subnetz - erfüllte sich leider nicht. Das heißt, nachdem ich das WLAN wieder deaktiivert und die Telefone wieder in meinem eigentlichen WLAN eingebucht waren, fanden sie die Fritzbox nicht mehr.

Frage: Hat jemand ein ähnliches Setup bei sich (gar erfolgreich) laufen und eine Idee was ich noch versuchen könnte, um das Problem weiter einzugrenzen? Oder ist mein Vorhaben aussichtslos?


Vielen Dank für Eure Unterstützung!
FritzchenWitz
 
Das liest sich für mich eher wie Overblocking zwischen verschiedenen Subnetzen (ich nenne sie mal "Segmente", weil sie das Netz vermutlich auch bei Dir unterteilen sollen und nicht "parallel" arbeiten innerhalb eines solchen Segments), da Du versäumt hast, Dich über die verwendeten Portnummern (und Protokolle an sich) in der Kommunikation zwischen der App und der Box zu informieren und das als "Autoconfig-Hokuspokus" ansiehst oder abtust.

Bei mir funktioniert die Android-Variante problemlos auch aus dem WLAN einer anderen FRITZ!Box, wobei zwischen dieser (7490) und der "eigentlichen" (6490) noch ein Linux-System sitzt, das erst den Zugriff über VLAN-Grenzen ermöglicht, weil es zwischen den VLANs routet (und dabei - quasi nebenbei - auch Zugriffsbeschränkungen (interne Firewall) durchsetzt).

Bei der (automatischen) Einrichtung der App ist die Beschränkung auf das LAN irgendwo logisch, da die Box ja über SSDP gesucht wird, was als Broadcast (bzw. Multicast) schon mal per se auf das Segment beschränkt ist, solange man nichts dagegen tut (kleiner Tipp am Rande: Auch das kann man - z.B. mit "iptables"-Regeln - wunderbar über mehrere Segmente verteilen).

Auch die aktuelle Version der FRITZ!App Fon kann noch problemlos "von Hand" eingerichtet werden kann - immerhin bietet sie noch die Möglichkeit im Menü an, die IP-Adresse der FRITZ!Box manuell einzugeben:
Screenshot_20181205-165309.jpg
- die 7580, die da noch zusätzlich steht, ist in einem Subnetz, wo sie über SSDP nicht gefunden werden kann und gerade mal zum Test von mir per Hand hinzugefügt worden.

Zwar werden bei mir die SSDP-Pakete (schon wg. des SAT>IP-Servers in der 6490) vom Router tatsächlich auch über die (passenden) Subnetze verteilt, aber nach dem Weiterleiten der Broad-/Multicast-Pakete (und dem "Erkennen" der Geräte im Netz über SSDP) geht die nachfolgende Kommunikation ja ohnehin nur noch über Unicast-Pakete und genau so wird auch von der App dann nach Eingabe einer IP-Adresse nach einer Box gesucht - nämlich mit einem HTTP-Request (HEAD für /tr64desc.xml) innerhalb des TR-064-Protokolls.

Aber der erfolgt eben - bekanntlich - auf Port 49000 (und auf Port 49443 für TLS-gesicherte Zugriffe - kriegt man mit dem simpelsten Paketmitschnitt auch sofort selbst heraus, wenn man es tatsächlich noch nie gehört, gelesen oder bei der eigenen Recherche zu diesem Thema im Internet gefunden hat) und wenn man sich berufen fühlt, sein Heimnetz in mehrere Segmente zu unterteilen, aber über diese Grenzen hinweg dann trotzdem mit FRITZ!Boxen per TR-064 zu kommunizieren, dann muß man eben auch dafür sorgen, daß diese Pakete weitergeleitet werden können zwischen den Segmenten. Solltest Du das wider Erwarten bereits machen, steht davon zumindest nichts (jedenfalls nichts konkretes) in #1.

Das angeführte CSipSimple ist ja als Beweis für "klappt schon irgendwie" vollkommen untauglich - der entsprechende Menüpunkt in der FRITZ!Box heißt ja nicht umsonst "Zugriff für Anwendungen zulassen" (https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/017p2/hilfe_netzwerk_ip wäre die Seite in der Online-Hilfe mit entsprechenden Erläuterungen, was solche "Anwendungen" denn nun sein könnten) und da reichen irgendwelche erlaubten Zugriffe für SIP und RTP über die Segmentgrenzen hinweg dann eben nicht aus (für CSipSimple hingegen schon).

Die FRITZ!App Fon ist eben nicht nur ein simpler SIP-Client und braucht etwas mehr "Freiheit" bei der Kommunikation mit der FRITZ!Box. Das kann/muß man eigentlich auch schon aus ihrem Funktionsumfang schließen, denn wie sollte sie über SIP/RTP auf das Telefonbuch in der FRITZ!Box zugreifen können?

Sollte ich mich hier tatsächlich so schwer irren hinsichtlich der Fehlerursache in berichteten Fall (TR-064 ist nicht ordnungsgemäß nutzbar), kann das Geschriebene hoffentlich immer noch späteren Lesern einen Hinweis auf mögliche Probleme (bei einer Topologie mit mehreren lokalen Segmenten, zwischen denen nicht alle Zugriffe erlaubt sind - ohne solche Beschränkungen bräuchte man i.d.R. aber auch nicht mehrere Segmente und könnte/sollte, sofern die Adressen tatsächlich knapp werden, lieber mit einer anderen Netzwerkmaske für die IPv4-Adressen arbeiten) geben.
 
danke für den Hinweis auf SSDP - ist mir entgangen (habe beim sniffen multicast-adressen ausgelassen). Da ich kein Linux, sondern eine pfsense als Router/Firewall einsetze helfen mir die iptables-rules, helfen mir die erwähnten iptables-rules zwar nur bedingt weiter, dennoch würden mich diese sehr interessieren. Wärst Du so freundlich und könntest diese kurz vorstellen?

Vielen Dank!
 
Einfach die Zieladresse 239.255.255.250 und den Zielport 1900 als Kriterium verwenden und die betreffenden Pakete dann auf die anderen Interfaces duplizieren ... entweder mit einem Proxy-Daemon oder (mit Einschränkungen) auch direkt mit einem "tee"-Target.

Erst dann, wenn man die Unicast-Zugriffe auch noch entsprechend limitieren will (damit nur auf die tatsächlich auch annoncierten Services (IP, Port) zugegriffen werden kann), wird es komplizierter und man muß beim "Übertragen" der MC-Pakete auf ein anderes Interface noch einen passenden Eintrag in einer "ipset"-Tabelle vornehmen, der den "Rückweg" aus dem Segment zum Absender der SSDP-Ankündigung freischaltet.

Und man darf natürlich hier kein NAT (zumindest für die SSDP-Pakete) machen, damit die anderen Systeme auch die tatsächliche IP-Adresse des "Dienstanbieters" als Absender sehen und nicht nur das Gateway ... auch müssen die Systeme dann natürlich die Routen für diese Zugriffe kennen.

Wobei das SSDP-Thema mit der generellen Funktion der App eben nichts zu tun hat ... daran liegt es ziemlich sicher nicht, wenn die App auch mit Angabe der IP-Adresse die FRITZ!Box nicht finden kann.
 
Wie gesagt, gebe ich die IP an, klappt's trotzdem nicht. Hier ein Paketcapture:

192.168.3.97 ist das iPhone
192.168.15.1 ist die Fritzbox


21:39:46.597735 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 265)
192.168.3.97.52258 > 192.168.15.1.80: Flags [P.], cksum 0xf507 (correct), seq 1:214, ack 1, win 1029, options [nop,nop,TS val 401531121 ecr 131256762], length 213: HTTP, length: 213
GET /jason_boxinfo.xml HTTP/1.1
Host: 192.168.15.1
Accept: */*
Accept-Language: en-us
Connection: keep-alive
Accept-Encoding: gzip, deflate
User-Agent: FRITZ!App%20Fon/2549 CFNetwork/975.0.3 Darwin/18.2.0

21:39:46.598063 IP (tos 0x0, ttl 63, id 43436, offset 0, flags [DF], proto TCP (6), length 52)
192.168.15.1.80 > 192.168.3.97.52258: Flags [.], cksum 0x1022 (correct), seq 1, ack 214, win 486, options [nop,nop,TS val 131256762 ecr 401531121], length 0
21:39:46.601456 IP (tos 0x0, ttl 63, id 43437, offset 0, flags [DF], proto TCP (6), length 300)
192.168.15.1.80 > 192.168.3.97.52258: Flags [P.], cksum 0xbe47 (correct), seq 1:249, ack 214, win 486, options [nop,nop,TS val 131256762 ecr 401531121], length 248: HTTP, length: 248
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 170
Content-Type: text/html; charset=utf-8
Pragma: no-cache
Server: Webserver
WWW-Authenticate: Digest realm="HTTPS Access",nonce="D8A1C393A6B4F179",algorithm=MD5,qop="auth"

Was mich daran wundert: Die App kontaktiert die Fritzbox auf Port 80 (http) und die Fritzbox scheint https zu erwarten? Zumindest schließe ich das aus dem in der Antwort enthaltenen realm="HTTPS ...
 
Die FRITZ!Box ist der Ansicht, daß die Verbindung "von außen" (also von der WAN-Seite) erfolgt (Variable "from_internet" ist hier gesetzt in Lua) ... da darf die (normalerweise auch ohne Authentifizierung abrufbare) "jason_boxinfo.xml" in dieser Form halt nicht abgerufen werden.

Wenn die Box hier immer noch als Router läuft (daß man die Betonung in #1 auf "nicht als DSL-Router" legen muß, ist ja nicht so offensichtlich), dann muß man (abhängig vom Rest der Konfiguration, denn irgendwie klingt das komisch bzw. sieht es komisch aus) dafür sorgen, daß die FRITZ!Box "weiß", daß 192.168.3.97/24(?) ein lokaler Client ist - bei einem "Router" dann halt dadurch, daß man die "Route" dorthin über ein Gateway auf der LAN-Seite der FRITZ!Box definiert.

Vielleicht solltest Du die Konfiguration der FRITZ!Box dann doch noch etwas genauer beschreiben ... und zwar sowohl die "logische" (also die Einstellungen) als auch die "physikalische" (was ist das wo per Ethernet-Kabel angeschlossen).
 
Na bitte und danke sehr!

Das Häkchen vor "Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" fehlte - jetzt funktioniert alles wie's soll. War ja fast so einfach, wie'n Fritzchenwitz - ich hatte es befürchtet.
 
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.