[gelöst] Problem mit Fritz!App Fon über VPN (Wireguard)

Peter_Lehmann

Mitglied
Mitglied seit
13 Mrz 2007
Beiträge
662
Punkte für Reaktionen
260
Punkte
63
Hallo Freunde!

Vorbemerkungen:
Ich betreibe seit vielen Jahren (oder: seit AVM das anbietet) auf allen meinen eigenen und zur Wartung/Hilfe "übernommenen" F!B als einzigen Zugang ins Heimnetz je ein bis 8 (AVM-)VPN. Alles, von Fernadministration bis Datensicherung funktioniert, wenn man mal vom geringen Durchsatz absieht, prächtig. Und natürlich nutze ich das VPN zusammen mit der Fritz!App Fon auch zur außerhäusigen "Verlängerung" meines Telefonanschlusses.

Wegen der immer größer werdenden Diskrepanz zwischen der in den Jahren stetig gestiegenen Upload-Bandbreite der DSL-Anschlüsse und dem geringen Durchsatz auch der neueren F!B (und auch, weil ein VPN auf einem vom Hersteller und Provider möglicherweise überwachbaren Gerät eigentlich ein "no go" ist) betreibe ich jetzt hinter einigen "meiner" F!B einen Wireguard-Server auf Raspberry Pi.
Das VPN startet blitzartig, bricht selbst beim Wechsel der Verbindung der Clients zwischen WLAN - Mobilfunk usw. nicht zusammen, ist also super stabil und es lastet die jeweilige Upload-Bandbreite fast vollständig aus.
Alles, was ich bislang mit dem IPsec-VPN vom AVM gemacht habe, funktioniert weiterhin. Nur schneller und stabiler!

Problem:
Alles - bis auf das Telefonieren <= jetzt komme ich zum eigentlichen Problem!
Die Fritz!App Fon verbindet "blitzartig" (also genau so schnell wie im heimischen WLAN) mit der F!B. Beide Balken grün.
Ich kann das Adressbuch und die Anrufliste sehen. Wenn ich einen Anruf tätige, wird dieser in der F!B in der Anrufliste eingetragen und ich bekomme wie gewollt eine Mail.
Aber es kommt kein Gesprächszustand zustande. Noch nicht einmal der Freiton wird übertragen.
Mehrfaches komplettes Löschen der Verbindung (in der F!B und auf dem Smartphone) und Neuanmeldung der F!B ändern nichts an der Situation.
Selbstverständlich kann ich mit einer alternativen App (ZoiPer und CSipSimple) abgehend und ankommend über das wireguard-VPN telefonieren.

Nun frage ich mich, was kann das AVM-VPN, was Wireguard nicht kann? Oder, was verlangt die AVM-App, was ich ihr nicht geben kann?

Ich will natürlich keinen Krampf draus machen (die Alternative habe ich ja schon erwähnt), aber ich würde es schon gerne wissen. ;-)


Vielen Dank fürs Lesen und auch für helfende und zielführende Beiträge!

MfG Peter
 
AVM-VPN: VoIP immer über WAN, auch bei IPSec | Wireguard: VoIP über LAN auf Sicht der Box, 'hint' in 'voip.cfg' (sipiface) konfig'en.


135 Byte
 
Moinsen


Closed Source kann die Fon APP
:rolleyes: ( Reverse Engineer, wo bist du ? )

Das die APP aber mehr als nur VoIP macht,
mit der vom Provider überwach/steuerbaren Box,
dafür gibts auch ne APP...
ConnectBot,
lokale Sitzung starten und...
In die APP Fon wechseln,
ins Telefonbuch schauen,
in Anrufliste gucken,
und danach wähle mal: **797 ( 2:41, gratis in HD ;) )
...schnell zu ConnectBot wechseln,
und vorher eingetipptes Kommando losschicken: netstat -tupe
( Obiges gilt für Android mit entsprechender busybox* )


* HUAWEI /system/bin/toybox :cool:
 
Zuletzt bearbeitet:
WIe sieht deine Netzwerk Konfiguration aus?
Nach meinen Experimenten hüllt sich der voipd in eisernes Schweigen, sobald eine FritzFon App mit ihm von einem andernen Subnetz aus kommunizieren will.
 
