[Problem] FritzFon App durch OpenVPN

prostream

Neuer User
Mitglied seit
3 Nov 2016
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
Hey zusammen,

ich betreibe zuhause einen nethserver als Router in einer Virtual Appliance auf einem Proxmox Node. Hierauf läuft ebenfalls ein OpenVPN Server, durch welchen ich mich mit meinem iPhone ins Heimnetzwerk einwähle.
Im Heimnetz steht noch eine Fritzbox 7490 als Wlan AP und VoIP Telefonanlage.

Ich versuche nun mich durch den OpenVPN Tunnel mich mit der FritzFon App auf die Fritzbox zu verbinden. Leider schlägt dies immer mit dem Fehler "Die Anmeldung des Telefoniegerätes an der FRITZ!Box ist gescheitert. Fehlerwert "404". In den Einstellungen habe ich bereits die IP Adresse und nicht den Hostname eingetragen. Im LAN funktioniert es einwandfrei.

Hat jemand schon ein ähnliches Problem gehabt? Alle anderen Geräte funktionieren über den OpenVPN Tunnel. Außerdem lässt sich die Fritzbox auch anpingen durch den Tunnel.

Kann es eventuell daran liegen, dass ich aus dem OpenVPN Netz versuche mich zu verbinden? Dieses Netz ist der Fritzbox ja nicht bekannt sondern nur meinen Nethserver.
Netz OVPN: 10.1.1.0
LAN Netz: 192.168.177.0
 
Zuletzt bearbeitet:
Der OpenVPN Server protokolliert den Verbindungsaufbau seiner Clients. Warum ist der TE nicht in der Lage diese Informationen zu nutzen?

Stellt diese App überhaupt eine Verbindung zum OpenVPN Server her?

Wenn ja, wie ist der Status?
 
Zuletzt bearbeitet:
Also, da der TE nicht mehr aktiv zu sein scheint und ich vor einem ähnlichen Problem steht erlaube ich es mir mal meine openvpn.log hier zu posten. So sieht es bei mir aus, wenn ich mich mit meinem iPhone einwähle:


Code:
Fri Nov  4 13:35:39 2016 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: CMD 'status'
Fri Nov  4 13:35:39 2016 MANAGEMENT: TCP recv error: Connection reset by peer
Fri Nov  4 13:35:39 2016 MANAGEMENT: Client disconnected
Fri Nov  4 13:35:43 2016 event_wait : Interrupted system call (code=4)
Fri Nov  4 13:35:43 2016 OpenVPN CLIENT LIST
Fri Nov  4 13:35:43 2016 Updated,Fri Nov  4 13:35:43 2016
Fri Nov  4 13:35:43 2016 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
Fri Nov  4 13:35:43 2016 ROUTING TABLE
Fri Nov  4 13:35:43 2016 Virtual Address,Common Name,Real Address,Last Ref
Fri Nov  4 13:35:43 2016 GLOBAL STATS
Fri Nov  4 13:35:43 2016 Max bcast/mcast queue length,0
Fri Nov  4 13:35:43 2016 END
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 TLS: Initial packet from [AF_INET]2.247.251.15:33660 (via [AF_INET]130.255.126.51%ppp0), sid=df0299fd 66697f41
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 CRL CHECK OK: CN=NethServer, O=Example Org, ST=SomeState, OU=Main, [email protected], C=--, L=Hometown
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 VERIFY OK: depth=1, CN=NethServer, O=Example Org, ST=SomeState, OU=Main, [email protected], C=--, L=Hometown
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 CRL CHECK OK: C=--, ST=SomeState, L=mycity, O=NET01, OU=Private, CN=, emailAddress=admin@NET01
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 VERIFY OK: depth=0, C=--, ST=SomeState, L=mycity, O=NET01, OU=Private, CN=, [email protected]
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Nov  4 13:38:47 2016 2.247.251.15:33660 [myname] Peer Connection Initiated with [AF_INET]2.247.251.15:33660 (via [AF_INET]130.255.126.51%ppp0)
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 MULTI_sva: pool returned IPv4=10.1.1.6, IPv6=(Not enabled)
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 MULTI: Learn: 10.1.1.6 -> myname/2.247.251.15:33660
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 MULTI: primary virtual IP for myname/2.247.251.15:33660: 10.1.1.6
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 PUSH: Received control message: 'PUSH_REQUEST'
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 send_push_reply(): safe_cap=940
Fri Nov  4 13:38:47 2016 myname/2.247.251.15:33660 SENT CONTROL [myname]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DOMAIN mydomain,dhcp-option DNS 10.1.1.1,dhcp-option WINS 10.1.1.1,dhcp-option NBDD 10.1.1.1,dhcp-option NBT 2,route 192.168.177.0 255.255.255.0,route 10.1.1.0 255.255.255.0,topology net30,ping 20,ping-restart 120,ifconfig 10.1.1.6 10.1.1.5' (status=1)
Fri Nov  4 13:39:39 2016 myname/2.247.251.15:33660 SIGTERM[soft,remote-exit] received, client-instance exiting

