NAT timeout für udp und tcp

[Erwin Lottermann]

Es geht mal wieder um Einstellungen für SIP/RTP.

Für den Betrieb hinter einem maskierenden Router haben diverse SIP User
Clients eine Option, um per SIP-Ping Richtung SIP-Proxy den NAT-Eintrag
im Router für die SIP-Verbindung zum SIP-Proxy am Leben zu erhalten.
Dabei kann man einen zeitlichen Abstand für den SIP-Ping im SIP-Client
einstellen. Ziel ist es, den SIP-Ping-Abstand möglichst groß
einzustellen. Die Obergrenze bestimmen die Routereinstellungen für den
NAT timeout. Üblicherweise sind die für UDP und TCP unterschiedlich.

SIP kann sowohl über UDP als auch über TCP abgewickelt werden.
Meistens scheint es UDP zu sein. (RTP ist immer udp)

Kann mir jemand sagen, wie groß die NAT Timeout Einstellungen für UDP
und TCP im fli4l sind?

[Christoph Schulz]

Hallo!

Erwin Lottermann schrieb:

> Kann mir jemand sagen, wie groß die NAT Timeout Einstellungen für UDP
> und TCP im fli4l sind?

Für UDP:

# cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
30
# cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
180

Der erste Wert gilt, falls noch nicht viele Pakete hin- und hergegangen sind
(Conntrack-Zustand ESTABLISHED aber nicht ASSURED).

Da TCP ein verbindungsorientiertes Protokoll ist, sind hier prinzipiell
keine Timeouts zum Einstellen nötig. (Beispiel:
nf_conntrack_tcp_timeout_established hat den Wert 432000, was fünf Tagen
entspricht, d.h. eine vernünftig aufgebaute Verbindung mit Paketen in beiden
Richtungen wird erst nach fünf Tagen "Datenlosigkeit" abgebaut, was mehr als
ausreichend ist.)


Viele Grüße,
--
Christoph Schulz
[fli4l-Team]

[Erwin Lottermann]

Danke,

in meiner Fritzbox 7170 sind 5 Minuten eingestellt, weil das der
Standardwert war.

Im Webinterface vom fli4l sehe ich, dass es eine aktive UDP Verbindung
von der FritzBox:5060 zum externen Sipproxy:5060 gibt.
Habe jetzt auch mal einige Minuten lang die Ansicht regelmäßig
aktualisiert. Die Verbindung war die ganze Zeit da.

Ein Portforwarding für 5060 auf die Fritzbox habe ich nicht konfiguriert.

Da scheint also noch irgend ein anderer Mechanismus am Werk zu sein,
denn die Verbindung verschwindet nicht nach 180s.

Gruß Erwin

[Erwin Lottermann]

Am 14.04.2016 um 22:04 schrieb Erwin Lottermann:
> in meiner Fritzbox 7170 sind 5 Minuten eingestellt, weil das der
> Standardwert war.
>
> Im Webinterface vom fli4l sehe ich, dass es eine aktive UDP Verbindung
> von der FritzBox:5060 zum externen Sipproxy:5060 gibt.
> Habe jetzt auch mal einige Minuten lang die Ansicht regelmäßig
> aktualisiert. Die Verbindung war die ganze Zeit da.
>
> Ein Portforwarding für 5060 auf die Fritzbox habe ich nicht konfiguriert.
>
> Da scheint also noch irgend ein anderer Mechanismus am Werk zu sein,
> denn die Verbindung verschwindet nicht nach 180s.
>

Vielleicht mal noch kurz vorab zur Info.
Derzeit mache ich nur erste Experimente mit SIP über einen SIP-Account
bei iptel.org
Dazu verwende ich eine Fritzbox 7170, die hinter dem fli4l hängt.
Produktive Telefonie läuft derzeit noch über ISDN.
Intenet ist ADSL2 16000 von der Telekom.
Die FB macht nur ISDN und die SIP-Experimente.

Habe jetzt mal eine Weile die offenen Verbindungen der FB im fli4l
Webinterface beobachtet.
Die FB hält 2 UDP Verbindungen mit Quell- und Zielport 5060 offen.
1. sip.iptel.org
2. res.iptel.org

Außerdem noch 1 bis 2 UDP Verbindungen mit Quellport 5060 und Zielport
3478 zu stun.t-online.de
stun.t-online.de habe ich in der FB als STUN-Server konfiguriert.

Gruß Erwin

[Matthias Taube]

Am 14.04.2016 um 22:04 schrieb Erwin Lottermann:

> in meiner Fritzbox 7170 sind 5 Minuten eingestellt, weil das der
> Standardwert war.
>
> Im Webinterface vom fli4l sehe ich, dass es eine aktive UDP Verbindung
> von der FritzBox:5060 zum externen Sipproxy:5060 gibt.
> Habe jetzt auch mal einige Minuten lang die Ansicht regelmäßig
> aktualisiert. Die Verbindung war die ganze Zeit da.