Wenn VPN anderes Subnet hat, ist Verhalten normal. Dazu habe ich mehrfach in anderen Themen schon was geschrieben. Es ist eine Route zu setzen.
 
In meinem Fall gehe ich davon aus, dass das Routing korrekt ist. Alle anderen Dienste auf der Box selbst und in dem angeschlossenen Netz sind wechselseitig erreichbar. Der voipd schweigt einfach, sobald die Anfrage eine IP Adresse aus einem anderen Subnetz hat. Ich vermute, es ist Absicht.
 
Du gehst von aus? Also bist dir nicht sicher. ;)

Die Subnets vom VPN sind also als Route in der FB eingetragen? Falls nicht - wovon ich ausgehe - laufen die UDP Paket Antworten entsprechend über WAN zum Internetprovider statt zum VPN.

Diverse andere Dienste nutzen wohl TCP und nicht UDP, wie erwähnt nicht neu, korrekt, und mehrfach schon in anderen Themen. Bei mir läuft es über fremde VPN Netze.

 
Code:
ip root@FB7490:/var/mod/root> ip route
default dev dsl scope link  metric 2
...
192.168.3.0/24 dev tun1 scope link  src 192.168.3.1
192.168.179.0/24 dev guest scope link  src 192.168.179.1
192.168.180.1 dev dsl scope link  metric 2
192.168.180.2 dev dsl scope link  metric 2
root@FB6790:/var/mod/root>

OpenVPN teilt den Clients eine IP aus dem Netz 192.168.3.0/24 zu. Ich weiß nicht, was noch fehlen soll.
 
voipd spricht wohl die IFs direkt an (s. SIP-Trace Supportdaten), daher die Zuweisung von sipiface_homenet bei Fremd-VPN über LAN.

[...]
 
Zuletzt bearbeitet von einem Moderator:
Habe ich doch mehrfach geschrieben, keine Route vorhanden.

Und da weder du noch Peter entsprechende Angaben macht, nutzt verlinkte Themen in Suche für Beispiele.

Wenn FB 192.168.178.1 hat und VPN im Heimnetz die 192.168.178.25 und vergibt im seinem Subnet dann 192.168.3.0/24 wäre in der FB die Route
1.jpg
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: pangul
voipd spricht wohl die IFs direkt an (s. SIP-Trace Supportdaten), daher die Zuweisung von sipiface_homenet bei Fremd-VPN über LAN.


Habe gerade in die voip.cfg geschaut. Die sipiface Angaben sind in den Abschnitte der "ausgehenden" Telefonnummern. Mein Problem betrifft aber die Telefoniegeräte (FritzApp Fon soll sich wie ein internes Handgerät verhalten).
Ich werde am Wochenende etwas damit spielen.



Habe ich doch mehrfach geschrieben, keine Route vorhanden.

Und da weder du noch Peter entsprechende Angaben macht, nutzt verlinkte Themen in Suche für Beispiele.

Wenn FB 192.168.178.1 hat und VPN im Heimnetz die 192.168.178.25 und vergibt im seinem Subnet dann 192.168.3.0/24 wäre in der FB die Route
Anhang anzeigen 101792

OK, Angaben fehlen in der Tat.

Ich benutze OpenVPN auf der Fritzbox selbst. Konkret:
Die Fritzbox hat 192.168.4.1 auf der LAN/WLAN Bridge und 192.168.3.1 auf der Tunnelschnittstelle.
Daran hängen jeweils die Netze 192.168.4.0/24 und 192.168.3.0/24.

Auf der FritzBox Oberfläche habe ich keine Routen eingetragen, sehr wohl aber auf dem Linux System selbst.

Die FritzApp Fon funktioniert problemlos aus dem WLAN, über OpenVPN nicht. Anderen Dienste tun übers VPN.

Ich werde am Wochenende den Einstellungen zum statischen Routing auf der AVM Oberfläche etwas Zeit widmen.
 
Ich habe meinen VPN nicht auf der FB und betreibe diese ohne Modifikation, da hier keine Angaben zu sind dass du Modifiziert hast, und auch nicht im Mod Thema steht, entsprechende Antwort halt. Zudem nutzt der TE sein VPN auf einem RasPi. Daher hast dir für Frage das Thema eher ungünstig ausgesucht.
 
