1900EF - NAT Refresh zeitlich steuern/entzerren

[BjörnG]

Moin zusammen,

ich hab hier ein nerviges Problem mit dem NATting des Routers.
Ich muss und möchte verhindern, daß für alle Clients im Netz gleichzeitig die NAT Tabelle neu aufgebaut wird.

Warum? Wir nutzen VoIP-Telefonie (Starface) als Cloud-Dienst.
Die Cloud-Anlage holt sich alle 60Sek. die IP/NAT-Daten der Clients, also wird die NAT Tabelle -nach Empfehlung des Herstellers- alle 61Sek. neu aufgebaut.

Es passiert alle paar Tage, manchmal aber auch erst nach Wochen, leider, daß dann zeitgleich alle VoIP-Clients die Verbindung zu Cloud verlieren.
Die User haben Panik, und gefühlt, werden mir auf 10.000 Kanälen die Störungen gemeldet. In der Regel ruckelt es nur kurz, und alle können wieder telefonieren.

Soweit so gut. Works as designed... leider...

Wie kann ich den LANCOM dazu zwingen die Verbindungen in der NAT Tabelle nicht mehr für alle gleichzeitig zu refreshen und statt dessen eine zeitliche Steuerung oder Gruppierung der Verbindungen zu etablieren?

So, daß bsplw. nur die hälfte der User ggf. die VoIP-Verbindung kurz verlieren, die andere Hälfte aber nicht betroffen ist, da sie in einem anderen 'refresh-timeslot' verortet sind?

Soweit verstanden? Oder war das jetzt zu konfus?

Habt einen angenehmen Freitag. Freue mich auf Rückmeldungen.

Grüße,
Björn

[5624]

Ich würde eher sagen, dass dies nichts mit dem LANCOM-Router zu tun hat. Man kann das NAT-Timeout beeinflussen, dieses befindet sich in der Regel aber im geringen Minutenbereich und nicht bei 1h. Und dieses wird durch jeglichen Traffic neu angesteuert. Da ja scheinbar telefoniert wird, wird also mit jedem SIP- und/oder RTP Paket das Timeout zurückgestellt.
Es wird also nicht zeitgleich auf allen Telefonen zuschlagen, sondern nur auf denen, die längere Zeit ungenutzt sind.

Ich seh den Fehler hier eher bei den Telefonen oder der Telefonanlage.

[BjörnG]

Ich würde eher sagen, dass dies nichts mit dem LANCOM-Router zu tun hat.
.
.
Ich seh den Fehler hier eher bei den Telefonen oder der Telefonanlage.

Danke für deine Rückmeldung. Ich bin da völlig bei dir und sehe das ähnlich.
Der Cloud-Server und die Clients bieten hier keine Einstellungsmöglichkeiten, zumindest keine die mir bekannt sind. Und der Hersteller konnte mir an der Stelle bisher auch keine belastbaren/nutzbaren Informationen an die Hand geben.
Daher der Gedanke, an der Stelle zu schrauben, an der ich schrauben kann. Nämlich am Router.
Schön ist was anderes, aber so ist das in der IT manchmal.

[BjörnG]

KORREKTUR, natürlich war 61Sek. gemeint. Hab mich beim schreiben schon gewundert, aber dann vergessen es zu verifizieren. Sorry.

https://knowledge.starface.de/pages/vie ... d=46567321

Die Cloud-Anlage holt sich alle 60SEK. die IP/NAT-Daten der Clients, also wird die NAT Tabelle -nach Empfehlung des Herstellers- alle 61SEK. neu aufgebaut.

[5624]

Dann passt es mit den Routerwerten noch immer nicht, weil die stehen auf 300 Sekunden für TCP und der für dich relevante Wert UDP liegt bei 120 Sekunden.
Du kannst es bei dir im Router unter IP-Router => Maskierung nochmal gegenprüfen, aber man dreht die Werte eher hoch als runter.

[Dr.Einstein]

SIP-TCP? Stell doch einfach dein NAT Timeout für TCP auf 8 Stunden. Dann sollten doch alle Probleme wegsein.

[5624]

TCP hab nirgendwo gelesen. Kenn Starface aber auch nicht, ich bevorzuge Steinzeittechnik von was mal Siemens war.

[GrandDixence]

Wie im oben verlinkten Fehlerleitfaden beschrieben, muss auf allen VoIP-Telefonen der Einsatz von "NAT Keepalive" eingeschaltet sein. Das auf den VoIP-Telefonen konfigurierte Intervall von "NAT Keepalive" muss auf allen VoIP-Telefonen deutlich kürzer sein als die Konfiguration "UDP Aging" (oder "TCP Aging") in allen NAT-Komponenten (zum Beispiel: LANCOM-Router). Siehe dazu:
fragen-zur-lancom-systems-routern-und-g ... ml#p101310

fragen-zum-thema-vpn-f14/fehlermeldunge ... tml#p98088

