Hallo,
wir haben seit einiger Zeit (> 11.6.x) bei Kunden die VOIP Telefonie einsetzen, folgendes Problem:
Nach einer Uptime der UTM (egal ob RC100 oder Dwarf G2) von ca. 2 Wochen können sich die Endgeräte nicht mehr beim Provider registrieren. Auch ein Neustart der Endgeräte bringt keine Besserung. Startet man allerdings die UTM neu, registrieren sich die Geräte danach ohne Probleme. Was alle UTMs gemeinsam haben, ist die Erhöhung des Session Timeout Wertes für UDP Pakete auf 300 Sekunden (wie hier beschrieben: http://wiki.securepoint.de/index.php/Sy ... v11#sysctl ). Kann es sein, daß bei diesem Wert die Maskierungstabelle volläuft?
Viele Grüße
Matthias
Probleme bei SIP Registrierung
Moderator: Securepoint
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Das Problem würde mich auch interessieren. Viele VOIP Anbieter empfehlen einen UDP Timeout von 130, vielleicht klappt es damit besser?
Kann man den UDP Timeout auch nur auf SIP Pakete anwenden? Ich kenne die Funktion von diversen Firewall herstellern
Gruß
Klaus
Kann man den UDP Timeout auch nur auf SIP Pakete anwenden? Ich kenne die Funktion von diversen Firewall herstellern
Gruß
Klaus
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Nachtrag: Evtl. liegt das Problem noch woanders begründet. Nachdem ich bei einem Kunden gestern das Problem durch einen Neustart behoben hatte, tauchte es heute morgen wieder auf (also nach nicht einmal 24 Stunden). Auch hier genügte ein simpler Neustart der UTM.
Matthias
Matthias
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Hallo Björn,
da ich ungern warten würde, bis das Problem wieder beim Kunden auftaucht, werde ich versuchen das Problem bei uns nachzustellen. Was genau meinen Sie denn mit "Es könnte evtl. auch am conntrack in der UTM liegen"?
Grüße
Matthias
da ich ungern warten würde, bis das Problem wieder beim Kunden auftaucht, werde ich versuchen das Problem bei uns nachzustellen. Was genau meinen Sie denn mit "Es könnte evtl. auch am conntrack in der UTM liegen"?
Grüße
Matthias
Hallo Matthias,
das conntrack merkt sich die Verbindungsinformation von der Quelle zu dem Ziel mit dem Port. Dies hat den Vorteil das nicht alle nachfolgenden Pakete jedesmal den Portfilter und das Routing durchlaufen muss. Dadurch wird die Verarbeitung der Pakete um einiges schneller. Das Problem könnte aber in diesem Falle sein das bei einem Verlust der Internetleitung die Pakete nicht geroutet werden können. Auch dies wird im conntrack durch die Paketmarkierung gespeichert. Ein neustart der UTM löscht das conntrack. Sie können auch per ssh und dem Benutzer root das conntrack manuell löschen
conntrack -F
Gruß Björn
das conntrack merkt sich die Verbindungsinformation von der Quelle zu dem Ziel mit dem Port. Dies hat den Vorteil das nicht alle nachfolgenden Pakete jedesmal den Portfilter und das Routing durchlaufen muss. Dadurch wird die Verarbeitung der Pakete um einiges schneller. Das Problem könnte aber in diesem Falle sein das bei einem Verlust der Internetleitung die Pakete nicht geroutet werden können. Auch dies wird im conntrack durch die Paketmarkierung gespeichert. Ein neustart der UTM löscht das conntrack. Sie können auch per ssh und dem Benutzer root das conntrack manuell löschen
conntrack -F
Gruß Björn
Lustig,
genau das identische Problem haben wir auch.
Ein conntrack -F ist nicht sinnvoll, damit behebt sich zwar das Problem, aber auch nur für eine gewisse Dauer.
Was allerdings funktioniert hat, ist seit dem die FW sich nicht mehr selber per PPPOE einwählt, sondern ein Router davor steht, seit dem tritt das PRoblem nicht mehr. Dafür ist jetzt natürlich Mist bei IPSEC.
@matzemcfly Um welche Telefone geht es hier wenn ich Fragen darf? Bei uns geht es speziell um Gigaset Telefone... Eventuell könnten wir auch persönlich zu dem Thema im Kontakt bleiben?
genau das identische Problem haben wir auch.
Ein conntrack -F ist nicht sinnvoll, damit behebt sich zwar das Problem, aber auch nur für eine gewisse Dauer.
Was allerdings funktioniert hat, ist seit dem die FW sich nicht mehr selber per PPPOE einwählt, sondern ein Router davor steht, seit dem tritt das PRoblem nicht mehr. Dafür ist jetzt natürlich Mist bei IPSEC.
@matzemcfly Um welche Telefone geht es hier wenn ich Fragen darf? Bei uns geht es speziell um Gigaset Telefone... Eventuell könnten wir auch persönlich zu dem Thema im Kontakt bleiben?
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Wir haben die Probleme einerseits mit Starface-Anlagen, d.h. die Leitungen in der Starface sind irgendwann rot und registrieren sich nicht mehr und andererseits mit jeglichen IP-Endgeräten in Kombination mit einer Starface Cloud, d.h. die Endgeräte verlieren irgendwann die Verbindung zur Cloudanlage und registrieren sich danach nicht mehr. Dabei ist es egal, ob es Yealink-Telefone, Snoms, Gigaset N510 oder Grandstreamadapter sind. Daher schließe ich auch die Geräteseite aus.
Das mit conntrack erscheint mir schon plausibel, aber wie auch Petasch geschrieben hat, behebt das die Symptome aber nicht das eigentliche Problem. Wenn es hier keine andere Lösung gibt, hilft wohl nur ein Cronjob der einmal am Tag conntrack -F ausführt (wäre aber doch eine eher unbefriedigende Lösung).
Ich habe die diversen Installationen jetzt mal überprüft. Und tatsächlich, der einzige Kunde bei dem das Problem nicht auftritt, hat vor der UTM noch einen Router.
Das mit conntrack erscheint mir schon plausibel, aber wie auch Petasch geschrieben hat, behebt das die Symptome aber nicht das eigentliche Problem. Wenn es hier keine andere Lösung gibt, hilft wohl nur ein Cronjob der einmal am Tag conntrack -F ausführt (wäre aber doch eine eher unbefriedigende Lösung).
Ich habe die diversen Installationen jetzt mal überprüft. Und tatsächlich, der einzige Kunde bei dem das Problem nicht auftritt, hat vor der UTM noch einen Router.
Hallo,
das liegt daran das die Verbindung auf der WAN Schnittstelle nicht weg ist. Bei Modemeinwahl kann man ein Redail auf eine bestimmte Uhrzeit setzten und im cronjob nach der "Zwangstrennung" das conntrack löschen lassen. Somit sollte das ganze vor Arbeitsbeginn gesäubert sein.
Gruß Björn
das liegt daran das die Verbindung auf der WAN Schnittstelle nicht weg ist. Bei Modemeinwahl kann man ein Redail auf eine bestimmte Uhrzeit setzten und im cronjob nach der "Zwangstrennung" das conntrack löschen lassen. Somit sollte das ganze vor Arbeitsbeginn gesäubert sein.
Gruß Björn
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
So, gerade im Moment hatte ich wieder einen Ausfall (die Abstände werden anscheinend auch kürzer). Allerdings hat der conntrack Befehl gar nichts gebracht.
Die Situation war folgende:
Yealink Telefon an Starface Cloud zeigt an "Registrierung fehlgeschlagen".
Folgendes haben wir probiert:
--> Neustart des Telefons --> kein Erfolg
--> Telefon für 1 Minute vom Stromnetz getrennt und dann wieder gestartet --> kein Erfolg
--> conntrack -F auf der UTM ausgeführt und 5 Minuten gewartet--> kein Erfolg
--> Neustart der UTM --> Das Telefon hat sich sofort von alleine wieder registriert, sobald die Internetverbindung wieder da war.
Ich muss gestehen, ich bin etwas ratlos. Da das Phänomen bis jetzt bei unserer Anlage noch nicht aufgetreten ist, werde ich mal die Firewallregeln vergleichen. Evtl. gibt es da noch einen Unterschied.
Die Situation war folgende:
Yealink Telefon an Starface Cloud zeigt an "Registrierung fehlgeschlagen".
Folgendes haben wir probiert:
--> Neustart des Telefons --> kein Erfolg
--> Telefon für 1 Minute vom Stromnetz getrennt und dann wieder gestartet --> kein Erfolg
--> conntrack -F auf der UTM ausgeführt und 5 Minuten gewartet--> kein Erfolg
--> Neustart der UTM --> Das Telefon hat sich sofort von alleine wieder registriert, sobald die Internetverbindung wieder da war.
Ich muss gestehen, ich bin etwas ratlos. Da das Phänomen bis jetzt bei unserer Anlage noch nicht aufgetreten ist, werde ich mal die Firewallregeln vergleichen. Evtl. gibt es da noch einen Unterschied.
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Ich hätte jetzt gerne einen dauerhaften Lösungsvorschlag. Beinahe täglich ruft hier ein anderer Kunde an und ist stinksauer. Und wenn ich sehe, daß ein Partner mit 200 Installationen von genau denselben Problemen geplagt wird (und wir beide sicher nicht die einzigen sind), dann drängt sich mir doch sehr der Verdacht auf, daß hier ein grundsätzliches Problem vorliegt. Ich kann ja schlecht allen Kunden eine Fritzbox hinstellen. Mit der gibt es nämlich keinerlei Probleme. Und ich will keine Lösung à la "dann starten Sie doch einmal am Tag die Firewall neu"!
-
pascal
Moin,
da ich anhand ihres Benutzernamen nicht erkennen kann, zu welchem Unternehmen Sie gehören, würde ich Sie bitten sich telefonisch bei uns zu melden, eine Ferndiagnose über das Forum ist doch leider etwas schwieriger. Dann kann für dieses Problem ein Ticket erstellt werden und wir können uns das auf der UTM ansehen.
Unsere Telefonnummer finden Sie in meiner Signatur.
da ich anhand ihres Benutzernamen nicht erkennen kann, zu welchem Unternehmen Sie gehören, würde ich Sie bitten sich telefonisch bei uns zu melden, eine Ferndiagnose über das Forum ist doch leider etwas schwieriger. Dann kann für dieses Problem ein Ticket erstellt werden und wir können uns das auf der UTM ansehen.
Unsere Telefonnummer finden Sie in meiner Signatur.
Moin,
ich weiß nicht ob matzemcfly sich im Support gemeldet hat.
Ansonsten rufen Sie einmal durch.
Generell gebe ich Recht das ein conntrack -F nicht optimal ist. (Da es das gesamte Modul flushed). Besser wäre es, gezielt die Verbindung zu löschen.
Im normalfall macht die UTM das selber: Nach jeder Neueinwahl werden die alten Einträge aus dem conntrack gelöscht.
Wurde auf den betroffenen Maschinen die SIP Helper im conntrack deaktivier? (eventuell besser das was)
Aus privater Erfahrung kann ich nur positives Berichten: Habe eine UTM (11.6.9) an einem VDSL Anschluss (die macht auch die Einwahl) und dahinter steht ein VoIP Telefon (ohne TK) und da gab es bisher keine Problem (egal ob mit oder ohne SIP Helper im conntrack)
Gruß
Kenneth
ich weiß nicht ob matzemcfly sich im Support gemeldet hat.
Ansonsten rufen Sie einmal durch.
Generell gebe ich Recht das ein conntrack -F nicht optimal ist. (Da es das gesamte Modul flushed). Besser wäre es, gezielt die Verbindung zu löschen.
Im normalfall macht die UTM das selber: Nach jeder Neueinwahl werden die alten Einträge aus dem conntrack gelöscht.
Wurde auf den betroffenen Maschinen die SIP Helper im conntrack deaktivier? (eventuell besser das was)
Aus privater Erfahrung kann ich nur positives Berichten: Habe eine UTM (11.6.9) an einem VDSL Anschluss (die macht auch die Einwahl) und dahinter steht ein VoIP Telefon (ohne TK) und da gab es bisher keine Problem (egal ob mit oder ohne SIP Helper im conntrack)
Gruß
Kenneth
Hallo,
also bei uns hat von diesem Forums-Eintrag der letzte Post alle Probleme mit SIP-Verbindungen "durch" die Securepoint geholfen:
viewtopic.php?t=5668
Diese Module müssen über die SPCLI entladen werden (auch auf einer VPN-Edition, die ja eigentlich die VoIP-Proxy-Funktion nicht hat).
Gruß
Rolf
also bei uns hat von diesem Forums-Eintrag der letzte Post alle Probleme mit SIP-Verbindungen "durch" die Securepoint geholfen:
viewtopic.php?t=5668
Diese Module müssen über die SPCLI entladen werden (auch auf einer VPN-Edition, die ja eigentlich die VoIP-Proxy-Funktion nicht hat).
Gruß
Rolf
-
matzemcfly
- Beiträge: 31
- Registriert: Mi 24.04.2013, 08:50
- Kontaktdaten:
Hallo zusammen,
sorry, daß ich mich länger nicht gemeldet habe, aber ich stand direkt mit dem Support in Verbindung. Leider nur mit bedingtem Erfolg. Wir hatten es zwar geschafft, daß sich ein Supportmitarbeiter direkt während eines Ausfalls aufschalten konnte, die Lösung war leider nur von begrenzter Dauer. Laut dem Support war eine fehlerhafte Firewallregel Schuld an den Ausfällen. Die Regel war zwar defintiv falsch nur hatte ich so meine Zweifel, daß dies tatsächlich die Ursache gewesen sei. Die Zweifel wurden heute morgen bestätigt, als wir bei unserer eigenen UTM zum ersten Mal das gleiche Problem hatten. Interessanterweise habe ich gestern auf die 11.6.9 aktualisiert und heute hatten wir den Ausfall.
Ich habe das direkt an den Support geschrieben und darauf hingewiesen, man möge sich vielleicht auch direkt mit Petasch in Verbindung setzen, da er ja die Problematik auf einer Vielzahl von UTMs und in wesentlich höherer Frequenz hat als wir. @Petasch: Sollte sich jemand vom Support melden und Sie zusammen zu einer Lösung kommen, würden wir uns alle über einen Post hier freuen :-).
Da das Thema „VOIP“ doch immer stärker zunimmt, wäre es vielleicht keine schlechte Idee, wenn es von Securepoint einmal ein „Best Practice“ gäbe, in dem beschrieben wird, welche Schritte durchzuführen sind, damit VOIP Telefonie mit einer UTM problemlos funktioniert. Bis jetzt muss man sich aus diversen Foren- und Wikibeiträgen (die sich auch gerne mal widersprechen) alles selbst zusammenreimen. Und beim Lesen der diversen Beiträge beschleicht einen das Gefühl, daß hier manchmal eher Voodoo im Spiel ist.
Viele Grüße
Matthias
sorry, daß ich mich länger nicht gemeldet habe, aber ich stand direkt mit dem Support in Verbindung. Leider nur mit bedingtem Erfolg. Wir hatten es zwar geschafft, daß sich ein Supportmitarbeiter direkt während eines Ausfalls aufschalten konnte, die Lösung war leider nur von begrenzter Dauer. Laut dem Support war eine fehlerhafte Firewallregel Schuld an den Ausfällen. Die Regel war zwar defintiv falsch nur hatte ich so meine Zweifel, daß dies tatsächlich die Ursache gewesen sei. Die Zweifel wurden heute morgen bestätigt, als wir bei unserer eigenen UTM zum ersten Mal das gleiche Problem hatten. Interessanterweise habe ich gestern auf die 11.6.9 aktualisiert und heute hatten wir den Ausfall.
Ich habe das direkt an den Support geschrieben und darauf hingewiesen, man möge sich vielleicht auch direkt mit Petasch in Verbindung setzen, da er ja die Problematik auf einer Vielzahl von UTMs und in wesentlich höherer Frequenz hat als wir. @Petasch: Sollte sich jemand vom Support melden und Sie zusammen zu einer Lösung kommen, würden wir uns alle über einen Post hier freuen :-).
Da das Thema „VOIP“ doch immer stärker zunimmt, wäre es vielleicht keine schlechte Idee, wenn es von Securepoint einmal ein „Best Practice“ gäbe, in dem beschrieben wird, welche Schritte durchzuführen sind, damit VOIP Telefonie mit einer UTM problemlos funktioniert. Bis jetzt muss man sich aus diversen Foren- und Wikibeiträgen (die sich auch gerne mal widersprechen) alles selbst zusammenreimen. Und beim Lesen der diversen Beiträge beschleicht einen das Gefühl, daß hier manchmal eher Voodoo im Spiel ist.
Viele Grüße
Matthias
Hallo,
Bezüglich "Best Practice":
Ein allgemeines "Kochrezept" gibt es für VoIP leider nicht. Bei einigen Umgebungen funktioniert es ohne Probleme, wieder andere benötigen das Entladen der Kernel Module oder Stateless Regeln im Portfilter. Was auf jedenfall Hilft: Automatisches QoS aktivieren (zwecks Priorisierung der Pakete)
Das Problem (meistens) ist: VoIP (insbesonders SIP) ist zwar genormt, aber irgendwie auch nicht. Viele VoIP Anbieter halten sich nicht dran oder machen irgendetwas anders.
Bei mir privat funktioniert VoIP ohne Probleme (aktuelle Version, Portweiterleitung für SIP auf eine Easybox von Vodafone die nur VoIP macht). Egal ob mit oder ohne geladenen Modulen.
Eventuell könnten die Probleme auch mit dem Thema hier zu tun haben:
https://support.securepoint.de/viewtopic.php?t=5668
Gruß
Kenneth
Die Module haben nichts mit dem VoIP Proxy zu tun, sondern mit den Kernel Modulen des Linux selbst. Diese sind UTM/VPN unabhängig geladenDiese Module müssen über die SPCLI entladen werden (auch auf einer VPN-Edition, die ja eigentlich die VoIP-Proxy-Funktion nicht hat).
Bezüglich "Best Practice":
Ein allgemeines "Kochrezept" gibt es für VoIP leider nicht. Bei einigen Umgebungen funktioniert es ohne Probleme, wieder andere benötigen das Entladen der Kernel Module oder Stateless Regeln im Portfilter. Was auf jedenfall Hilft: Automatisches QoS aktivieren (zwecks Priorisierung der Pakete)
Das Problem (meistens) ist: VoIP (insbesonders SIP) ist zwar genormt, aber irgendwie auch nicht. Viele VoIP Anbieter halten sich nicht dran oder machen irgendetwas anders.
Bei mir privat funktioniert VoIP ohne Probleme (aktuelle Version, Portweiterleitung für SIP auf eine Easybox von Vodafone die nur VoIP macht). Egal ob mit oder ohne geladenen Modulen.
Eventuell könnten die Probleme auch mit dem Thema hier zu tun haben:
https://support.securepoint.de/viewtopic.php?t=5668
Gruß
Kenneth