[flyinghuman]

Hallo,

ich habe folgendes Problem:

Es besteht ein VPN zwischen 2 Standorte, eingesetzt werden Draytek Vigor 2820 für die Herstellung der VPN Verbindung.

Gelegentlich kommt es vor, dass nach einer Zwangstrennung sich die Telefone vom zweiten Standort nicht mit der 3CX Anlage im ersten Standort verbinden können. Auch ein Reboot der betroffenen Telefone hilft da nicht, sondern nur ein Reboot des Router am zweiten Standort.

Verbinde ich die Telefone aber über den 3CX Tunnel / Proxy, sind die Telefone dauerhaft verbunden. Auch nach der Zwangstrennung. Allerdings ist darüber die Sprachqualität schlechter (ist das normal?).

Dies betrifft sowohl Grandstream GXP 2020, GXP 2110 sowie Snom 360 und Snom 370 Telefone.
Bei den Snom Telefonen erscheint im Status die Meldung "Network Failure".
Edit: Auch ein Patton am zweiten Standort ist gelegentlich nach einer Zwangstrennung nicht mehr verbunden.

Dies passiert nicht immer, nur alle 2-5 Tage. Im Syslog der Router kann ich auch nichts auffälliges finden.

Hatte schonmal jemand so ein Problem mit Vigor-Router?

Andere Anwendungen funktionieren nach wie vor Problemlos, nur die SIP-Pakete scheinen irgendwo verloren zu gehen.

[matictec]

Es hört sich auf jeden Fall schon mal nach einem Router Problem an. Der müsste sicherstellen, dass die VPN-Verbindung immer wieder aufgebaut wird. Die meisten Router unterstützen eine solche Funktionalität. Oft muss diese für beide Standort separat eingestellt werden.

Schlechte Sprachqualität spricht dafür, dass die Verbindung nur "wenig" Bandbreite hat und kein Priorisierung der VoIP-Pakete vorgenommen wird.

Bei einer Verbindung über den Tunnel kann es etwas schlechtere Sprachqualität geben, da hier immer noch die Pakete auf der Anlage bzw. dem Proxy-Endpunkt "angefasst" werden. Optimal ist es, wenn die Telefone 1-1 die pakete senden/empfangen. dann hängt die Qualität nur noch von den Endgeräten ab.

[pc37]

Dieses Problem kommt vom Draytek Router. Die Zwangstrennung ist oft so kurz, sodass die VPN Gegenseite die Unterbrechung nicht wahrgenommen hat und die LAN-LAN Verbindung nicht geschlossen wurde. Man sieht hier eine VPN Online Zeit die größer ist als die Zeit seit der letzten Zwangstrennung.
Workaround: auf beide Router 2 Timer erstellen um die Zwangstrennung selber zu regeln, z.B. um 6 Uhr:
Timer 1: On 6:01, Off 5:59
Timer 2: On 6:02, Off 5:58
In der WAN Verbindung Timer 1 eintragen
In den LAN-LAN Verbindungen Timer 2 eintragen
Um 5:58 werden dann die VPN-Verbindungen gekappt, Um 5:59 die DSL Verbindung
Um 6:01 wird die DSL Verbindung wieder hergestellt und um 6:02 die LAN-LAN Verbindungen
Natürlich nicht vergessen die Router mit NTP zu füttern: z.B. ptbtime1.ptb.de

John

[flyinghuman]

Danke für Eure Antworten.

Leider bringt der Timer auch keinen Erfolg.
Ich lasse nun schon immer einen Router per Timer Rebooten - auch das bringt nichts.

Seltsam ist aber auch, dass die VPN Verbindung dauerhaft vorhanden ist und auch über RDP (Terminalserver) ist ein durchgängiges arbeiten via dieser VPN-Verbindung möglich. Nur die Telefone / der Patton Gateway kommt nicht mehr zur Anlage bzw. sind dort abgemeldet. Ping zu den betroffenen Geräten kommt aber auch erfolgreich durch.

Irgendetwas verschluckt nach einiger Zeit UDP-Pakete. KANN sowas auch am Switch liegen?
Nach einen Router-Reboot in der betroffenen Filiale klappt es vorerst wieder wie es soll.

Ich bin etwas ratlos, da auch schon der Router ausgetauscht wurde.
Einziger Unterschied: Die Filiale hat VSDL und da hat der Vigor 2820 die spezielle VDSL Firmware drauf. In der Zentrale ist die normale Firmware drauf für ADSL.

Hat noch jemand einen Tipp?

[groundhog]

Wenn Du den Router täglich für eine Minute (händisch) abschaltest, tritt das Problem dann noch auf?

[flyinghuman]

Ich schätze mal das würde funktionieren. Nach dem Reboot klappt es ja auch wieder für mehrere Stunden / Tage

Eine Zeitschaltuhr dazwischen zu schalten kommt aber nicht in Frage - es muss ja irgendwo dran liegen und das Problem muss zu lösen sein...

[StefanW]

