Gelöst: Sipura hinter NAT + Zwangstrennung (ohne Routereingriff!)

[tuttut]

Lösung siehe mein 2. Posting hier!

Hallo,
schon seit langer Zeit versuche ich das Problem einen SPA zuverlässig hinter einem NAT-Router zu betreiben in den Griff zu bekommen. Die 24-Stunden Zwangstrennung sorgt jedoch zuverlässig für Probleme, so dass nach einer Trennung immer die Registrierung des einen oder anderen Accounts auf meinem SPA-3000 dauerhaft fehlschlägt (Registration State: Failed).

Als Router benutze ich eine ältere Version von IPCop und habe schon sämtliche Prozeduren ausprobiert, die NAT-Mapping-Tabelle bei einer Zwangstrennung zu löschen. Unter anderem habe ich folgendes Skript gebaut, welches bei einem Verbindungsauf- und abbau aufgerufen wird:

#!/bin/sh
echo "1" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
sleep 15
echo "180" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

Obwohl das Skript ausgeführt wird, stehen in der NAT-Tabelle (cat /proc/net/ipcontrack) alte UDP-IP-Mappings. Es bleibt also unzuverlässig...

ABER:
Letztens bin ich über den Eintrag Reg Retry Intvl gestolpert, meine Idee war es nun, diesen Eintrag auf einen Wert größer als in ip_conntrack_udp_timeout_stream zu stellen: Dadurch sollte das Problem ganz ohne Eingriffe in den Router zu lösen sein, denn wenn die Registrierung fehlschlägt, würde der SPA einfach einige Minuten mit dem nächsten Registrierungsversuch warten. In dieser Zeit wird auch bei älteren Routern das Tracking gelöscht...
Aber Pustekuchen: Obwohl nun die Re-registrierung verzögert wird, sendet dieser doofe SPA weiterhin die ja sonst benötigten Keep-Alive-Messages, womit mein schöner Traum von einem Problemlosen Betrieb hinter einem NAT-Router ohne Portforwardings zerplatzt. Würde die Firmware so schlau sein und diese Keep-Alive-Messages auch nicht senden, wäre die 24-Stunden-Trennung sicher viel unproblematischer bei vielen Router-Nutzern...

Habe ich eine Einstellungsmöglichkeit übersehen oder wäre das vielleicht wirklich mal ein wichtiger Verbessungsvorschlag für die Firmware der Sipuras?

Gruß Lutz

 

[zoo]

Das Problem ist mir auch bekannt. Ich habe es letztendlich dadurch gelöst, dass ich bei mir einen Siproxd auf dem Router einsetze. Ansonsten gibt es ja auch schon einen NAT-helper für SIP. Habe ich aber noch nicht ausprobiert.

 

[tuttut]

Lösungsmöglichkeit gefunden!

Hallo,
mittlerweile ist mir selbst eine Lösungsmöglichkeit in den Sinn gekommen, die ich im moment ausprobiere, vielleicht können andere Benutzer diese mal testen und ihre Erfahrungen dazu hier posten. Mein Lösungsansatz besteht darin, die nötigen NAT-Keepalive-Messages nicht durch das dafür vorgesehende System im SPA erzeugen zu lassen, was übrigens oft zu "falschen Fehlern" in der Syslog führt, wenn SIP-Server dieses NOTIFY-Kommando nicht kennen, sondern durch etwas regelmäßigere Registrierungsvorgänge. Die Registrierungsvorgänge halten nämlich den Port ebenso offen, so dass bei einem genügend kleinem Intervall das Keep-Alive vom SPA überflüssig wird. Hier mal ein "Rezept" von mir zur vorgehensweise.

Zuverlässiger Betrieb eines SIPURAS hinter NAT-Router trotz Zwangstrennungs-Problematik
1. Schritt: Herausfinden, wie lange UDP-Mappings in der NAT-Tabelle gespeichert werden. Dazu entweder auf Erfahrungswerte zurückgreifen oder im Linux-Router diesen Wert abrufen als root mit folgendem Kommando (klappt aber nur wenn netfilter im Einsatz ist):

 cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

Dies ergibt bei meinem IPCOP 1.4.6 den Wert 180, also nach 180 Sekunden inaktivität auf dem UDP-Port wird dieser aus der Tabelle verworfen und kann mit neuer IP-Adresse aufgenommen werden. Also, um das Mapping aufrecht zu erhalten, damit der SPA angerufen werden kann, muss in Abständen von unter 180 Sek. auf diesen Port etwas passieren. Im Fehlerfall, also bei falscher IP durch die Zwangstrennung muss für eine Zeitspanne von mind. 180 Sek. absolute Funkstille auf diesem Port herschen.

2. Schritt: Im SPA unter "SIP" - "SIP Timer Values (sec)" muss für die Parameter "Reg Retry Intvl:" und "Reg Retry Long Intvl:" ein Wert eingetragen werden, der ein etwas (etwa 10%) größer ist als der udp-timeout, also im vorliegenden Fall nutze ich z.B. 300.
Unter "NAT Support Parameters" sollten die Einstellungen so sein, als wenn man NAT benutzt (was ja weiterhin der Fall sein soll), also das meiste auf "YES" sowie ein gültiger STUN-Server.
Der Parameter "NAT Keep Alive Intvl:" spielt dabei keine Rolle, da der Trick ja genau darin besteht, dieses nicht zu nutzen. Falls Sipura mit einem Firmwareupdate reagiert und bei fehlerhaften Registrierungen auch die Keep-Alive-Nachrichten unterdrückt, wird man diesen Wert wieder nutzen können. Hier sollte ein Wert eingetragen werden, der etwas kleiner ist als der udp-Timeout, im vorliegenden Fall nutze ich hier 25.