Wenn ich dann versuche mich über die App zu verbinden bekomme ich in die Fehlermeldung: Die Anmeldung des Telefoniegerätes an der FRITZ!Box ist gescheitert. Fehlerwert "404"
Im Ereigniss Protokoll der Fritzbox erscheint: Anmeldung einer App des Benutzers .... von IP-Adresse 10.1.1.6

Wäre der Fritzbox dieses Netz bekannt wäre es vermutlich gar kein Problem, oder?
 
@prostream:
Dank Deiner sehr kurzen Schilderung des Problems (die nicht unbedingt der Präzision derselben geschuldet ist), kann man da einfach nicht helfen ... in gewisser Weise steht (wenn man raten muß, kann man auch daneben liegen) die Lösung bereits in diesem Thread:
HabNeFritzbox schrieb:
Klar, fremdes Subnet ist Internet [...]
Man kann also unterstellen (mangels gegenteiliger Information), daß bei der Konfiguration des Telefoniegerätes (schon die Frage, ob das von Hand eingetragen oder automatisch von der App über TR-064 eingereicht wurde, ist unbeantwortet ... aber u.U. entscheidend) der Zugriff aus dem Internet nicht erlaubt ist. Da Du ohnehin Deine FRITZ!Box für die Verwendung von OpenVPN modifizieren mußtest und diese Konfiguration ebenfalls im Dunkeln bleibt, wirst Du Dir wohl selbst helfen müssen.

Wenn der verwendete TAP-Adapter Bestandteil der "lan"-Bridge in der FRITZ!Box ist, sollte diese eigentlich die dahinter befindlichen Adressen als "lokal" anerkennen - aber auch das bleibt Spekulation.

Insgesamt ist das wohl eher ein Problem, welches nach "Freetz" gehört und wenn man selbst ein aktuelles Problem hat, ist es zwar "best practice", sich erst einmal nach bereits vorhandenen Lösungen umzusehen, aber die Wiederbelebung solcher Zombies ist dann trotzdem (meines Erachtens) nur die zweitbeste Lösung. Erst recht die Feststellung bei einem VPN-Thema, man hätte "das gleiche Problem" - daß es das nicht ist, sieht man schon daran, daß bei Dir andere IP-Adressen verwendet werden, auch wenn die konkrete Adresse sicherlich nicht das Problem ist, sondern die Konfiguration "rundherum" und gerade zu dieser fehlen praktisch alle Informationen; daran ändert auch das Protokoll nichts.

Wenn man Dir wirklich (effektiv und ohne ständiges Nachfragen, wozu vermutlich auch niemand so richtig Lust hat) helfen soll, mach' einen eigenen Thread auf (ich würde hier tatsächlich eher nach "Freetz" wandern und dort aber deutlich machen, daß es sich um ein "Anwendungsproblem" des OpenVPN-Paketes handelt und nicht um ein Problem des Pakets selbst) und beschreibe dort haarklein Deine verwendete Konfiguration. Das geht beim Modell der verwendeten FRITZ!Box los, zieht sich über die Angabe der verwendeten FRITZ!OS-Version und der ausgeführten Modifikationen bis zur Beschreibung, welche FRITZ!App verwendet wird (auch wenn hier die FRITZ!App Fon Thema ist, wird sich kaum jemand vom neuen Thread aus auf diesen verweisen lassen und auch von der App gibt es verschiedene Versionen für unterschiedliche Plattformen mit unterschiedlichen Einstellungsmöglichkeiten - die Information "iPhone" erfolgt auch eher "nebenbei" und nicht einmal spezifisch auf die App bezogen, sondern auf die VPN-Verbindung) und wie diese letzten Endes an der FRITZ!Box registriert ist bzw. wie dieses Telefonie-Gerät eingerichtet wurde. Der krönende Abschluß sind dann die Protokolle der VPN-Verbindung zum Zeitpunkt des Fehlers und die (exakten, mit Uhrzeit) Fehlermeldungen der FRITZ!Box, damit man diese den Ereignissen im VPN-Protokoll zuordnen kann.