Also bei mir (Fritz und Telekom) hat das nicht geklappt.
Wenn von außen jemand angerufen hat, wurde die Verbindung mehr zufällig
aufgebaut oder lief ins Leere, weil ein udp-Timeout seit dem letzten
Ping der Fritz zugeschlagen hat.

Seit der Einrichtung von Portforward und PF_PREROUTING_CT[]='tmpl:sip
IP_NET_3 HELPER:sip' läuft alles problemlos.

LG
Matthias

[Erwin Lottermann]

Zur Zuverlässigkeit meiner derzeitigen Konfiguration kann ich noch
nichts sagen, da ich bisher zu wenige Tests gemacht habe.
Ich konnte einen Account anrufen, der auch per SIP erreichbar war
(Telekom SIP-Kunden sind z.B. nicht per SIP erreichbar)
und ein Telekom-SIP-Kunde, der eine Fritzbox als Router hat, konnte mich
per SIP anrufen, nachdem er meinen SIP-Account im Telefonbuch seiner
Fritzbox eingetragen hatte (mit normalen Telefonen kann man ja keine
SIP-Adresse eingeben)

Habe inzwischen einige RFCs zum Thema SIP/RTP und NAT überflogen.
Wenn ich es richtig verstanden habe, wird prinzipiell von expliziten
Routerkonfigurationen für SIP abgeraten, weil die ehe kontraproduktiv
sind. Denn:

1. Sind für SIP/RTP hinreichend Mechanismen spezifiziert, wie
SIP-User-Clients und SIP-Proxys mit NAT umzugehen haben und

2. führen spezielle SIP-Routerkonfigurationen meistens dazu, dass SIP
nur für einen Client hinter dem Router funktioniert. D.h. falls es dazu
kommt, dass Besucher in deinem Netz SIP nomadisierend benutzen wollen,
dann kann das durch die Rounterkonfiguration unmöglich sein.

Die Prinzipien helfen aber wenig, wenn man weder Einfluss auf den
SIP-Provider (z.B. weil der bisherige klassische Telefonanbieter seine
eigene Vorstellung von SIP hat) noch auf den SIP-User-Client (z.B. weil
der durch die Firmware der Fritzbox vorgegeben ist) hat.

Das Prinzip der Registrierung eines Sip-UserClients hinter einem
NAT-Router habe ich so verstanden:

Der SIP-Client muss wissen, dass er hinter einem NAT-Router sitzt und
muss folgende Dinge tun:
1. der User-Client muss per STUN die öffentliche IP-Adresse des Routers
bestimmen
2. da der User-Client keinen Einfluss auf den Quellport hat, den der
Router der Verbindung zuweist, muss er dem SIP-Registrar/Proxy bei der
Registrierung mittels 'rport'-Parameter mitteilen, dass er die
Kontaktaufnahme bei eingehenden Anrufen auf dem selben Port wünscht, den
der Router für die Verbindung vergeben hat.
3. der User-Client muss den NAT-Eintrag im Router per SIP-Ping am Leben
halten.

Wenn das so funktioniert, dann sendet der SIP-Proxy eingehende Anrufe
also gar nicht an Port 5060 des Routers und außerdem können sich aus dem
internen Netz mehrere SIP-Clients bei verschiedenen SIP-Proxies
registrieren.

Weißt du, was der conntrack helper für SIP genau macht?

[Matthias Taube]

Am 16.04.2016 um 11:14 schrieb Erwin Lottermann:

> Habe inzwischen einige RFCs zum Thema SIP/RTP und NAT überflogen.
> Wenn ich es richtig verstanden habe, wird prinzipiell von expliziten
> Routerkonfigurationen für SIP abgeraten, weil die ehe kontraproduktiv
> sind. Denn:
>
> 1. Sind für SIP/RTP hinreichend Mechanismen spezifiziert, wie
> SIP-User-Clients und SIP-Proxys mit NAT umzugehen haben und
>
> 2. führen spezielle SIP-Routerkonfigurationen meistens dazu, dass SIP
> nur für einen Client hinter dem Router funktioniert. D.h. falls es dazu
> kommt, dass Besucher in deinem Netz SIP nomadisierend benutzen wollen,
> dann kann das durch die Rounterkonfiguration unmöglich sein.

Zu 1 - Wie gesagt, das hat bei mir (Fritzbox hinter Fli4l) nicht
funktioniert. Möglicherweise hätte ich das durch drastisches Verkürzen
der SIP-Pings der Fritzbox ändern können.