schalte mal in den DrayTeks Ping an in der VPN und er soll dann die PBX Pinge.(in den alten 2900 ging es) Wenn der VPn down ist veranlasst das die Boxen um dieses wieder aufzubauen

[flyinghuman]

Danke für die Antwort.
Die VPN wird ja nicht abgebaut - die ist immer da, außer beim Reconnect natürlich.

Ich habe schon einmal eine Dauerping-Test gemacht während sich die Telefone abmelden - der Ping kommt durch und die Antwortzeitzeiten sind auch Super.

Wie gesagt, irgendetwas scheint da die UDP Pakete mit der Zeit zu verschlucken.

--> KANN das an einem Buggy Switch mit Fehlerhafter QoS liegen? woran kann es noch liegen?

VPN ist immer da, nur die Telefone trennen sich (snom, sowie Grandstream, sowie Patton Gateway).

Edit: bei den DrayTeks wird per Firewall nichts geblockt. Sonst würde es ja auch nicht für eine gewisse Zeit x funktionieren.

[matictec]

Ok. Das ist ein neuer Aspekt, der mir davor nicht klar geworden ist. Die VPN-Verbindung steht und kann von anderen Diensten auch genutzt werden. Nur Telefone funktionieren nicht mehr?

[flyinghuman]

Richtig. Alles andere funktioniert noch. (Netzwerkfreigaben, Remotedesktop)

[groundhog]

Bei den Snoms gibt es einen Button (im Webinterface) "Re-Registrieren".

Funktioniert das Re-Registrieren, wenn die Anlage ausgefallen ist (ohne den Router neu zu starten)?

[flyinghuman]

nein. wenn einmal die Verbindung bei den Telefonen weg ist, kann man selbst durch Telefone neu starten keine erfolgreiche Verbindung der Telefone herstellen. Bei den Snoms steht dann als Status: network failure.

[groundhog]

Du hast geschrieben

Alles andere funktioniert noch. (Netzwerkfreigaben, Remotedesktop)

Hängen die funktionierenen Teile am gleichen Switch, gleiche Portart (also kein PoE oder 100er Port statt 1000er)?

Meine Frage zielt darauf ab, Störquellen im LAN auszuschließen.

Dann würde es Sinn machen, Wireshark auf der Anlage mitlaufen zu lassen um zu sehen, was da wann abstirbt. Die Snoms erneuern ja regelmäßig ihre Anmeldung.
So könnte dann auch im Router nach Ereignissen zu diesem Zeitpunkt gesucht werden.

Du hattest den Router ja schon getauscht und ich finde es ist recht unwahrscheinlich das beide den gleichen Fehler haben, daher lieber erst alle anderen Möglichkeiten abklopfen.

[flyinghuman]

Die funktionierenden Teile hängen am selben Switch.
Die Telefone werden separat angeschlossen, es wird also nicht der integrierte Switch der Telefone genutzt.
PC und Telefon hängen also am selben Switch. Der PC hat immer Verbindung - die Telefon melden sich nach einer gewissen Zeit x bei der 3CX ab. Anpingen kann man die Telefone aber noch und auch auf das Webinterface kann zugegriffen werden.

Ich werde ggf. dieses We mal Wireshark auf dem Server installieren.
Auf den Routern wird bereits per Syslog mitprotokolliert - ich kann aber nichts auffälliges finden.
Auf den Snoms kommt irgendwann ein Fehler wie
"Generating Fake Paket" oder Ghost Paket, ich weiß es nicht mehr genau, kann aber auch gerade nicht nachschauen.
-> Das snom bekommt jedenfalls keine Antwort auf seine Registrierungsanfrage und erstellt selbst ein Paket damit der Vorgang abgeschlossen werden kann - aber eben ohne Verbindung zur 3CX.

Ich werde auch mal bei Gelegenheit die 3CX Version 9 installieren.
Zur Zeit wird noch die 8er genutzt. Die Demoversion muss zum testen erst mal ausreichen.

[groundhog]

Ja, die Demo reicht. Ich sehe sowieso keinen Zusammenhang mit der 3CX, das muss ein anderer Fehler sein.

Allerdings habe ich auch Probleme damit, das es am Router liegen soll. Denn letztlich unterscheidet sich das SIP-Paket zunächst mal überhaupt nicht von irgendeinem anderen Paket. Erst wenn dekodiert wird, kommen z.B. die Ports ins Spiel und zwar für die decodierende Stelle. Wenn der Router da nichts verarbeitet, "sieht" der nicht mal den Unterschied zwischen einem Port 80 oder 5060.
Decoder wäre in diesem Fall der Server, auf dem die 3CX läuft. Netzwerkkarte oder Betriebssystem, bis dahin müsste das Paket eigentlich kommen. Daher mein Vorschlag mit Wireshark.

Wenn Du die Möglichkeit hast, folgender Vorschlag zum Test:
Laptop oder irgendwas Provisorisches mit 3CX bespielen und statt des bisherigen Systems beteiben.
Dann wäre mit einem Schlag Netzwerkkarte, Betriebssystem und 3CX Server ausgeschlossen oder eben nicht.