Guten Morgen,
ich versuche aktuell eine Starface Compact (VoIP TK-Anlage) an eine RC100 anzubinden. Dies funktioniert auch grundsätzlich,
jedoch spätestens alle 24 Stunden bei der Zwangstrennung verliert die Starface Compact seine Registrierung bei QSC und es ist
keine neue Registrierung mehr bei QSC möglich. Bei der Starface Compact steht der Fehler "Request Send". Ein Neustart der Starface
Compact löst das Problem nicht, erst wenn ich die RC100 neustarte kann sich die Starface Compact wieder ganz normal ohne mein Zutun
bei QSC registrieren.
Ich habe den SIP-Port 5060 (TCP und UDP) und die RTP-Ports 20000-59999 (UDP) per
DESTNAT an die Starface weiter geleitet. Die Starface Compact geht per HIDENAT nach draußen.
Woran könnte das Problem liegen?
Vielen Dank im Voraus!
RC100 mit Starface Compact (VoIP TK-Anlage) / Probleme
Moderator: Securepoint
Wenn das Problem das nächste Mal auftaucht, starten Sie die Appliance bitte nicht neu, sondern erstellen sich einen "root"-Benutzer und melden sich mit diesem an der SSH-Konsole an. Führen Sie dort aus:
Und teilen Sie uns dann bitte mit, ob die Registrierung jetzt wieder möglich ist. Bitte warten Sie mit dem Ausführen des Befehls, bis die RC100 sich wieder mit dem Internet verbunden hat.
Code: Alles auswählen
# conntrack -F
Mit Bordmitteln: überhaupt nicht. Sie können auf der UTM allerdings einen SSH-Key hinterlegen: http://support.securepoint.de/viewtopic ... 440#p12440
Und dann von einem externen Gerät mittels SSH den Befehl absetzen, wenn der Reconnect eine viertel Stunde her ist.
Das Problem tritt an dieser Stelle auf, weil die TK-Anlage vermutlich mehrfach pro Sekunde versucht, die Registrierung wiederherzustellen. Da das schreiben des Regelwerks allerdings ein paar Sekunden nach dem Aufbau der Internetverbindung stattfindet, sind zu diesem Zeitpunkt noch keine NAT-Regeln geschrieben und die Verbindung geht somit mit der falschen IP Richtung Internet.
Ich werde hier intern mal erläutern, wir man in so einem Fall softwareseitig am besten vorgehen könnte.
Und dann von einem externen Gerät mittels SSH den Befehl absetzen, wenn der Reconnect eine viertel Stunde her ist.
Das Problem tritt an dieser Stelle auf, weil die TK-Anlage vermutlich mehrfach pro Sekunde versucht, die Registrierung wiederherzustellen. Da das schreiben des Regelwerks allerdings ein paar Sekunden nach dem Aufbau der Internetverbindung stattfindet, sind zu diesem Zeitpunkt noch keine NAT-Regeln geschrieben und die Verbindung geht somit mit der falschen IP Richtung Internet.
Ich werde hier intern mal erläutern, wir man in so einem Fall softwareseitig am besten vorgehen könnte.
Erstmal vielen Dank für Ihren schnellen Lösungsansatz.
Ich habe mir jetzt erstmal so beholfen, dass der SSH-Befehl in der
Nacht kurz nach dem Reconnect einmal automatisch abgesetzt wird.
Mittelfristig wäre es natürlich schöner, wenn wir das Problem eleganter gelöst
bekämmen, da es ja auch mal zu einem ungeplanten Reconnect kommen kann.
Bin also auf Ihre internen Ergebnisse gespannt und wünsche Ihnen ein schönes Wochenende!
Ich habe mir jetzt erstmal so beholfen, dass der SSH-Befehl in der
Nacht kurz nach dem Reconnect einmal automatisch abgesetzt wird.
Mittelfristig wäre es natürlich schöner, wenn wir das Problem eleganter gelöst
bekämmen, da es ja auch mal zu einem ungeplanten Reconnect kommen kann.
Bin also auf Ihre internen Ergebnisse gespannt und wünsche Ihnen ein schönes Wochenende!
Gibt es hier was neues? Wäre schön auf die momentan bei DSL häufigen reconnects reagieren zu können. Der eine Nachts geht ja noch per Aufgabenplanung, aber tagsüber ist dann immer der Trunk weg...Erik hat geschrieben:...
Das Problem tritt an dieser Stelle auf, weil die TK-Anlage vermutlich mehrfach pro Sekunde versucht, die Registrierung wiederherzustellen. Da das schreiben des Regelwerks allerdings ein paar Sekunden nach dem Aufbau der Internetverbindung stattfindet, sind zu diesem Zeitpunkt noch keine NAT-Regeln geschrieben und die Verbindung geht somit mit der falschen IP Richtung Internet.
Ich werde hier intern mal erläutern, wir man in so einem Fall softwareseitig am besten vorgehen könnte.