Zu 2 - Ich habe in meinem Netz ja nur einen Client, nämlich die
Fritzbox. Die fungiert ja als lokaler Server für alle Telefone. Meine
Besucher fragen mich höchstens, ob sie mal mein Telefon verwenden können
- nomadisierende Nutzung von SIP dürfte im Heimbereich bisher kaum
vorkommen.

Ich bin erstmal froh, wenn es in der einen Konfiguration (Telekom SIP -
fli4l - fritzbox) stabil funktioniert. Bei der Telefonie ist der Rest
der Familie heikel - da kann es echt Stress geben wenn das nur instabil
klappt.

Und für die Tests rate ich Dir einfach mit dem Handy 10 Minuten lang
einmal pro Minute die Festnetznummer anzurufen - da sieht man dann ob
alle Anrufe bis zum Klingeln am Endgerät durchgeschaltet werden (und wie
lange es nach einem IP-Wechsel dauert, bis man wieder Anrufe
entgegennehmen kann).

> Weißt du, was der conntrack helper für SIP genau macht?

Nein, evtl. braucht man den auch bei einem so breiten Portforward nicht.
Aber zur Sicherheit lasse ich den drin - siehe die Ausführung mit dem
Stress oben.

LG
Matthias

[Erwin Lottermann]

Zitat: Matthias Taube schrieb am Sa, 16 April 2016 21:28
----------------------------------------------------

> Am 16.04.2016 um 11:14 schrieb Erwin Lottermann:
>
> > Habe inzwischen einige RFCs zum Thema SIP/RTP und NAT
> > überflogen.
> > Wenn ich es richtig verstanden habe, wird prinzipiell von
> > expliziten
> > Routerkonfigurationen für SIP abgeraten, weil die ehe
> > kontraproduktiv
> > sind. Denn:
> >
> > 1. Sind für SIP/RTP hinreichend Mechanismen spezifiziert, wie
> > SIP-User-Clients und SIP-Proxys mit NAT umzugehen haben und
> >
> > 2. führen spezielle SIP-Routerkonfigurationen meistens dazu,
> > dass SIP
> > nur für einen Client hinter dem Router funktioniert. D.h. falls
> > es dazu
> > kommt, dass Besucher in deinem Netz SIP nomadisierend benutzen
> > wollen,
> > dann kann das durch die Rounterkonfiguration unmöglich sein.
>
> Zu 1 - Wie gesagt, das hat bei mir (Fritzbox hinter Fli4l) nicht
> funktioniert. Möglicherweise hätte ich das durch drastisches
> Verkürzen
> der SIP-Pings der Fritzbox ändern können.
>

Ich hätte da eher den Verdacht, dass das SIP-Ping in deinem Fall ganz
wirkungslos war.
Bei mir ist es ja auch so, dass die in der FB eingestellten 5 Min. für
das SIP-Ping größer sind als das UDP-Timeout des fli4l, das hier
genannt wurde.
Also müsste mein NAT-Eintrag laufend weg sein.
Zumindest laut Webinterface des fli4l kann ich das aber nicht
nachvollziehen.

Kann mir jemand sagen, wie man den Quellport sehen kann, den der fli4l
für die UDP-Verbindung vergibt?
Im Webinterface des fli4l habe ich nur den Quellport von der FB und den
Zielport am SIP-Proxy gesehen.

Wenn das NAT des fli4l so arbeitet, dass es den Quellport des
SIP-Clients auch nach außen verwendet, so lange es für diesen Port
noch keinen Eintrag in der NAT-Tabelle gibt, dann wäre das eine
mögliche Erklärung, warum die SIP-Verbindung manchmal funktioniert und
manchmal nicht.
Es funktioniert immer dann, wenn der fli4l Port 5060 als Quellport für
die Verbindung vergibt und funktioniert nicht mehr, wenn der fli4l einen
anderen Quellport für die Verbindung vergibt, weil es noch einen
NAT-Eintrag für 5060 gab.

Laut https://tools.ietf.org/html/rfc6314 soll ein SIP-UserClient hinter
einem NAT-Router dem SIP-Proxy per STUN und SIP-RPORT-Parameter
mitteilen, dass er auf dem Port zu erreichen ist, den der NAT-Router
vergeben hat.
Wenn das so funktioniert, dann macht ein Portforwarding für 5060 wenig
Sinn.

> Zu 2 - Ich habe in meinem Netz ja nur einen Client, nämlich die
> Fritzbox. Die fungiert ja als lokaler Server für alle Telefone.
> Meine
> Besucher fragen mich höchstens, ob sie mal mein Telefon verwenden
> können
> - nomadisierende Nutzung von SIP dürfte im Heimbereich bisher kaum
>
> vorkommen.
>
> Ich bin erstmal froh, wenn es in der einen Konfiguration (Telekom
> SIP -
> fli4l - fritzbox) stabil funktioniert. Bei der Telefonie ist der
> Rest
> der Familie heikel - da kann es echt Stress geben wenn das nur
> instabil
> klappt.
>

