[Problem] N510 Kein zuverlässiger Verbindungsaufbau zu Sipgate

Hi,

wir setzen in unserem Unternehmen zwei N510 IP Pro Basistationen (Firmware 42.199) und 6x C610H Mobilgeräte (je Station 3 Geräte).

VoIP Provider ist Sipgate,
VDSL-Anschluss via Telekom Business VDSL 50,

Modem Zyxel VMG1312-B30A (alle ALG deaktiviert) <----> TP-Link N750 mit OpenWRT-Firmware (ohne installierte VoIP oder QoS oder SIP-Pakete) <---> N510 IP

IP-Verbindungen beginnen bei beiden N510 erst ab dem 2. Eintrag. Port Range für SIP / RTP inkl. Forwarding vom Open-WRT-Router zu den N510 ist konfiguriert (erste SIP 5160, RTP 5104-5120, zweite SIP 5260, RTP 5204-5220).

Aktuell haben wir das Problem, dass zumindest werktags gegen 7:00 Uhr morgens scheinbar die VDSL-Verbindung abbricht (Telekom versichert uns, dass wir keine Zwangstrennung haben). Das wirkt sich auf die N510 aus: Wenn die Verbindung zu Sipgate mit allen 6 IP-Verbindungen erstmal hergestellt ist, funktioniert das Telefonieren tadellos.

Nach (simuliertem) Verbindungsabbruch, bauen die N510 allerdings die Verbindungen zu Sipgate nicht mehr zuverlässig auf. Bisher ist nicht klar, ob ein Geräteneustart und aktivieren/deaktivieren der Verbindungen im N510-Webfrontend hilft, es funktioniert jedesmal erst wieder nach einer undefiniert langen zeit (meist mehr als 10 minuten). Dann geht am nächsten Werktag das Spiel von vorne los. Man muss aber manuell tätig werden, sonst dauert es min. eine Stunde bis die Geräte wieder angemeldet sind. Zu letzt wurden auf den C610H noch nicht mal mehr "Anmeldung beim Provider fehlgeschlagen" angezeigt. Anmelde-Refreshzeit übrigens nach Anraten von Sipgate auf 600 Sekunden bei allen IP-Accounts gestellt (ohne Erfolg).

Scheinbar bauen die N510 die Verbindung nach einem Abbruch der VDSL-Leitung nicht mehr zuverlässig auf, bzw. bekommen das nicht mit.

Alternativer Tausch der N510 durch C610 mit 42.075 Firmware brachte keine Änderung im Verhalten (ich habe auch schon versucht die C610 mit der 199er Firmware zu flashen, was nicht funkioniert hat -> Firmware wurde vom Gerät geladen, Update läuft aber endlos).

Was könnte hier noch versucht werden? Ich bin ratlos.

Danke und viele Grüße,
arnold1001

Hallo rmh,

danke für den Tipp! Ich habe gerade mal die Konfiguration angepasst. Bisher haben die DECT-Stationen die Verbindung auf 'manuell' umgestellt, denn das war eine dynamische Zuweisung (im Router hatte ich ein Static Lease eingetragen).

Die neuen DNS-Server sind jetzt

DNS 1: 217.237.148.102
DNS 2: 217.237.151.115

Ich beobachte und melde mich wieder zurück. Nach Neustart (der erforderlich war) beider Basisstationen sind die Verbindungen schonmal erhalten geblieben. Auch ein Disconnect des WAN hat die Verbindungen noch nicht zum Erliegen gebracht. Definitiv ein Schritt vorwärts! DANKE

Ok, etwas zu früh gefreut. Nach Änderung der Einstellungen war die Anmeldung zwar erhalten, Leitungstest von außen (Sipgate und vom Handy) führten auch zum Klingeln auf den Endgeräten, aber es kam kein Gespräch zu stande. Die Geräte klingelten einfach weiter. Vom Handy aus gab es kein Freizeichen, aber die Endgeräte haben geklingelt. Nach Abnehmen auf dem Handy "Der gewünschte Gesprächspartner ist nicht erreichbar".

