[fli4l] st?==?utf-8?Q?atisches Forward vs. dynam?==?utf-8?Q?ischer NAT-Eintrag

[Erwin Lottermann]

Danke für die gründliche Erklärung.

Ich halte für mich fest, dass ein statisch konfiguriertes Forward
(Conntrack) vor einem dynamisch entstandenen NAT-Eintrag (DST_NAT)
greift.

Für das konstruierte Beispiel heißt das, dass man mit dem SIP-Client
auf dem PC testen kann soviel man will, man wird sich nicht einmal
erfolgreich beim SIP-Server registrieren können, weil alle
Antwortpakete an die Fritzbox geschickt werden.

Allerdings erzeugt der SIP-Client bei den Registrierungsversuchen einen
dynamischen NAT-Eintrag. Falls vorher der NAT-Eintrag der Fritzbox für
5060 wegen Timeout abgelaufen war, bekommt der SIP-Client den externen
Quellport 5060. Macht nun, während der NAT-Eintrag des SIP-Clients noch
aktiv ist, die Fritzbox eine Neuregistrierung dann bekommt sie einen
anderen externen Quellport (angenommen 5061). Der SIP-Provider merkt
sich also bis zur nächsten Neuregistrierung, dass die Fritzbox unter
ext.IP:5061 zu erreichen ist. Nachdem dann das Timeout des NAT-Eintrags
der Fritzbox abgelaufen ist, ist sie für den Provider bis zur nächsten
Neuregistrierung nach vielleicht 1h auch nicht mehr erreichbar.

Langsam wird mir immer klarer, warum viele SIP/RTP-Provider offiziell
keine SIP-Clients hinter NAT-Routern unterstützen und falls doch,
dringend vor statisch konfigurierten Forwards für 5060 warnen. Die
Fehlermöglichkeiten sind so vielfältig und von kaum nachvollziehbarem
temporärem Charakter, dass man das kaum supporten kann.

Zum statischen Forward für 5060 für Fritzboxen:
Man wird nur in Ausnahmefällen sicherstellen können, dass garantiert
nie ein zweiter SIP-Client im LAN auftaucht. Es macht also vielleicht
Sinn, ein wenig Mühe darauf zu verschwenden, dass es auch ohne
statisches Forward für 5060 auf einen einzigen internen Client
funktioniert. D.h., dass dafür gesorgt werden muss, dass die
NAT-Einträge, die die SIP-Clients bei der Registrierung der
SIP-Accounts erzeugen, bis zur nächsten Neuregistrierung nicht in den
Timeout laufen. Das kann einfach sein, weil sich der SIP-Provider darum
kümmert, das kann aber auch kompliziert oder unmöglich sein, wenn sich
der SIP-Client darum kümmern muss, man aber nur eingeschränkte
Kontrolle über seine Funktionen hat.