OK, sipiface tatsächlich nur für UAs. Als Reg. antwortet der voipd auf dem IF, wo der Req. einging (siehe Trace, gibt extra die Angabe).
[...]

Ausserdem hilft Trace (showshringbuf in Supportdaten) bei Feststellung, ob überhaupt Daten von F!App ankommen und wo Antwort hingeht.
[...]
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: f666
Danke für die vielen Antworten. Ich sehe, dass die von mir gesuchte Ursache in diesen Antworten steckt.
Weitere Routen, nur um die Fritz!App Fon zu nutzen, werde ich allerdings nicht setzen. Habe ja die genannten Alternativen, wenn mir mal nach "mobiler Festnetztelefonie" ist. Das kommt, außer im Urlaub, selten genug vor.

@PeterPawn:
Könntest du bitte bei deiner ersten Antwort noch etwas deutlicher werden.
Bedeutet der erste Satz das, was ich daraus lese: der VOIP-Traffic geht beim AVM-VPN immer "barfuß" raus (also auch wenn der Gesprächspartner direkt am anderen VPN-Endpunkt sitzt)? Man sollte wohl grundsätzlich immer zuerst mal wireshark starten, wenn man ein VPN einrichtet und sich dann darauf verlässt.

MfG Peter
 
Wieso Route nicht setzen?

Ist doch einfach, und wird ja nur für VPN Subnet umgelenkt, nicht alles.
 
Zumindest hat der voipd seinen "eigenen Kopf" beim Routing und wählt - nach meiner Erfahrung - das Interface direkt, über welches er Pakete verschickt.

-------

Ich würde mir die SIP-Pakete der App genau ansehen bei der Fehlersuche, besonders event. "Via"-Header, die m.E. zum falschen IF bei der Antwort führen könnten.

-------

Andere Alternative wäre NAT fürs Wireguard-VPN - ext. (VPN-)Clients erscheinen unter der (VPN-)Gateway-Adresse im LAN.

-------

Letzteres geht ja auch selektiv für Zugriffe auf die FRITZ!Box oder gar nur für SIP und RTP zur FRITZ!Box.
 
Wieso Route nicht setzen?
Ist doch einfach, und wird ja nur für VPN Subnet umgelenkt, nicht alles.

Klar ist das einfach. Aber ich habe ja geschrieben, dass ich die Ursache wissen will - und dass ich dieses Feature sehr selten benötige und dann auch eine Alternative habe.
Ich habe einfach gegrübelt, warum es mit dem AVM-VPN geht und mit WG nicht. Jetzt weiß ich es Dank eurer Hilfe. (Hätte auch selbst draufkommen können - schäm)
 
Für UDP Pakete findet der (die FB) ohne Route den Weg zum VPN Server nicht und damit nicht zum Smartphone. Bei AVM VPN kennt der den Weg, daher klappt es dort.

Daher klappt Verbinden mit App oder die Webseite per TCP, aber eben keine Sprache zurück per UDP.
 
Zuletzt bearbeitet von einem Moderator:
Nochmals Danke.
Jetzt ist aber wirklich die alllllerletzte Unklarheit beseitigt.
 
Sorry, wenn ich mich hier nochmal einklinke...
Bin vielleicht nicht ganz so fit, wie Peter_Lehmann, aber für mich ist irgendwie noch keine Unklarheit beseitigt...
WO sollte man denn nun WAS eintragen, damit die Angelegenheit funktioniert?
HabNeFritzbox sagt: "Für UDP Pakete findet der (die FB) ohne Route den Weg zum VPN Server nicht "
Warum nicht? Die Box findet doch über den Wireguard-VPN (UDP-Port freigegeben zum Raspi!) auch den Weg zum Phone...
Mein Phone hat 'ne IP aus dem lokalen Adressbereich des Wireguard-Servers (10.10.10.0/24).
Wenn ich jetzt eine IPv4 Route zum Wireguard-Netz einrichten würde (10.10.10.0/24), dann kann ich ja die Fritzbox im lokalen Netz nicht mehr erreichen... Deshalb traue ich mich nicht, hier was einzutragen!
Vielen Dank für eine weitergehende Erhellung!
 
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.