Dann Neustart der N510 über das Frontend. Anschließend wieder auf allen 6 Verbindungen: Anmeldung fehlgeschlagen.

@informex: Danke für den Hinweis. Das teste ich ggf. am Freitag nochmal. Leider zeigen ja beide Basis-Stationen dasselbe verhalten, egal welche Version.

Beide N510 haben nun wieder die Connection verloren und können sie auch nicht mehr aufbauen, nachdem gegen 15:00 Uhr wieder die WAN-Verbindung im Router abgebrochen wurde und anschließend neu aufgebaut worden ist.

Könnte das vielleicht mal jemand simulieren? Die WAN-Verbindung zu trennen und anschließend wieder zu connecten um dann im Gigaset den Status gegenzuchecken?

Das keine Pakete ankommen verstehe ich nach Deiner Beschreibung, allerdings verbinden sich die Telefone ja nicht mal mehr mit Sipgate. Bis scheinbar eine bestimmte Zeitspanne abgelaufen ist und dann funktioniert die Anmeldung wieder. Kann das auch am NAT liegen?

Falls ja: kann ich da irgendwas gegen machen? Open-WRT wird doch auch von anderen in einer ähnlichen Konstellation eingesetzt, wenn ich das hier im Forum richtig gelesen habe...

OK, das prüfe ich.

Allerdings verstehe ich immer noch nicht, weshalb ich die Gigaset N510 (und auch C610) neu Starten muss, ansonsten bekommen die (scheinbar) NIE mehr eine Verbindung zu Sipgate.

Es scheint immer gleich zu sein:

1. Verbindung geht verloren
2. Bis zum folgenden Vorgehen erhalten die Telefone KEINE neue Verbindung mehr, auch nicht beim einzelnen deaktivieren und aktivieren der Verbindungen
3. Alle Verbindungen auf beiden DECT-Stationen einzeln deaktivieren
4. Beide DECT-Stationen über das Frontend neu starten
5. Mindestens 5 Minuten warten
6. Jede einzelne Verbindung, nacheinander wieder aktivieren

OK, erneuter Verbindungsabbruch. Vermutlich Zwangstrennung durch Telekom am Business VDSL-Anschluss nach 24h. Telekom Hotline versicherte uns keine Zwangstrennung durchzuführen... Der 24h-Rhytmus passt aber.

Zwischendurch auf dem Open-WRT das Paket "conntrack-tools" installiert.

Diesmal bin ich so vorgegangen:

Erstmal in den N510 alle Verbindungen deaktiviert. Dann:

root@router:~# conntrack -L | grep 192.168.1.185
conntrackudp 17 3331 src=192.168.1.185 dst=217.10.68.147 sport=5160 dport=5060 packets=948 bytes=507317 [UNREPLIED] src=217.10.68.147 dst=XX.XX.XX.XX sport=5060 dport=5160 packets=0 bytes=0 mark=0 use=1
udp 17 56 src=192.168.1.185 dst=217.237.148.102 sport=32978 dport=53 packets=11 bytes=722 src=217.237.148.102 dst=XX.XX.XX.XX sport=53 dport=1026 packets=11 bytes=1237 [ASSURED] mark=0 use=1

und nach einer Weile

root@router:~# conntrack -L | grep 192.168.1.185
tcp 6 110 TIME_WAIT src=192.168.1.185 dst=148.251.243.133 sport=60418 dport=80 packets=7 bytes=1555 src=148.251.243.133 dst=XX.XX.XX.XX sport=80 dport=60418 packets=6 bytes=1096 [ASSURED] mark=0 use=2
udp 17 3228 src=192.168.1.185 dst=217.10.68.147 sport=5160 dport=5060 packets=948 bytes=507317 [UNREPLIED] src=217.10.68.147 dst=XX.XX.XX.XX sport=5060 dport=5160 packets=0 bytes=0 mark=0 use=1
udp 17 50 src=192.168.1.185 dst=217.237.148.102 sport=32978 dport=53 packets=1 bytes=64 src=217.237.148.102 dst=XX.XX.XX.XX sport=53 dport=32978 packets=1 bytes=80 mark=0 use=1
conntrack v1.0.0 (conntrack-tools): 127 flow entries have been shown.

