[Problem] FRITZ!Fon App über VPN

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
Hallo zusammen,

ich brauche mal Hilfe.
Die App findet die FBF nicht.

Setup:
FBF 7270 aus der Signatur
Samsung Galaxy S plus (GT-I9001) mit Firmware 2.3.6
AVM FRITZ!Fon App Labor 1.64

Status:
vpnc-Tunnel steht.
Die FBF lässt sich anpingen und die Weboberfläche aufrufen.
Mit CSipSimple kann ich mich an der Box anmelden und darüber telefonieren.
Nur die Fon App findet die Box nicht - selbst mit Angabe der IP nicht.
Der Haken in den erweiterten Einstellungen für Nicht-WLAN ist natürlich gesetzt.

Hat irgend jemand einen sachdienlichen Hinweis, z.B. ob die App ein Log schreibt und wenn ja, wohin?

Gruß
Claus
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
So,

dann antworte ich mal selbst.
Nach Auswertung mehrerer tcpdump-überwachter Tests habe ich eine starke Vermutung.
Die App sendet ein SSDP-discover-Paket an die Adresse 239.255.255.250:1900.
Wenn die FBF sich im gleichen Netzwerksegment befindet, antwortet sie mit einem OK.
Danach findet eine http-Unterhaltung der beiden statt.
Befindet sie sich nicht dort, sondern z.B. auf der anderen Seite des Tunnels, bleibt das discover-Paket unbeantwortet.
Selbst wenn ich in der App eine IP-Adresse angebe, unterhalten sich diese und die FBF zwar ganz intensiv über den Port 49000, aber ohne das gewünschte Ergebnis.
Das Problem tritt demnach eigentlich immer auf, wenn NAT im Spiel ist, da der NAT-Router üblicherweise die Pakete an die 239er-Adresse nicht in das Subnetz der FBF routet.
Da haben wir also mal eine Aufgabe für AVM...

Damit hätte ich zwar eine Antwort für das Problem, aber keine Lösung.

Gruß
Claus
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,771
Punkte für Reaktionen
32
Punkte
48
Ich kann dir nur sagen, dass die iPhone-App über den in iOS-integrierten VPN-Client telefonieren kann. Vielleicht liegts ja am VPN-Client, dass der nicht alle Pakete durchlässt? Hast du Alternativen?
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
Na ja,

da setzt der iOS-VPN-Client wohl die Default-Route um - dann kommen alle Pakete an der FBF vorbei, auch der SSDP-discover.
Aber ich steh nicht so auf angebissenes Obst.
Als Nächstes ist mal ein tcpdump auf der FBF dran - dann sehen wir weiter.
Viellleicht fehlt ja nur eine statische Route.
Alternativen brauche ich nicht - mit CSipSimple habe ich ja einen VoIP-Client, der mit der FBF spielt - nur halt ohne die Komfortfunktionen der App.

Gruß
Claus
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,771
Punkte für Reaktionen
32
Punkte
48
Ich meinte auch Alternativen für die VPN-Client. Warum sollte die default-Route auch nicht umgesetzt werden? Wenn ich mich in feindlichen fremden WLANs befinde, dann soll auch kein unverschlüsseltes Paket mehr durchgehen. Funktioniert denn die AVM-App, wenn du die default-Route manuell änderst?

PS: Bitte sachlich (=technisch) bleiben, einen Flamewar brauchen wir hier wirklich nicht.
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
einen Flamewar brauchen wir hier wirklich nicht.
Das liegt mir ferne - aber iOS hier ins Spiel zu bringen, hat halt was von Äpfeln mit kleinen grünen Männchen vergleichen...
Die Default-Route auf den Tunnel umzusetzen, ist keine wirklich gute Idee für mich, da sich dann ja alle Daten aus dem Internet über unseren schmalen DSL-Upload quälen müssten.
Richtig gut wäre die Lösung tatsächlich dann, wenn nur die Kommunikation mit der FBF durch den Tunnel gehen würde und der Rest über z.B. HS[DU]PA.
Obwohl, für das bisschen Traffic mit der FBF wäre das evtl. noch akzeptabel.
Das VPN lässt sich ja danach wieder abbauen.
Inhaltlich geht es an der Baustelle aber frühestens übermorgen weiter.

Gruß
Claus
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
So,
sehen wir uns das Ganze noch mal genauer an.
Zuerst das Handy.
Die oft gefundene Anweisung zum Überprüfen der Routen ergibt:
Code:
C:\Software\adb>adb shell ip route show
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Also nichts.
Ein Blick in die Hilfe - ip route help - zeigt schon mal, dass es "show" eigentlich gar nicht gibt und es "list" lauten müsste.
Egal, weil es zu keinem anderen Ergebnis führt.
Das muss auch so sein, solange man keine Datenverbindung aktiviert hat.

