[Gelöst] Fritz!Box als Registrar - kein Rufton, kein Gespräch möglich, Klingeln klappt!

[Friedrich]

Ich plage mich seit einiger Zeit mit folgendem Problem, ohne einer Lösung näher zu kommen:
Ich habe über OpenVPN eine Fritz!Box 7320 (Client ist die Box selbst) an einer Fritz!Box 7170 (die als Router für das heimische Netzwerk und auch als VPN-Server dient) als IP-Telefon registriert. Die erfolgreiche Registrierung wird in beiden Boxen angezeigt. Die ausgehenden Anrufe (der 7320) sollen über eine der an der 7170 registrierten VOIP-Nummern geführt werden.
Wenn ich nun vom an die 7320 angeschlossenen Analog-Telefon einen Anruf starte, höre ich kein Freizeichen, es klingelt aber an der Gegenstelle. Nach dem Abheben der Gegenstelle kommt jedoch kein Gespräch zustande. Beim Anruf "von außen" ist es genau umgekehrt.
Nach meiner Einschätzung sollte bei dieser Konfiguration keine Portweiterleitung notwendig sein, denn die beiden Boxen sind ja via VPN verbunden und die Kommunikation mit der Außenwelt übernimmt (zumindest in Bezug auf VOIP-Telefonie) die 7170.
Ich bin für jeden weiterführenden Tip dankbar.

Friedrich

 

[informerex]

kenn mich mit OpenVPN nicht aus
Sip-Server AVM
AVM VPN
Mini-Howto: Kompletten Internetverkehr über AVM VPN routen

 

[Friedrich]

Hallo Informerex, Dank für die schnelle Antwort. Ich habe die VOIP-Verbindung der beiden Boxen exakt nach der ersten Anleitung noch einmal aufgesetzt. Leider kein Erfolg - unverändert kein Ruftton, am anderen Ende klingelt es, ein Gespräch kommt aber nicht zustande. Einziger Unterschied ist (vielleicht hatte ich vorher aber nur nicht so darauf geachtet) wenn der Angerufene aufhängt, höre ich das Besetztzeichen.
AVM-VPN kann ich leider nicht mehr ausprobieren. Wegen Problemen in der Vergangenheit bei der Einrichtung von Linux-Clients bin ich auf OpenVPN umgestiegen und habe beim "Freetzen" der Boxen aus Platzgründen AVM-VPN entfernt. Mit OpenVPN sind die Boxen (7320 ist 192.168.0.3 - 7170 ist 192.168.1.1) bisher problemlos verbunden gewesen. Auf beiden sind die Ports 0 (udp und tcp), sowie der Port 5060 (udp) auf die jeweilige Box (0.0.0.0) umgeleitet. An der 7170 bestehen zusätzlich Portweiterleitungen für tcp 80 (zum http-Server) und udp 1194 (zum OpenVPN-Server 0.0.0.0). Die IP-Telefonie im Heimnetz (7170) funktioniert damit hervorragend. Müssen jetzt zusätzlich weitere Ports geöffnet werden?

Friedrich

 

[Friedrich]

Ich fürchte, vom Gedanken an fehlende offene Ports an der Fritz!Box zuhause (7170, das ist die, über die alle Telefonate der Familie laufen) muß ich mich verabschieden: Ich habe das in dieser Box eingerichtete IP-Telefoniegerät (welches durch den OpenVPN-Tunnel mit der 7320 verbunden ist) den ausgehenden Ruf über den Festnetzanschluss führen lassen - das Ergebnis ist dasselbe wie bisher. Allerdings spielen bei dieser Konfiguration die Ports der 7170 zu DSL doch wohl keine Rolle mehr.
Ich werde irgendwie aus der Sache nicht schlau.

Friedrich

 

[Friedrich]

Ein zwischenzeitlich gemachter Versuch mit einer auf der 7320 eingerichteten VOIP-Nummer war nach Einrichtung einer Portweiterleitung auf der 7170 (udp-Port 5061->Ip-Adresse der 7320) und einer Portweiterleitung auf der 7230 (udp 5061->5060) erfolgreich - Telefonate in beide Richtungen funktionierten. Allerdings strebte ich ja eine andere Lösung an, da ich am 2. Wohnsitz unter der Woche die Flatrate in meiner Hauptwohnung nutzen wollte.
Daher habe ich als letzten Versuch OpenVPN nicht als Tunnel, sondern als Brücke konfiguriert. Das hatte leider den Nachteil, dass ich den DHCP-Server am 2. Wohnsitz deaktivieren musste und das gesamte dortige Netz auf feste Adressen im gleichen Netz wie zu Hause konfigurieren musste. Und plötzlich funktionierte alles wie von Anfang an vorgesehen!
Ich nehme daher an, dass abweichend vom üblichen Sip-Verfahren die Umsetzung durch den Registrar der Fritz!Box teilweise auf Broadcasting beruht. Ich hatte darüber nirgendwo etwas gefunden.
Irritierenderweise war jetzt aber die OpenVPN-Verbindung nicht mehr so stabil wie zuvor. Nach Verbindungsabbrüchen wurde sie nicht von selbst wieder aufgenommen. Momentan scheint es aber so, dass auch dies Problem durch das Hinzufügen der Parameter ping-timer-rem;persist-key;persist-tun;push "ping-timer-rem" zur Server-Konfiguration zu beheben war.

Friedrich