|
OpenCom 1010 - VPN - OpenPhone 65 IP - Verbindung bricht ab - Cisco 5505
Guten Morgen erst mal an alle.
Hier ein Ausschnitt aus einem anderen Forum, welchen in gerade gefunden habe. Er beschreibt das Problem ganz genau. (weiter unten, gekürzt).
Erklärung des Herstellers (sinngemäß)
"...das Problem ist, dass nur die Cisco Router im VPN-Tunnel nochmals eine Firewall haben. Diese Firewall verwirft das 1. Datenpaket, welches aber für die IP-Telefonie benötigt wird. Anderen Router verwenden ..."
Ich weis, ist ein wenig viel zu lesen, aber bevor sich jemand beschwert, ich würde das Problem nicht ausführlich beschreiben
Gruss
Torsten
<-----------------
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!!??
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.
----
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.
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.
|