Ich habe dann geflusht (und die SSH-Verbindung zum Router verloren)

root@router:~# conntrack -F

Danach ohne Neustart auf den N510 die Verbindungen wieder aktiviert. Es hat ein paar Sekunden gedauert und die Verbindungen wurden sofort wiederhergestellt (aber nicht automatisch, scheinbar - es kann aber sein, dass der Refresh noch nicht kam).

Die Cronjob-Lösung teste ich als nächstes, allerdings finde ich es jetzt schon befremdlich, dass sich die N510 nicht automatisch eingewählt haben (oder ich nicht lange genug gewartet habe?) - tun sie das denn normalerweise?

Also nach weiterer Beobachtung: Verbindung trennt wieder zuverlässig nach 24h, direkt conntrack -F zum flushen. Telefone verbinden sich NICHT automatisch von selbst wieder. Wartezeit: 30 Minuten.

Auch Häkchen wegnehmen und wieder setzen bringt gar nichts.

STUN -> war in der Sipgate-Anleitung explizit deaktiviert. Muss ich da noch etwas berücksichtigen? Ich teste das als nächstes.

Alle 6 Verbindungen sind nun via stun.sipgate.de:10000 mit Refresh-Zeit von 600 Sekunden, gemäß Allgemeine Sipgate-Konfigurationsanleitung konfiguriert.

Anmelden konnten sich die N510 wieder nur nach deaktivieren und reset und reaktivieren... (diesen Teil verstehe ich rein gar nicht).

Outbound-Proxy war (und ist noch) aktiv (konfiguriert auf 'immer').

Das bedeutet, dass ich Portfreigaben gar nicht benötige? Die Verbindung an sich ist die gesamte Zeit über stabil für eingehende/ausgehende Telefonate, bis eben die Zwangstrennung erfolgt.

Weiterhin loggen sich die Geräte nach der Zwangstrennung nicht neu ein. Es ist immer ein manueller Reset erforderlich.

Die aktuelle Konfiguration ist nun so, dass ich nur noch STUN konfiguriert habe und auf dem Router bei jedem WAN-up via hotplug die conntrack-queue mit "conntrack -F conntrack" geflusht wird.

Gibt es novh etwas was ich versuchen kann?

Mittlerweile nach diversen tcpdump-Sitzungen direkt an unserem router hat sich folgendes herausgestellt:

1. Die DECT-Stationen senden ein REGISTER Paket an sipgate via UDP, wenn die Verbindung getrennt wird. Diese Pakete werden jedoch nicht beantwortet (bzw. beteuert sipgate das die Pakete nicht bei ihnen ankommen)

2. Die SRC-Ports der Geräte bleiben bestehen, wenn man sie nicht rebootet. Durch den reboot bekommen die DECT-Stationen einen neuen SRC-port und sipgate antwortet wieder auf die REGISTER-pakete (bzw. diese kommen nun bei sipgate an).

3. Testweise ein Softphone genutzt: Dasselbe (!) verhalten. Das Softphone muss beendet und neu gestartet werden (sonst derselbe SRC-port und die UDP-pakete verlassen den Router, kommen aber nicht bei sipgate ...)

3. Testweise einen Asterisk-Server im Internet aufgesetzt: Dasselbe (!) Verhalten: REGISTER-Pakete verlassen unseren Router, kommen aber nicht auf unserem Server an.

Nun ist komplette Ratlosigkeit angesagt: Die aktuelle Vermutung ist, dass die Telekom ggf. diese Pakete wegfiltert. Eine letzte Quelle könnte noch das Zyxel Modem sein, wobei mir unerklärlich ist, weshalb das bei weiteren REGISTER-Paketen mit demselben SRC-Port UDP-Pakete herausfiltert...

Scheinbar ist das ganze auch egal ob wir UDP oder TCP verwenden (sipgate unterstützt nur UDP, unser Asterisk kann TCP).

Irgendwelche Ideen?