OpenCom 150 mit VPN

[djrick]

Hallo,

Wir haben eine OpenCom 150 Telefonanlage und mehrere Mitarbeiter die an verschiedenen Standorten sind.

Jeder Mitarbeiter hat einen VPN Router in dem sein jeweilies VOIP Telefon / SIP Telefon steckt. Der VPN Router verbindet sich mit unserer Firma wo die Telefonanlage steht. Dadurch "finden" die Telefone die Anlage und können nach draussen telefonieren und angerufen werden.

Leider funkioniert das Telefonieren untereinander mit Hilfe der jeweilgen Durchwahl nicht. Die einzige Lösung die wir gefunden haben ist: Jeder User stellt zusätzlich zu jedem User auch eine VPN Verbindung mit dem VPN Router her. Dadurch findet jeder jeden und man kann auch untereinander telefonieren. Diese Lösung ist mit steigenen Mitarbeitern natürlich sehr unpraktikabel.

Kann man das irgendwie anders lösen? Gibt es in der Telefonanlage irgendwie die Option dass alle Gespräche (und damit auch die internen) über die Telefonanlage geleitet werden? Dann wäre die Strecke zwichen den internen Gesprächen länger aber man könnte sich jede Menge VPN Verbindungen sparen. Für jede andere Lösung wäre ich auch sehr dankbar

 

[neffs]

Kann man nicht in dem zentralen VPN Router einstellen, dass die eingewählten Netze auch untereinander Daten austauschen können? Dann geht es zwar auch 2x übers VPN, muss allerdings nicht über die Anlage.

Ich wüsste nicht wie man alles über die Anlage routet.

 

[djrick]

Das mit dem zentralen VPN Server habe ich mir auch schon überlegt.

Man sagte mir auch, dass es vielleicht auch so ginge, dass halt alle Gespräche und nicht nur die externen über die Anlage geroutet werden könnten.

Deswegen wollte ich lieber erst noch mal nachfragen bevor ich einen VPN Server aufsetze

 

[Balogh]

In einem voll verdrahtetem VPN-Netzwerk (fully-meshed VPN) besteht zwischen jedem Firewall-Paar eine Verbindung, was ziemlich wartungsintensiv ist. Umgehen kann man das mit einem VPN-Konzentrator (hub-and-spoke VPN), der alle Verbindungen zu den Aussenstandorten miteinander verknüpft (es gibt dann genau doppelt so viele Rules wie Firewalls) oder man löst es so, dass man auf der zentralen Firewall am Anlagenstandort eine einzige Rule erstellt, welche sich über alle IP-Adressbereiche alle Netze erstreckt. Die IP-Adressbereiche der Gegenstellen werden dabei nicht eingetragen, so dass es nur jeweils eine Rule mehr braucht als es Firewalls gibt.

Es ist mir nicht bekannt, dass mittels einer Einstellung sämtliche Gespräche in jedem Fall über die TVA geroutet werden könnten. Von der Logik her hat es mich schon immer verwundert, wieso überhaupt alle OpenPhone-Geräte zwangsläufig die Verbindungen untereinander haben müssen. Es wäre elegant, wenn die OpenPhone-Geräte, sobald sie sich untereinander nicht sehen, automatisch den Weg über die TVA suchten. Vielleicht ist das ja etwas Potential für den Release 10.

Mit bestem Gruss, Philippe

 

[djrick]

Zwichenzeitlich hab ich einen zentralen VPN Server aufgesetzt, der am Standort der Telefonanlage sitzt. Alle Clients verbinden sich per VPN zu diesem Server und jedes Telefon findet so jedes Telefon ohne eine direkte VPN Verbindung dorthin zu haben.

 

[Sam5000]

Hallo Balogh,

endlich ein Leidensgenosse (Leider)!
Ich hatte die Hoffnung schon aufgegeben.

Ich habe das gleiche Problem. Ich setzte seit Jahren bei meinen Kunden Router der Firma Bintec (jetzt Funkwerk) ein. Diese verbinden Standorte per VPN über IPsec.

Die Tunnel laufen einwandfrei, keinerlei Programme (z.B. RDP) haben Probleme.
Die IP-Systemtelefone OpenPhone 6x und 7x, sowie die Softphones haben alle
während Gesprächen eine gute Sprachqualität und keinerlei Probleme, ausser....