Das klingt nach fürchterlich vielen "Hausaufgaben" ... es erspart aber ständiges "Ping-Pong" im Frage-/Antwort-Spiel und am Ende ist es auch nicht ganz unerheblich, ob man die notwendigen Informationen für eine gezielte Antwort in einem Beitrag findet oder erst den ganzen Thread dafür studieren muß. Es mag zwar immer wieder auch die Notwendigkeit von Nachfragen geben, aber wenn ein Versuch der Problemlösung gleich damit starten soll, daß man sich erst einmal selbst die notwendigen Informationen "erfragt" (auch solche Anworten wie "Du hättest halt (nach)fragen müssen ..." gibt es ja und da verkennt der TE meist, wer das zu lösende Problem hat und damit derjenige sein sollte, der die größeren Anstrengungen (von sich aus) investiert), dann wird man als Fragesteller damit wenig Erfolg haben.

Wenn Du Dir andere Threads ansiehst, dann ist die Zeitspanne von > 24 Stunden ohne Antwort schon ziemlich lang ... meinerseits lag das daran, daß ich mir solche Texte wie diesen eigentlich abgewöhnen wollte. Nun habe ich das doch noch einmal aufgeschrieben und jetzt werde ich mir das auch als Bookmark hinterlegen - und in der Zukunft dann hierher verweisen.

Ich stehe mit meiner Meinung/Einstellung auch nicht so ganz alleine ... Du bist ja auch kein "Einzelfall". Eine recht gute Zusammenfassung der wichtigsten Punkte findet man hier (auch davor und danach können viele Fragesteller etwas lernen, denn das ist hier weder Facebook noch Twitter und die Gemeinsamkeiten eines solchen Bulletin-Boards und einer Mailingliste (für die das mal geschrieben wurde) sind deutlich größer):

https://tty1.net/smart-questions_de.html#beprecise

Auch die Hinweise für eine eigene Fehlermeldung (der letzte Absatz im verlinkten Punkt) sollte man einfach einmal gelesen haben ... in der Regel wird man dann deutlich schneller "bedient". Man darf nie vergessen, daß es auch den Antwortenden Zeit kostet (und die ist eben bei den meisten die deutlich knappste Ressource), wenn er sich das alles erst "erfragen" muß (oder gar soll nach der Ansicht von Einzelnen) und dann wendet der sich vielleicht einem anderen (besser beschriebenen) Problem zu.
 
Der OpenVPN Server läuft auf einem Host ABC im LAN und nicht auf der eierlegenden Wollmilchsau. Richtig?

Läuft der Server mit TUN/TCP? Wie sehen die Routen auf den beteiligten Hosts aus?

Das OpenVPN sollte korrekt eingerichtet sein bevor man sich dem Telefonkram zuwendet.
 
Der OpenVPN Server läuft direkt auf meinem Router (NethServer release 6.8 (Final)). Der OpenVPN Server läuft über TUN/TCP ja.


Ein "route":


route.jpg

Dazu sollte man noch wissen, dass im Hintergrund noch ein ipsec Tunnel zu einem weiteren Netzwerk (192.168.179.0.) steht.
 

Anhänge

  • route.jpg
    route.jpg
    52.2 KB · Aufrufe: 17
Zuletzt bearbeitet:
Das Bild der Route passt aber nicht zur Fritzbox, die muss ja eine Route haben zu deinem extra Router der als Gateway angesprochen wird und so dann durch VPN leiten kann.

Zudem wird 192.168.179.0 von der FB als Gastnetzwerk verwendet, kann also auch zum Konflikt werden.
 
Zuletzt bearbeitet von einem Moderator:
Ich habe eine Route in der Fritzbox angelegt. 192.168.177.6 ist hierbei mein Linux Router.

route2.jpg

Funktionieren tut der Verbindungsaufbau trotzdem noch nicht.
 
Schon mal IP-Telefon gelöscht, und durch App neu erstellen lassen?
 
Ja, auch schon versucht. Leider ohne Erfolg.
 