Ja, die klassischen Telefongesellschaften wollen SIP derzeit nur für
die Verbidnung zwischen ihrem Telefon-Gateway und dem Endkunden haben,
damit sie einen Teil der dedizierten Telefoninfrastruktur einsparen
können.

Wenn ich es dabei belasse, habe ich den starken Verdacht, dass der fli4l
bei mir einem von der Telekom verwalteten Router weichen wird, sobald
mir die Telekom den ISDN-Anschluss kündigt.

Vom technischen Hintergrund her erinnert mich das an mein
Homebanking-Programm, dass trotz Internet seine Transaktionen immer noch
per BTX machen wollte und die Telekom dazu ein BTX-Gaterway im Internet
bereitgestellt hatte.

M.E. ist Telefonieren mit den klassischen Telefonnummern tot, wenn es
keine dedizierte Infrastruktur mehr dafür gibt.
Die gibt es noch bei GSM und UMTS.

Gefühlt nimmt die Anzahl der Menschen, die nicht mehr über Festnetz
erreichbar sind, laufend zu.
SIP macht für mich am meisten Sinn, wenn ich auch per SIP erreichbar
bin und nicht nur über das Telefon-SIP-Gateway der Telekom.
Am naheliegendsten erscheint mir dabei, dass jede Email-Adresse
grundsätzlich auch als SIP-Account eingerichtet wird.

Derzeit möchte ich also darauf hinaus, dass meine häuslichen Telefone
per ISDN und per SIP erreichbar sind, so dass man ein Gefühl dafür
entwickeln kann, wie wichtig man die Erreichbarkeit unter der bisherigen
Festnetznummer überhaupt noch nehmen muss.
Außerdem müsste es nach Abschaltung der ISDN-Infrastruktur technisch
möglich sein, dass man bei der Telekom für seine Festnetznummer ein
Weiterleitung auf einen SIP-Account nach eigener Wahl hinterlegt, so
dass man für alle klassischen Anrufer unter der Nummer erreichbar
bleibt.

> Und für die Tests rate ich Dir einfach mit dem Handy 10 Minuten
> lang
> einmal pro Minute die Festnetznummer anzurufen - da sieht man dann
> ob
> alle Anrufe bis zum Klingeln am Endgerät durchgeschaltet werden
> (und wie
> lange es nach einem IP-Wechsel dauert, bis man wieder Anrufe
> entgegennehmen kann).
>

Mein Test-SIP-Account bei iptel.org ist nur per SIP erreichbar.

> > Weißt du, was der conntrack helper für SIP genau macht?
>
> Nein, evtl. braucht man den auch bei einem so breiten Portforward
> nicht.
> Aber zur Sicherheit lasse ich den drin - siehe die Ausführung mit
> dem
> Stress oben.
>

M.W. machen die RFCs für SIP/RTP keine Vorgaben zu den Ports für die
RTP/RTCP-Verbindungen, da die dynamisch per SIP ausgehandelt werden.
Mit "breitem Portforwaring" meinst du sicher die empirisch ermittelten
Portbereiche für die RTP/RTCP Verbindungen, die von Fritzboxen und dem
Telekom-Telefon-Gateway bevorzugt werden.

Der oben genannte RFC beschreibt Mechanismen, wie SIP User Clients
UDP-Ports für die RTP/RTCP-Verbindungen im Router dynamisch öffnen und
die vom Router vergebenen Portnummern per SIP der Gegenseite mitteilen
sollen.

Bei meinem Test funktionierte die Audioverbindung auch ohne
Portforwardings.
Allerdings könnte auch das wieder Zufall gewesen sein, falls der fli4l
zufällig die gleichen Ports als Quellport vergeben hat, die die FB
gewählt hat.

Gruß Erwin

[Matthias Taube]

Am 22.04.2016 um 14:24 schrieb Erwin Lottermann:
> Wenn ich es dabei belasse, habe ich den starken Verdacht, dass der fli4l
> bei mir einem von der Telekom verwalteten Router weichen wird, sobald
> mir die Telekom den ISDN-Anschluss kündigt.

Warum willst Du das? Wenn man sich um nichts kümmern will sind z.B. die
Fritzboxen doch ideal. Einen von der Telekom verwalteten Router würde
ich nicht nehmen.

> SIP macht für mich am meisten Sinn, wenn ich auch per SIP erreichbar
> bin und nicht nur über das Telefon-SIP-Gateway der Telekom.
> Am naheliegendsten erscheint mir dabei, dass jede Email-Adresse
> grundsätzlich auch als SIP-Account eingerichtet wird.

Ich bin ganz froh, dass der Spam- und Phishing-Müll der Mails bisher
noch nicht im gleichen Ausmaß auf die klassische Telefonie übertragen
werden konnte.