Nach Anschalten der WLAN-Verbindung sieht das schon anders aus:
Code:
C:\Software\adb>adb shell ip route list
192.168.102.0/24 dev eth0  proto kernel  scope link  src 192.168.102.111
default via 192.168.102.2 dev eth0
WLAN wieder aus und Paketdaten Datennetz aktivieren:
Code:
C:\Software\adb>adb shell ip route list
10.b.c.0/24 dev pdp0  proto kernel  scope link  src 10.b.c.d
default via 10.b.c.1 dev pdp0
Da stand natürlich nicht b.c.d, aber die IP-Adresse von meinem Handy möchte ich jetzt gerade mal nicht öffentlich verbreiten, auch bzw. gerade weil es eine private des Netzbetreibers ist...

Wo ich schon mal dabei bin - nach Aktivieren von OpenVPN sieht die Ausgabe so aus:
Code:
C:\Software\adb>adb shell ip route list
192.168.104.1 via 192.168.104.5 dev tun0
192.168.104.5 dev tun0  proto kernel  scope link  src 192.168.104.6
192.168.100.0/24 via 192.168.104.5 dev tun0
192.168.101.0/24 via 192.168.104.5 dev tun0
10.b.c.0/24 dev pdp0  proto kernel  scope link  src 10.b.c.d
default via 10.b.c.1 dev pdp0
Man sieht sehr schön, wie die Routen ins Netz hinter dem Tunnel gesetzt sind und die Default-Route auf dem GSM-Netz bleibt.

Jetzt mit vpnc statt OpenVPN:
Code:
C:\Software\adb>adb shell ip route list
10.b.c.0/24 dev pdp0  proto kernel  scope link  src 10.b.c.d
default via 10.b.c.1 dev pdp0
Hoppla, was ist das denn?
Die Pfeile auf dem Screen sind grün, aber keine Routen gesetzt?
Ein ping auf die FBF funktioniert aber einwandfrei...

Wie bekomme ich denn jetzt heraus, welche Interfaces aktiv sind?
Google bringt bei der Suche mit "android list network interfaces" u.a. einen Treffer in ein Blog mit der Information:
Code:
C:\Software\adb>adb shell ls /sys/class/net
lo
dummy0
usb0
sit0
ip6tnl0
pdp0
tun0
Aha, der Tunnel ist da - aber wo sind die Routen?

Nochmal die Ausgabe von "ip route help" studiert und siehe da:
Code:
C:\Software\adb>adb shell ip route list table all
80.130.1.d via 10.b.c.1 dev pdp0  table 20
10.b.c.0/24 dev pdp0  table 20  scope link
default dev tun0  table 20  scope link
10.b.c.0/24 dev pdp0  proto kernel  scope link  src 10.b.c.10
default via 10.b.c.1 dev pdp0
broadcast 10.b.c.0 dev pdp0  table local  proto kernel  scope link  src 10.b.c.10
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 192.168.101.201 dev tun0  table local  proto kernel  scope host  src 192.168.101.201
broadcast 10.b.c.255 dev pdp0  table local  proto kernel  scope link  src 10.b.c.10
local 10.b.c.10 dev pdp0  table local  proto kernel  scope host  src 10.b.c.10
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
unreachable default dev lo  table 0  proto kernel  metric -1  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 0
unreachable default dev lo  table 0  proto kernel  metric -1  error -101 hoplimit 255
Geht doch.
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
Jetzt die FBF:
Code:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
80.130.1.d      *               255.255.255.255 UH    2      0        0 dsl
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.101.201 *               255.255.255.255 UH    2      0        0 dsl
192.168.101.0   *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl
Mist, weil die Route zum VPN zeigt direkt auf dsl und nicht auf ein eigenes Interfaces.
Damit dürfte es nicht möglich sein, die unverschlüsselten Pakete zu loggen, die durch den Tunnel kommen und gehen - schade eigentlich.

Gruß
Claus
 

paulkir

Neuer User
Mitglied seit
29 Mrz 2008
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
Hi,

ich hatte das gleiche Problem und einige Tage herumgedoktert. Die App mehr mals neu installiert bist ich eine Hinweis bei der installation des Apps gefunden habe:
Bei den Einstellung im App und dann unten links, da wo bei den meisten Apps die Einstelungen sind, ist ein Menupunkt "Erweitert". Das muss aktiviert sein um auch über VPN sich mit der FritzBox verbinden zu können.

Ich hoffe es hilft!
Gruß Paul
 

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
108
Punkte für Reaktionen
0
Punkte
16
Ich zitiere mich mal selbst - aus dem allerersten Beitrag:
Der Haken in den erweiterten Einstellungen für Nicht-WLAN ist natürlich gesetzt.
Gruß
Claus
 

schnappi

Mitglied
Mitglied seit
15 Jan 2005
Beiträge
281
Punkte für Reaktionen
0
Punkte
16
Hallo,

wie hast du es geschafft, dass CSipSimple funktioniert? Ich kämpfe gerade mit diesem Problem http://www.ip-phone-forum.de/showthread.php?t=236134 und es scheint aussichtslos.
Wird bei deiner VPN Konstellation der gesamte Datenverkehr über deinen PC/Fritzbox umgeroutet?
 

Zurzeit aktive Besucher

3CX

Statistik des Forums

Themen
238,144
Beiträge
2,107,286
Mitglieder
360,761
Neuestes Mitglied
dermarc.at

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via