https://community.sunrise.ch/d/20070-gi ... achrichten

Zustandstabelle der SPI-Firewall beobachten:
fragen-zum-thema-firewall-f15/verschluc ... 19377.html

Und ja, für SIP (Signalisierung von Telefongesprächen) ist der Einsatz von TCP anstelle von UDP zu empfehlen. Die Signalisierung von Telefongesprächen ist nicht zeitkritisch. Somit gibt es keinen wirklichen Grund auf Kundenseite für den Einsatz von UDP für SIP. Abwicklung von SIP über Serverport TCP Port 5060 anstelle von UDP Port 5060 konfigurieren. Und aus Sicherheitsgründen sollte ausschliesslich verschlüsselte Kommunikation mit dem SIP-Registrar per SIPS (TCP Port 5061) realisiert werden. Dann kann man auch die verschlüsselte Sprachdatenübertragung mit SRTP realisieren. Zu SRTP siehe BSI TR-02102-1:
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html

Aber nein, die meisten SIP Registrare unterstützen kein SIP über TCP und schon gar kein SIPS. Und die Sprachdaten werden vorwiegend unverschlüsselt mit RTP übertragen. Die Übermittlung der Sprachdaten von Telefongesprächen ist zeitkritisch und sollte somit per UDP erfolgen.

Ein kurzer Einstieg in die Welt der VoIP-Telefonie mit SIP und RTP bietet:
https://www.bsdforen.de/threads/gigaset ... ost-330634

[Dr.Einstein]

TCP hab nirgendwo gelesen. Kenn Starface aber auch nicht, ich bevorzuge Steinzeittechnik von was mal Siemens war.

Ich hatte vorhin 60 Minuten gelesen, nicht Sekunden. Ich glaub, dass hat der Threadersteller editiert. Bei 60 Min wäre ich von TCP ausgegangen, bei 60 Sek von UDP. Dann halt UDP auf kA 30 Minuten hochstellen, oder mehr.

[BjörnG]

Wie im oben verlinkten Fehlerleitfaden beschrieben, muss auf allen VoIP-Telefonen der Einsatz von "NAT Keepalive" eingeschaltet sein. Das auf den VoIP-Telefonen konfigurierte Intervall von "NAT Keepalive" muss auf allen VoIP-Telefonen deutlich kürzer sein als die Konfiguration "UDP Aging" (oder "TCP Aging") in allen NAT-Komponenten (zum Beispiel: LANCOM-Router). Siehe dazu:
fragen-zur-lancom-systems-routern-und-g ... ml#p101310

fragen-zum-thema-vpn-f14/fehlermeldunge ... tml#p98088

https://community.sunrise.ch/d/20070-gi ... achrichten

Zustandstabelle der SPI-Firewall beobachten:
fragen-zum-thema-firewall-f15/verschluc ... 19377.html

Und ja, für SIP (Signalisierung von Telefongesprächen) ist der Einsatz von TCP anstelle von UDP zu empfehlen. Die Signalisierung von Telefongesprächen ist nicht zeitkritisch. Somit gibt es keinen wirklichen Grund auf Kundenseite für den Einsatz von UDP für SIP. Abwicklung von SIP über Serverport TCP Port 5060 anstelle von UDP Port 5060 konfigurieren. Und aus Sicherheitsgründen sollte ausschliesslich verschlüsselte Kommunikation mit dem SIP-Registrar per SIPS (TCP Port 5061) realisiert werden. Dann kann man auch die verschlüsselte Sprachdatenübertragung mit SRTP realisieren. Zu SRTP siehe BSI TR-02102-1:
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html

Aber nein, die meisten SIP Registrare unterstützen kein SIP über TCP und schon gar kein SIPS. Und die Sprachdaten werden vorwiegend unverschlüsselt mit RTP übertragen. Die Übermittlung der Sprachdaten von Telefongesprächen ist zeitkritisch und sollte somit per UDP erfolgen.

Ein kurzer Einstieg in die Welt der VoIP-Telefonie mit SIP und RTP bietet:
https://www.bsdforen.de/threads/gigaset ... ost-330634

Komme leider jetzt erst wieder dazu das Feedback hier zu sichten. Vielen lieben Dank für die ausführliche Antwort. Das sieht so aus, als wenn ich damit dem Ziel näher komme. Ja SIP kann per TCP gemacht werden. Die Streams RTP sollen dann aber schon via UDP laufen. Tun sie auch. Jetzt muss ich nur rausfinden wie ich das entknote, also Anruf initialisieren via TCP, Gespräch dann aber via UDP. Hatte irgendwie vorausgesetzt, weils mir wegen DNS und NAT logisch erschien, daß das automatisch so sei, daß Initialisierung und Gespräch jeweils über TCP und dann UDP laufen. Hab da wohl eine Bildungslücke die ich dann noch schliessen muss.