> Mein Test-SIP-Account bei iptel.org ist nur per SIP erreichbar.

Bei sipgate.de hat ein Test-Account auch eine normale Rufnummer.

LG
Matthias

[Erwin Lottermann]

Zitat: Matthias Taube schrieb am So, 24 April 2016 10:39
----------------------------------------------------

> Am 22.04.2016 um 14:24 schrieb Erwin Lottermann:
> > Wenn ich es dabei belasse, habe ich den starken Verdacht, dass
> > der fli4l
> > bei mir einem von der Telekom verwalteten Router weichen wird,
> > sobald
> > mir die Telekom den ISDN-Anschluss kündigt.
>
> Warum willst Du das? Wenn man sich um nichts kümmern will sind z.B.
> die
> Fritzboxen doch ideal. Einen von der Telekom verwalteten Router
> würde
> ich nicht nehmen.
>

Ob FB oder Telekom-Router ist dann auch schon egal.
Es geht darum, dass es m.E. wenig Sinn macht, mit dem eigenen
fli4l-Router den DonQuijote zu geben, nachdem man sich auf propietäres
Sip eines bestimmten Anbieters eingelassen hat und telefonieren über
diesen Weg weiterhin wichtig ist.

> > SIP macht für mich am meisten Sinn, wenn ich auch per SIP
> > erreichbar
> > bin und nicht nur über das Telefon-SIP-Gateway der Telekom.
> > Am naheliegendsten erscheint mir dabei, dass jede Email-Adresse
> > grundsätzlich auch als SIP-Account eingerichtet wird.
>
> Ich bin ganz froh, dass der Spam- und Phishing-Müll der Mails
> bisher
> noch nicht im gleichen Ausmaß auf die klassische Telefonie
> übertragen
> werden konnte.
>

Redest du das nur nach oder hast du das schon mal irgendwo erlebt, dass
es einen Zusammenhang zwischen starker Zunahme von Spam-Anrufen und
telefonischer Erreichbarkeit per SIP gab?
Das klingt wie: Ich bin ganz froh, dass mein proprietärer Mail-Account
nur per Fax erreichbar ist, so bekomme ich keine Spam-Mails. (Fax-Spam
ignorieren wir an der Stelle einfach mal.)
Spam-Anrufe haben m.E. weniger damit zu tun, ob ich technisch per ISDN
oder SIP erreichbar bin, sondern mit den Sanktionen, die der Gesetzgeber
Spam-Anrufern androht.

> > Mein Test-SIP-Account bei iptel.org ist nur per SIP erreichbar.
>
> Bei sipgate.de hat ein Test-Account auch eine normale Rufnummer.
>

Danke.
Habe einen Testaccount bei sipgate eingerichtet.
Die verklausulierten Hinweise auf NAT-Router und Erreichbarkeit
bestimmter Ports im Kleingedruckten geben aber auch ersten Anlass, dass
sipgate seine eigenen Vorstellungen von SIP hat.
Ebenso die Fritzbox: Obwohl ich den Account unter "andere Anbieter"
eingerichtet habe, springt die FB nach dem Speichern in eine "Sipgat.de
- Ansicht", so dass man in Erwägung ziehen muss, dass sich die FB
SIP-technisch anders verhält als beim iptel.org-Account.

[Erwin Lottermann]

Am 14.04.2016 um 22:04 schrieb Erwin Lottermann:

iptel.org betreibt eine serverseitige NAT-Traversal-Lösung.
Auch wenn ich den SIP-Ping in der FB ganz deaktiviere bleibt die
UDP-Verbindung zu sip.iptel.org dauerhaft aktiv.

Ganz anders verhält sich dagegen siptel.de
Ohne SIP-Ping der FB ist die UDP-Verbindung zu siptel.de jeweils für 3
Min. aktiv, verschwindet dann für ca. 6 Min. und wird dann wieder neu
aufgebaut.

Die Konfiguration der FB 7170 passt nicht so ganz zu diesem Szenario,
denn die Einstellung des SIP-Ping ist eine globale Einstellung, die für
alle konfigurierten SIP-Accounts einheitlich gilt.

[Erwin Lottermann]

Schaut man sich die Log-Einträge von Thomas/News[1] an, dann sieht es
so aus, als wenn der SIP-Conntrack-Helper das Timeout für
UDP-Verbindungen von 180s auf 3600s erhöht.

>Tue Aug 9 17:45:39 MESZ 2016 udp 17 3572 src=192.168.246.50
dst=62.52.148.134 sport=5060 dport=5060 packets=7 bytes=7839
src=62.52.148.134 dst=78.51.63.105 sport=5060 dport=5060 packets=7
bytes=4808 [ASSURED] mark=0 helper=sip use=1