Ich habe dann zumindest keine Idee mehr, bei mir läuft die Fon App unterwegs sowohl IPsec als auch openVPN (Standard mit UDP) Tunnel auf dem NAS mit jeweils anderem Subnet für jeden VPN Typ.
 
Wie sieht denn Deine Route auf der Fritzbox dafür aus?
 
So wie bei dir, bloß halt nur 3 Routen, für jeden VPN Typ ein Subnet mit dem NAS als Gateway.

Verwende aber auch nicht das 10er Netz, da es sonst ggf. im Mobilfunk Konflikte geben kann.
 
Welche Rolle spielt denn eigentlich die eierlegende Wollmilchsau in deinen Szenarium?

Wer macht die Portweiterleitung zum OpenVPN Server (TUN device/TCP-Port yxz)?

Das "default gateway" auf dem Linux Server ist ppp0.
 
@HabNeFritzbox:
Habe testweise das VPN Netzwerk auf 172.16.0.1 geändert und die Route entsprechend angepasst, leider ohne Erfolg. Habe außerdem die App auch mal neu installiert. Zu Anfang bekomme ich dann eine endlose Abfrage des Passworts. Wenn ich das Anmelde Szenario in der Fritzbox dann von "Anmeldung mit dem FRITZ!Box-Kennwort" auf "Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort" ändere bekomme ich wieder die 404 Fehlermeldung.

@grauGolz:
Was genau meinst du mit "eierlegende Wollmilchsau"? Die Portweiterleitung übernimmt mein Router (Nethserver). Das Default Gateway ist ja auch richtig. An dem ppp0 Adapter hängt direkt meine Glasfaserleitung.
 
Der trollt manchmal ganz gern, gemeint ist die FB.

Ich benutze keine Benutzer, sondern nur Passwort so wie man es von früher kennt.

Wenn der Nethserver der Router ist ins Internet, und du bei der FB auch Routen eintragen kannst, läuft diese als Router, und damit ist das Nethserver Netz ein fremdes, und damit wäre App Zugriff aus dem Internet, und dann normal, dass es nicht geht.

Besser wäre dann die FB IP Client, mit ner IP vom Nethserver Netz, oder halt Zugriff aus Internet gewähren.

Beim TE ist der VPN Server im Heimnetz der FB, bei dir scheint es was anders zu sein, weil was geschrieben hattest mit gleiche Problem.
 
Zuletzt bearbeitet von einem Moderator:
Der OpenVPN Server läuft direkt auf meinem Router (NethServer release 6.8 (Final)).
Dann ist das aber nicht einmal im Ansatz witzig, was Du da geschrieben hast:
prostream schrieb:
Jemand hierzu schon neue Erfahrungen? Stehe vor dem gleichen Problem.
Da hast Du also tatsächlich einen Thread gefunden, bei dem es sich um eine FRITZ!App und OpenVPN dreht? Und da hängst Du Dich dann ran und behauptest, Dein Problem wäre das gleiche? Nicht einmal "ähnlich" oder irgendetwas in der Richtung? Da war Dein erster Beitrag (und Dein neuer Thread) trotz ebenfalls extrem spärlicher Fakten und falschem Unterforum ja deutlich informativer und origineller.

Vielleicht denkst Du ja doch noch einmal nach - an meiner Erklärung in #15, was man alles als Information benötigt, hat sich ja nichts geändert. Hier findet sich immer noch keine einzige Information, welche FRITZ!OS-Version auf welchem Modell eingesetzt wird und das gleiche gilt für die FRITZ!App.

Da der "voipd" (das ist der Daemon auf der FRITZ!Box, der die Anmeldung der App ablehnt) nicht einfach blind anhand der Routing-Tabelle die Daten irgendwohin schickt, sondern für den die Bindung an verschiedene Netzwerkschnittstellen möglich ist (und alles, was dann auf dem falschen Interface kommt, ist im Prinzip ein Angriffsversuch), bin ich ja mal gespannt, wann (eher ob) Du das auf die Reihe bringen wirst. Daß der SIP-Server auf der FRITZ!Box da zusätzliche Maßnahmen zur Prüfung der Gültigkeit einer Anmeldung durchführen muß (der ist ja auch von extern erst einmal theoretisch zu erreichen und muß es zunächst mal für allen SIP-Traffic sein, das wird erst anhand des Inhalts klar, ob das eine gültige Anforderung ist oder nicht) und diese sich auch mal geändert haben in Anhängigkeit von der FRITZ!OS-Version, sollte jedem ebenso einleuchten wie die Notwendigkeit passender Protokolle (und sei es das der SIP-Kommunikation des "voipd" mit dem REGISTER-Paket und den Antworten für die abgelehnte Anmeldung).