3. Schritt: In den entsprechenden Line-Settings unter "Line 1" bzw. "PSTN Line" nun unter "NAT Settings" zwar "NAT Mapping Enable:" auf "YES" belassen , aber die Keep-Alive-Nachrichten deaktivieren, in dem "NAT Keep Alive Enable:" auf "NO" gesetzt wird. Die Einstellungen für "NAT Keep Alive Msg:" und "NAT Keep Alive Dest:" bleiben auf den Defaultwerten.
Damit bei erfolgreicher Registrierung die NAT-Tabelle erhalten bleibt, wird nun der Registrierungsintervall auf einen Wert eingestellt, der kleiner als das UDP-Timeout ist. Dazu unter "Proxy and Registration" die Parameter "Register Expires:" und "Proxy Fallback Intvl:" entsprechend belegen. In meinem Fall habe ich 120 eingetragen. Damit erfolgt alle 120 Sekunden eine erneute Registrierung, was auch dafür sorgt, das der Eintrag in der NAT-Tabelle weiterhin gültig bleibt.

Mit diesen Einstellungen sollte es möglich sein, ohne Veränderungen am Router und ohne Portweiterleitungen den SPA hinter einem Router zu betreiben. Bei einer Zwangstrennung dauert es dann etwa "Reg Retry Intvl:" + "Register Expires:" Sekunden, bis der SPA wieder eine neue erfolgreiche Registrierung hat.

Bitte eure Erfahrungen und auch eure UDP-Timeout-Werte hier mal posten.

Gruß Lutz

Update:
Mittlerweile habe ich diese Lösung einige Zeit getestet und die Zwangstrennung hat keine größeren Probleme mehr bereitet, daher deklariere ich es als eine Lösung.

 

[reinerh]

Hi!

Ich hatte dasselbe Problem und deine Lösung hat mir auch geholfen.

Vielen Dank!

 

[zoo]

Komisch ist, dass ich dieses Problem immer nur zu QSC hatte und nicht zu meinem Asterisk Server. Ich werde die Tage vielleicht mal deinen Vorschlag ausprobieren

 

[tuttut]

Das wäre logisch, wenn dein Asterik-Server im lokalen Netz ist und QSC im Internet. Die Problematik taucht nur auf, wenn der SPA über einen NAT-Router "nach draussen" telefoniert, im lokalen Netz gibts normalerweise weder NAT noch entsprechende NAT-Tabellen...

 

[gandalf94305]

Die Deaktivierung von Keepalives kann natürlich dazu führen, daß die Registrierung länger als die Abbildung des NAT-Ports lebt, d.h. eingehende Gespräche nicht mehr ankommen.

--gandalf.

 

[tuttut]

Nein, es läuft ja alles über den selben Port. Für den Verbindungsaufbau als auch zur Anrufsignalisierung ist der Port zuständig, der auch zur Registrierung verwendet wird.

 

[gandalf94305]

Genau... und wenn das NAT-Mapping des Ports, der zur Registrierung verwendet wurde, abläuft bevor die Registrierung ausläuft, dann können Pakete, die an diesen SIP-Port gerichtet sind, nicht mehr ins lokale Netz weitergereicht werden, da der Router diesen Port nicht mehr kennt...

--gandalf.

 

[tuttut]

Richtig. Und daher wird das Registrierungsintervall ja kürzer eingestellt, als die Gültigkeitsdauer der NAT-Mappings.
Was ich bisher noch nicht erwähnt habe, ist das es bei einer neuen Registrierung wärend eines Telefonates ein leichtes Knacksen hören kann, was man vermutlich nur bemerkt, wenn man den Countdown unter "Next Registration In:" beim Telefonieren im Auge behält.

 

[zoo]

Das wäre logisch, wenn dein Asterik-Server im lokalen Netz ist und QSC im Internet.

Ich habe aber nicht gesagt, dass der Asterisk im lokalen Netz steht. Der steht auch extern.

 

[Gortosch]

Grüße,
finde das Thema klasse und sollte sticki gemacht werden...
Kennt jemand die UDP-Timeout-Werte von einem Netgear Router der neueren Serien?

de Gortosch...

 

[ROCK01]

DANKE tuttut ! 1000x Danke.

Ich habe heute den gesamten Tag nach einer Lösung für das Problem gesucht und Deine passt einfach Perfekt.

Mein Setup:

Gateway(Router inkl. Modem) Linksys WAG300N dahinter ein Linksys (Sipura) 2102.

Der Linksys hat auch den ip_conntrack_udp_timeout_stream Timeout von 180.
Nachdem ich deine Settings übernommen hatte ist es mir seit Stunden zum ersten mal gelungen nach einer Trennung vom ISP wieder mit dem Sipura zu telefonieren ohne den Router händisch oder per Telnet neu zu starten.

Das man dabei ein paar Minuten online ist stört mich keines Wegs.

TOP!

Eventuelle Schreibfehler stammen aus meiner momentanen Hochstimmung

Ich fänds klasse wenn das ein Sticky würde - oder spricht was dagegen?

 

[phl_99]

Auch ich schließe mich dem Dank einmal an. Nachdem ich erst kurz vor Weihnachten die PAP2T erstanden habe, habe ich durch diesen Beitrag unser Telefon wieder im Griff.

DANKE!