Kann jemand sagen, ob es Szenarien gibt, bei denen ein so großes
Timeout für UDP-Verbindungen störend sein kann?

[Christoph Schulz]

Hallo!

Am Thu, 18 Aug 2016 12:08:52 +0200 schrieb Erwin Lottermann:

> Schaut man sich die Log-Einträge von Thomas/News[1] an, dann sieht es so
> aus, als wenn der SIP-Conntrack-Helper das Timeout für UDP-Verbindungen
> von 180s auf 3600s erhöht.

So ist es. Aus include/linux/netfilter/nf_conntrack_sip.h:

#define SIP_TIMEOUT 3600

Die Beschreibung des Modul-Parameters lautet "timeout for the master SIP
session". Somit kannst du den SIP-Timeout-Wert als Modul-Parameter
angeben. Zum Testen könntest du über ein selbstgeschriebenes Skript /etc/
rc.d/rc050.sip-timeout o.ä. den folgenden Eintrag an die /etc/
modprobe.conf anhängen:

options nf_conntrack_sip sip_timeout=600

Das würde den Timeout auf 600 Sekunden senken. Das Skript könnte etwa so
aussehen:

#!/bin/sh
echo "options nf_conntrack_sip sip_timeout=600" >> /etc/modprobe.conf

Wenn du der C-Programmiersprache mächtig bist, solltest du dir den
Quelltext der Datei net/netfilter/nf_conntrack_sip.c anschauen. Dort
findest du vermutlich alle Informationen, die du brauchst. Interessant
wären vermutlich:

/* Parse a REGISTER request and create a permanent expectation for
incoming
* signalling connections. The expectation is marked inactive and is
activated
* when receiving a response indicating success from the registrar.
*/
static int process_register_request(struct sk_buff *skb, unsigned int
protoff,
unsigned int dataoff,
const char **dptr, unsigned int
*datalen,
unsigned int cseq)

und

static int process_register_response(struct sk_buff *skb, unsigned int
protoff,
unsigned int dataoff,
const char **dptr, unsigned int
*datalen,
unsigned int cseq, unsigned int code)

> Kann jemand sagen, ob es Szenarien gibt, bei denen ein so großes Timeout
> für UDP-Verbindungen störend sein kann?

Ich wüsste nicht, warum das so sein sollte. Wenn die Internet-Verbindung
neu aufgebaut wird, wird die Conntrack-Tabelle sowieso geleert.

[Erwin Lottermann]

Zitat: Christoph Schulz schrieb am Fr, 19 August 2016 15:40
----------------------------------------------------

> Hallo!
>
> Am Thu, 18 Aug 2016 12:08:52 +0200 schrieb Erwin Lottermann:
>
> > Schaut man sich die Log-Einträge von Thomas/News[1] an, dann
> > sieht es so
> > aus, als wenn der SIP-Conntrack-Helper das Timeout für
> > UDP-Verbindungen
> > von 180s auf 3600s erhöht.
>
> So ist es. Aus include/linux/netfilter/nf_conntrack_sip.h:
>
> #define SIP_TIMEOUT 3600
>
> Die Beschreibung des Modul-Parameters lautet "timeout for the master
> SIP
> session".

D.h. das muss gar keine generelle Vergrößerung des Timeouts für alle
UDP-Verbindungen sein, sondern könnte ausschließlich für
SIP-Verbindungen gelten, so dass sich die Frage nach negativen
Auswirkungen für andere UDP-Verbindungen gar nicht stellt.

> Somit kannst du den SIP-Timeout-Wert als Modul-Parameter
> angeben. Zum Testen könntest du über ein selbstgeschriebenes
> Skript /etc/
> rc.d/rc050.sip-timeout o.ä. den folgenden Eintrag an die /etc/
> modprobe.conf anhängen:
>
> options nf_conntrack_sip sip_timeout=600
>
> Das würde den Timeout auf 600 Sekunden senken. Das Skript könnte
> etwa so
> aussehen:
>
> #!/bin/sh
> echo "options nf_conntrack_sip sip_timeout=600" >>
> /etc/modprobe.conf
>

D.h. man kann das Timeout für die SIP-Verbindung nach Bedarf
einstellen.
z.B. wenn der SIP-Provider ein Reconnect-Intervall von mehr als 1h
vorgibt, würde es wahrscheinlich Sinn machen, den Timeout-Wert noch
größer einzustellen.

Zum Verstehen von C-Quelltext reicht es bei mir nicht.
Für das Verständnis wird man aber auch die SIP-Spezifikationen
verstanden haben müssen.
In denen habe ich ein wenig gelesen und danach machen deine Hinweise
schon Sinn.