Wenn Du das irgendwann mal begriffen hast, werden wir ja vielleicht an anderer Stelle mal einen "richtigen Thread" von Dir zu diesem Thema finden ... warum hier am Routing herumgedoktert werden soll, wenn doch die VPN-Verbindung nach der Fehlermeldung aus #14 gar nicht das eigentliche Problem ist, wird man dann ja vielleicht auch erkennen können.

Vorsicht, es kommt jetzt eine Begründung, die sollte man ggf. überlesen, wenn man so wie bisher weitermachen will und sich auch weiterhin etwas davon versprechen will: Da die FRITZ!App Fon normalerweise TCP (statt UDP) für die SIP-Kommunikation verwendet, ist schon der in der FRITZ!Box protokollierte Versuch der Registrierung das deutliche Zeichen dafür, daß IP-Pakete (zumindest gilt das für TCP auf L4) in beiden Richtungen ihr Ziel erreichen, weil die Anmeldung erst nach dem 3way-Handshake für TCP übertragen und damit später auch protokolliert werden kann.

Aber vielleicht kannst Du uns ja auch (plausibel) erklären, inwiefern das Problem dann etwas mit dem Routing anstelle des "falschen Interfaces" für den "voipd" zu tun haben soll - überrasche mich.

Bisher haben wir hier in diesem Thread sechs Beiträge von Dir mit - optimistisch geschätzt - vier Fakten und die muß man sich auch wieder über mehrere Beiträge zusammensuchen. Da hat der andere Thread (auch wenn der im Thema "DSL, Internet und Netzwerk" steht und es sich hier streng genommen um ein Crossposting innerhalb von weniger als 30 Minuten handelt - und das, obwohl das Abnicken der Forenregeln noch nicht so sehr lange zurückliegen dürfte bei Dir) dann weitere "Bröckchen", die wir gefällist selbst mit den hier vorhandenen Informationen (Routing-Eintrag in der FRITZ!Box, VPN-Protokoll des Servers und Anzeige der Routing-Tabelle Deines Routers) in Verbindung bringen können, wenn wir Dir wirklich helfen wollen. Das ist ja schließlich das Mindeste, was jemand an eigener Initiative zeigen sollte, wenn er Dir eine fundierte(re) Antwort geben will.

Als ich #15 schrieb, hatte ich noch die Freundlichkeit gegenüber Newbies im Blick, jetzt drängt es mich nach deutlicheren Worten - aber ich muß hier ja tatsächlich nicht weiter lesen (oder schreiben), wenn es am Ende nur auf Zeitverschwendung hinausläuft und wenn ich mit Diesem Beitrag hier Deine Zeit verschwende, machst Du das eben genauso mit der Zeit vieler anderer Leser, die sich durch diesen Käse hier kämpfen werden - und das ohne jede (begründete) Aussicht auf Erfolg, wenn das hier so weiter gehen sollte.

Trotzdem drücke ich die Daumen ...
 
Zuletzt bearbeitet:
Wenn die eierlegenden Wollmilchsau als IP-Client genutzt wird, eine sehr empfehlenswerte Betriebsart, sind natürlich zusätzlich zum "default gateway"
keine statischen Routen zum OpenVPN-Tunnelnetzwerk nötig.

Ich nehme an, daß auch im IP-Client-Modus die Fon App genutzt werden kann. Ich verwende auch ein AVM-Teil in dieser Betriebsart.
Das ist aber aus der Steinzeit und somit kann ich damit nichts testen.

Hinweis zu OpenVPN:

Heute sollte man statt "topology net 30" (veraltet, wird nur wegen uralter Windos-Clients noch unterstützt) stets "topology subnet" verwenden.
Das wird zwar das eigentliche Problem nicht lösen, ist aber zukunftssicherer.

Damit ziehe ich mich aus diesem Thema zurück und übergebe an die Experten aus der AVM-Fraktion. Dort gibt es sehr schlaue und hilfsbereite Köpfe.

Viel Spaß mit OpenVPN wünscht der

grauGolz
 
Kostenlos!

Statistik des Forums

Themen
248,922
Beiträge
2,305,230
Mitglieder
378,646
Neuestes Mitglied
atrora