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!

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,

[Erwin Lottermann]

Post by Christoph Schulz

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

# 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
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.)

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]

Post by 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]

Post by 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]

Post by Matthias Taube

Post by 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.

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]

Post by 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
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).

Post by Erwin Lottermann
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
----------------------------------------------------

Post by Matthias Taube

Post by 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
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.

Post by Matthias Taube
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.

Post by Matthias Taube
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.

Post by Matthias Taube

Post by Erwin Lottermann
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]

Post by 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.

Post by Erwin Lottermann
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.

Post by Erwin Lottermann
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
----------------------------------------------------

Post by 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.

Post by Erwin Lottermann
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.

Post by Erwin Lottermann
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]

Post by Erwin Lottermann

Post by Christoph Schulz

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

# 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
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.)

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.

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!

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.


Viele Grüße,

[Erwin Lottermann]

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

Post by Christoph Schulz
Hallo!

Post by 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.

#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.

Post by Christoph Schulz
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/
options nf_conntrack_sip sip_timeout=600
Das wÌrde den Timeout auf 600 Sekunden senken. Das Skript könnte
etwa so
#!/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.

Post by Christoph Schulz
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
/* 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)

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.

Post by Christoph Schulz

Post by Erwin Lottermann
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!

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.


Viele Grüße,

[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!

Post by 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"?

Post by Erwin Lottermann
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.)


Viele Grüße,

[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]

Post by Christoph Schulz

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.