Der SIP-Conntrack-Helper soll vermutlich nur die SIP-Verbindungen am
Leben halten (Timeout erhöhen), die bei einer erfolgreichen
SIP-Registrierung entstanden sind. Dazu wird zuerst die ausgehende
Request-Message geparst, um zu sehen, ob es sich um eine
Register-Message handelt und die Call-ID zu bestimmen, damit die
eingehende Message zugeordnet werden kann.
Dann wird die eingehende Antwortmessage des SIP-Servers geparst, um
herauszufinden, ob es eine Register-Response ist und die Registrierung
erfolgreich war.

> > Kann jemand sagen, ob es Szenarien gibt, bei denen ein so
> > großes Timeout
> > für UDP-Verbindungen störend sein kann?
>
> Ich wüsste nicht, warum das so sein sollte. Wenn die
> Internet-Verbindung
> neu aufgebaut wird, wird die Conntrack-Tabelle sowieso geleert.
>

Wie schon oben gesagt: Wenn es nur die SIP-Verbindungen betrifft, dann
ist die Frage wohl hinfällig.

Vielen Dank
Erwin

[Christoph Schulz]

Hallo!

Am Sat, 20 Aug 2016 14:13:44 +0200 schrieb Erwin Lottermann:

> D.h. das muss gar keine generelle Vergrößerung des Timeouts für alle
> UDP-Verbindungen sein, sondern könnte ausschließlich für
> SIP-Verbindungen gelten, so dass sich die Frage nach negativen
> Auswirkungen für andere UDP-Verbindungen gar nicht stellt.

So ist es.

> D.h. man kann das Timeout für die SIP-Verbindung nach Bedarf einstellen.

Jein. Bei fli4l 3.10 konnte man via "MASQ_MODULE_%_OPTION" Optionen
nutzen, bei fli4l 4.0 ist diese Variable "deprecated", und die neue
Vorgehensweise erlaubt keine Optionen. Hier muss ich mir am besten noch
etwas überlegen.

> Der SIP-Conntrack-Helper soll vermutlich nur die SIP-Verbindungen am
> Leben halten (Timeout erhöhen), die bei einer erfolgreichen
> SIP-Registrierung entstanden sind. Dazu wird zuerst die ausgehende
> Request-Message geparst, um zu sehen, ob es sich um eine
> Register-Message handelt und die Call-ID zu bestimmen, damit die
> eingehende Message zugeordnet werden kann.
> Dann wird die eingehende Antwortmessage des SIP-Servers geparst, um
> herauszufinden, ob es eine Register-Response ist und die Registrierung
> erfolgreich war.

Genau.

[Erwin Lottermann]

Hallo,

habe jetzt bei mir den SIP Conntrack-Helper aktiviert.

Allerdings zeigt mir

conntrack -L -p udp --orig-port-src 5060

,dass die von der Fritzbox von Port 5060 ausgehenden
SIP-UDP-Verbindungen immer noch ein Timeout von 180s haben.
Ohne SIP-Ping von der Fritzbox ist auch die aktive Verbindung zu
sipgate.de nach jeweils 180s weg.

Muss man mehr machen als diesen Eintrag in der base.txt (fli4l 3.10.5)?

PF_PREROUTING_CT_N='2'
PF_PREROUTING_CT_1='tmpl:ftp IP_NET_1 HELPER:ftp'
PF_PREROUTING_CT_2='tmpl:sip any dynamic HELPER:sip'

[Christoph Schulz]

Hallo!

Am Mon, 22 Aug 2016 21:13:58 +0200 schrieb Erwin Lottermann:

> Hallo,
>
> habe jetzt bei mir den SIP Conntrack-Helper aktiviert.
>
> Allerdings zeigt mir
>
> conntrack -L -p udp --orig-port-src 5060
>
> ,dass die von der Fritzbox von Port 5060 ausgehenden
> SIP-UDP-Verbindungen immer noch ein Timeout von 180s haben.
> Ohne SIP-Ping von der Fritzbox ist auch die aktive Verbindung zu
> sipgate.de nach jeweils 180s weg.
>
> Muss man mehr machen als diesen Eintrag in der base.txt (fli4l 3.10.5)?

Ist dein Zähler zur iptables-Regel hochgegangen? Was zeigt

iptables -t raw -vnL PREROUTING

denn an? Steht in der HELPER:sip-Zeile vorne etwas anderes als "0"?

> PF_PREROUTING_CT_2='tmpl:sip any dynamic HELPER:sip'

Diese Regel wird vermutlich nicht greifen, denn der Flow geht ja nicht
zur externen Adresse des fli4ls (= "dynamic"), sondern zu deinem SIP-
Registrar. Besser wäre es, über die Quelle zu filtern:

PF_PREROUTING_CT_2='tmpl:sip @fritzbox:5060 any HELPER:sip'

