OpenCom 1010 - VPN - OpenPhone 65 IP - Verbindung bricht ab - Cisco 5505

[Torsten.E 10]

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.

[blackbox 10]

Hi,

 

hast du für das H.323 was du vermutlich verwendest - auf der ASA mal die FIXUP´s deaktiviert ? Das hilft hier meistens.

[Torsten.E 10]

Hi Blackblox,

 

ich habe nachgefragt. Die Anlage verwendet G711 oder Komprimiert G729.

 

Im Augenblick teste ich mit folgender Einstellung:

policy-map global-class-IP-Telefone
class global-class-IP-Telefone
 set connection timeout idle 0:00:00 
 set connection advanced-options tcp-state-bypass
!
service-policy global-class-IP-Telefone global

 

Da die Tests immer ziemlich viele Stunden in Anspruch nehmen kann ich bisher nur sagen, 7 Std. haben bisher schon geklappt.

 

Torsten

[blackbox 10]

Hi,

 

jau - hatte ichmir gedacht - in der Regel sind aber im Default für das G711 / G729 die Fixup aktiviert - schau mal nach.

[Torsten.E 10]

Wo finde ich das genau "blacky" ?

[Torsten.E 10]

Was ich herausgefunden habe, ist, dass FIXUP jetzt INSPECT heist. Aber wenn ich es richtig verstanden habe, läuft bei mir KEIN SIP. Also SIP INSPECT ist es dann nicht.

 

Die Aastra bzw. OpenCom1010 verwendet zwischen PBX und den IP-Endgeräten das sogenannte Stimulus-Protokoll.

bearbeitet 8. August 2011 von Torsten.E

[blackbox 10]

Ich meine auch das INSPECT H323

 

policy-map global_policy

class inspection_default

no inspect h323 h225

no inspect h323 ras

[Torsten.E 10]

Aber H.323 wird doch überhaupt nicht verwendet. Ich meine, einstellen kann ich es schon. Was bewirkt ein "no inspect" ?

[blackbox 10]

Die Anlage verwendet G711 oder Komprimiert G729. = H.323

[Torsten.E 10]

Ich will nicht widersprechen, weis es ja auch nicht 100%.

G711 und G729 sind ja nur Codierungsverfahren für die Gesprächsübermittlung.

 

Stimulus Protokoll für die Signalisierung zwischen System-Endgeräten und OpenCom 1000.

Und hier ist eben nicht definiert, was genau "Stimulus" ist.

 

Schaden kann Deine Einstellung aber auf keinen Fall ;-)

 

Aber was bedeutet "no inspect" genau ?

 

Ich hab mal im ASDM nachgesehen, da steht für die beiden Protokolle "Low". Ist dann "no inspect" dann noch weniger?

bearbeitet 8. August 2011 von Torsten.E

[blackbox 10]

Hi,

 

doch ist der Codec den H.323 verwendet. Der Inspect macht eine Überwachung der Befehle die für den Codec verwendet werden dürfen (sprich er schaut in den Datenstrom rein und überprüft - was da passiert und ob es den Regeln entspricht.) Wenn man das ding mit "NO" abschaltet - tut er das für dieses Protokoll nicht mehr. Das Problem bei den Codec´s ist - das "jeder" das etwas anderst auslegt (Cisco verwendet das ja auch) - z.B. bei einer Avaya bekommt man mit "Inscpect" das Telefon angemelt - hört aber nix - bei einer Siemens kann man das Telefon meist garnicht anmeldet...

[Torsten.E 10]

# no inspect h323 h225
ERROR: Inspection not installed or parameters do not macht

 

sieht so aus als ob gar keine Inspection eingerichtet ist

[blackbox 10]

notfalls mal mit "sh run | in inspect" suchen gehen

[Torsten.E 10]

bzw nur die "low" Einstellung, welche ich jetzt über den ASDM eingerichtet habe. Da wird dann nix geprüft.

[blackbox 10]

ok - dann müssen wir mal weitersuchen was da passiert... denke....