Nach einer nicht genau definierbaren Zeit der "Nichtbenutzung", schlafen die Geräte ein.
D.h., dass Telefon steht auf dem Tisch und erweckt den Anschein das alles OK ist,
aber es kommen keine Rufe mehr an und wenn man selbst Telefonieren will passiert nichts. Manchmal bemerkt das Gerät dann seine "Nichtfunktion" und macht einen Neustart. In der Regel muss man diesen jedoch durch "Stromsteckerziehen" herbeiführen.

An dieser Stelle die Bemerkung: Die DECT over IP Basis und auch die Aastra 5x SIP Telefone funktionieren einwandfrei und zwar zur selben Zeit, über den selben Tunnel!!??

Die DeTeWe-Hotline meinte, ich solle den Netzwerkverkehr mit Wireshark aufzeichnen und Ihnen zur Auswertung zukommen lassen.

Da ich mich mit Protokollanalyse aber bislang nicht beschäftigt habe, fehlt mir momentan die Zeit das erforderliche Scenario aufzubauen und diese Geschichte durchzuführen.

Ich habe das auch schon mit der Routerkonstellation:

Bintec <-> Bintec
Bintec <-> Zywall USG100
Bintec <-> Lancom

getestet und zwar mit dem gleichen, schlechten Ergebniss.

Wenn Du jetzt sagst, dass es mit Zyxel <-> Zyxel auch nicht geht,
dann kann ich Bintec wohl nicht mehr die Schuld geben und eher das Problem
im DeTeWe Verbindungsprotokoll suchen.

Der Gedankengang ist inzwischen soweit gereift, dass das Problem durch die in den
Routern vorhandene SIF (StatefullInspectionFirewall) hervorgerufen wird.

Laienhaft ausgedrückt würde ich annehmen, die SIF macht nach einer gewissen Zeit
die Session/Port dicht und die Telefone versuchen nicht ernergisch genug die Anlage
wieder zufinden. Was dann dazu führt, dass diese die Geräte als nicht verfügbar an sieht.

Im übrigen ist es Egal welche OpenCom 100/X320 Du nimmst, dass Problem tritt bei allen
auf.


Gruß

Christian

 

[Balogh]

In diesem Forum wurde dann und wann von Reboots auf IP-Endgeräten in VPN-Netzwerken berichtet. Diese erfolgen immer nach dem gleichen Muster: nach einer gewissen Zeit der Inaktivität (keine Gespräche, kein LED-Zustandswechsel, kein Anruf) löst das Hörerabnehmen, ein Tastendruck oder ein eingehender Anruf einen Reboot auf ebendiesem IP-Endgerät aus. Beim OpenPhone 75IP wird beispielsweise auf dem Display angezeigt:

IP PHONE terminated
IP PHONE module load
IP PHONE application start
please wait
starting protocol

Danach ist das Endgerät wieder bereit. Ein allfälliger Anruf ist aber bereits verpasst; er ist aber in der Anrufliste protokolliert. Weil das Problem nur dann auftritt, wenn das Endgerät per VPN angeschlossen ist, fiel der Verdacht natürlich sofort auf die VPN-Router. Es zeigte sich, dass die Probleme mit Firewalls verschiedener Hersteller auftreten, aber nach unterschiedlichen Wartezeiten.

Bei Firewalls vom Typ ZyXEL ZyWALL tritt das Problem alle 2.5 Stunden auf. Die Zeit von 9000 Sekunden entspricht dem Connection Tracker bzw. State Table Timeout für hängende Sessions. Der Workaround besteht darin, dass diese Zeit erhöht wird. Bei der aktuellen ZyXEL ZyWALL USG-Serie lässt sich der Wert bis auf 432000 Sekunden erhöhen, was fünf Tagen entspricht. Dadurch wird die Wahrscheinlichkeit eines Reboots praktisch auf 0 reduziert.

Bei anderen Firewall-Herstellern ist die Zeit sogar kürzer als 9000 Sekunden und führt dazu, dass die Reboots tendenziell noch häufiger auftreten können.

Die beste Lösung wäre freilich, wenn Aastra ihr eigenes VoIP-Protokoll so anpassen könnte, dass es "firewallfreundlicher" wäre. Denn das beidseitige Deaktiveren aller Firewall-Funktionen, was einem zweiten funktionierenden Workaround bei ZyXEL ZyWALL-Geräten entspricht, kann ja keine praktikable Lösung sein.

Philippe Balogh/19.12.2009