Damit würdest du alle abgehenden Pakete von der FRITZ!Box, Quellport 5060
"erwischen". (Für @fritzbox kannst du natürlich die IP-Adresse einsetzen,
falls du keinen HOST_x-Eintrag für die FRITZ!Box hast.)

[Erwin Lottermann]

fli4l 3.10.5 # iptables -t raw -vnL PREROUTING
Chain PREROUTING (policy ACCEPT 2779K packets, 2358M bytes)
pkts bytes target prot opt in out source
destination
0 0 CT tcp -- * * 192.168.1.0/24
0.0.0.0/0 tcp dpt:21 /* PF_PREROUTING_CT_1='tmpl:ftp IP_NET_1
HELPER:ftp' */ CT helper ftp
0 0 CT tcp -- * * 0.0.0.0/0
79.194.147.122 tcp dpts:5060:5061 /* PF_PREROUTING_CT_2='tmpl:sip
any dynamic HELPER:sip' (PLACEHOLDER:2) */ CT helper sip
1479 727K CT udp -- * * 0.0.0.0/0
79.194.147.122 udp dpts:5060:5061 /* PF_PREROUTING_CT_2='tmpl:sip
any dynamic HELPER:sip' (PLACEHOLDER:2) */ CT helper sip


Du hast wahrscheinlich recht damit, dass man den SIP-Conntrack-Helper
auf die ausgehende SIP-Verbindung ansetzen muss.

'tmpl:sip' sagt nur etwas zum Übertragungsprotokoll und zum Zielport,
also für SIP udp+tcp Port 5060 bis 5061. Richtig?

Mein Ziel wäre es, nicht nur die Fritzbox sondern auch andere
Teilnehmer aus meinen internen Netzen IP_NET_1 und IP_NET_2, die einen
SIP-Client starten, mit dem Conntrack-Helper zu unterstützen.

Das müsste dann vielleicht so aussehen:

PF_PREROUTING_CT_N='3'

PF_PREROUTING_CT_1='tmpl:ftp IP_NET_1 HELPER:ftp'

PF_PREROUTING_CT_2='tmpl:sip IP_NET_1 HELPER:sip'
PF_PREROUTING_CT_3='tmpl:sip IP_NET_2 HELPER:sip'

Scheint auch wie erwartet zu funktionieren:

fli4l 3.10.5 # conntrack -L -p udp --orig-port-src 5060
udp 17 3579 src=192.168.1.41 dst=217.10.79.9 sport=5060 dport=5060
ackets=11 bytes=8332 src=217.10.79.9 dst=79.194.136.118 sport=5060
dport=5060 packets=11 bytes=4577 [ASSURED] mark=0 helper=sip use=1
udp 17 9 src=192.168.1.41 dst=217.10.68.152 sport=5060 dport=10000
ackets=1 bytes=56 src=217.10.68.152 dst=79.194.136.118 sport=10000
dport=5060 packets=1 bytes=116 mark=0 use=1
udp 17 3593 src=192.168.1.41 dst=212.79.111.155 sport=5060
dport=5060 packets=15 bytes=12777 src=212.79.111.155 dst=79.194.136.118
sport=5060 dport=5060 packets=15 bytes=8579 [ASSURED] mark=0 helper=sip
use=1
conntrack v1.4.2 (conntrack-tools): 3 flow entries have been shown.

Man sieht, dass nur das Timeout der beiden SIP-Verbindungen (sipgate.de,
iptel.org) erhöht wurde.
Die ebenfalls von der Fritzbox von Port 5060 ausgehende STUN-Verbindung
an Zielport 10000 hat das Standard-UDP-Timeout behalten.

Habe mir dann übrigens doch einmal den Quelltext von
net/netfilter/nf_conntrack_sip.c angesehen.
Das scheint eine durchdachte Geschichte zu sein, die sich nicht nur um
die SIP-Verbindnngen sondern auch um die über die SIP-Verbindung
ausgehandelten RTP/RTCP-Ports kümmert.

Danke
Erwin

[Erwin Lottermann]

Am 20.08.2016 um 15:08 schrieb Christoph Schulz:
> Am Sat, 20 Aug 2016 14:13:44 +0200 schrieb Erwin Lottermann:
>
>> D.h. man kann das Timeout für die SIP-Verbindung nach Bedarf einstellen.
>
> Jein. Bei fli4l 3.10 konnte man via "MASQ_MODULE_%_OPTION" Optionen
> nutzen, bei fli4l 4.0 ist diese Variable "deprecated", und die neue
> Vorgehensweise erlaubt keine Optionen. Hier muss ich mir am besten noch
> etwas überlegen.
>

Habe gerade im IP-Phone-Forum gelesen, dass Alice/o2 mit dem Expire der
SIP-Registrierung von etwas über 1h offenbar in "guter" Geslleschaft
ist, denn bei 1&1 soll der Wert gar bei 7200s=2h liegen.