2 FBF hinter einem (nicht FBF) Router

[rollo]

Das klappt aber z.B. dann nicht, wenn ein SIP-Server des Providers der Meinung ist, das er SIP-Pakete von einer anderen IP-Adresse aus an die Box (zurück)schicken muss, als jene IP-Adresse, zu der die Box vorher ihrerseits ausgehende SIP-Pakete versandt hatte. Diese eingehenden Pakete kommen dann nämlich nicht bei der Box hinter dem NAT-Router an, ...

Sehr gute Anmerkung! Genau deshalb ziehe ich ein manuelles Portforwarding vor. Das hilft auch, die Box per DynDNS und SIP-URI direkt zu erreichen.

jo

 

[RudatNet]

Ich würde mal vorschlagen, den Titel deines Threads zu ändern!

"2 FBF hinter einem Router ..." o.ä wäre hier sicher der sinnvollere Titel!

"2 FritzBoxen in einem Netz ..." haben hier sehr viele Leute.
... allerdings meistens nicht noch zusätzlich hinter einem weiteren Router!

 

[casellini]

Ich würde mal vorschlagen, den Titel deines Threads zu ändern!

Mache ich gerne. Aber wie?

 

[RudatNet]

Du mußt deinen ersten Beitrag im Thread "ändern"!

 

[otaku42]

quatsch.

Offensichtlich ist es mit der gegebenen Erklärung nicht leicht, die Hintergründe zu verstehen, die zur eigentlichen Frage führen. Deswegen aber das Vorhaben als solches kurzerhand als Quatsch abzukanzeln ist ziemlich daneben, findest Du nicht? Überhaupt frage ich mich, warum die meisten Reaktionen hier im Thread keine Antwort auf die eigentliche Frage geben, sondern sich stattdessen primär damit beschäftigen, Sinn oder Unsinn der Fragestellung zu ergründen.

Ich kenne in diesem Fall die Hintergründe, da ich als Netzwerkadministrator für den ISP arbeite, bei dem casellini seinen Internetzugang hat, und ausserdem an der Entwicklung der Routerfirmware beteiligt bin. Daher kann ich bestätigen, dass das angerissene Problem nicht hausgemacht ist, sondern real existiert.

Das Problem wird, wenn überhaupt, nur einen sehr kleinen Teil der FBF-User betriffen. Für die ursprüngliche Fragestellung spielt das eigentlich keine Rolle, aber ich versuche trotzem mal, die Hintergründe zu erklären:

Beim fraglichen Internetzugang handelt es sich um eine Standleitung via Richtfunk. Die Empfangsanlage ist gleichzeitig der Zugangsrouter und arbeitet auf Linux-Basis (mit iptables für Firewall, NAT, Portforwarding und Co). In der Regel hat der Router zwei Netzwerk-Interfaces, eines für die Richtfunkanbindung (das "äussere Interface") und ein Ethernet-Interface für den Anschluss an das Netzwerk des Kunden (das "innere Interface").

Bei den meisten Kunden, so auch bei casellini, ist nur dem äusseren Interface eine öffentliche IP-Adresse zugewiesen, auf dem inneren Interface hingegen wird ein privater IP-Adresskreis nach RFC 1918 verwendet - es kommt also NAT zum Einsatz. Es gibt keinen NAT-Helper für SIP und (noch) keinen SIP-/RTP-Proxy auf dem Router.

Per default sind keine restriktiven Firewall-Regeln aktiviert, was auch auf den Anschluss von casellini zutrifft. Sprich: Verbindungen, die aus dem Kundennetz heraus aufgebaut werden, können die Firewall problemlos passieren. Verbindungen, die aus dem Internet heraus zum Kundenanschluss hin aufgebaut werden, scheitern hingegen naturgemäß am NAT, sofern kein Portforwarding eingerichtet ist. Per default gibt es kein Portforwarding, es sei denn, der Kunde informiert uns, dass er ein SIP-Endgerät im Einsatz hat, für dessen Ports dann explizit Weiterleitungen eingerichtet werden (dazu gleich mehr).

Soweit zu den "Vorbedingungen". Hier kommt also kein DSL-Zugang zum Einsatz, somit agiert die FBF nicht selbst als Router. Vielmehr verwendet sie einfach die vorhandene Internetverbindung mit, so wie das auch die "normalen" Arbeitsplatz-PCs oder andere Hosts im Kundennetz machen. Insofern ist das vermutlich nicht das übliche Szenario, in dem eine FBF sonst genutzt wird.

Die Erfahrung hat gezeigt, dass auch für den Betrieb einer einzelnen FBF an einem solchen Anschluss ein Portforwarding nötig ist. Lässt man es weg, wird durch die Aktivität der FBF zwar anfangs eine implizite Zuordnung im Router geschaffen, die aber früher oder später dort wieder rausfällt. Danach ist ausgehende Telefonie zwar in der Regel weiterhin möglich. Bei eingehenden Gesprächen kommt aber häufig der RTP-Stream vom Mediagateway des Providers zum SIP-Endgerät des Kunden nicht zustande, so dass der Kunde zwar beim Anrufer zu hören ist, aber der Anrufer nicht beim Kunden. Mit einem explizit eingerichteten Portforwarding für den SIP- und die RTP-Ports lässt sich das vermeiden, und das funktioniert in der Praxis auch einwandfrei.

Ein Problem entsteht allerdings, wenn man eine zweite FBF am gleichen Anschluss in Betrieb nehmen möchte.
Beispiel: FBF1 sendet zur Registrierung ein SIP REGISTER an den SIP-Server, Quell- und Zielport jeweils 5060/udp. Die Antwort des Servers kommt ebenfalls mit Quell- und Zielport 5060/udp. So weit, so gut. Kurz darauf will FBF2 sich registrieren und sendet ebenfalls ein SIP REGISTER an den SIP-Server, auch wieder mit Quell- und Zielport 5060/udp. Auch hier kommt die Antwort wieder mit Quell- und Zielport 5060/udp zurück. Der Router wird die Antwort nun aber an FBF1 weiterleiten, nicht an FBF2 - zumindest, wenn FBF2 sich am gleichen SIP-Server registriert wie FBF1. Falls die Registrierung an unterschiedlichen SIP-Servern erfolgt, könnte es unter Umständen funktionieren, aber das hängt wohl stark vom jeweiligen Router und dessen "Intelligenz" bzw. Konfigurierbarkeit bei den Themen NAT und Portforwarding ab. Bei unseren Routern klappt das jedenfalls in der Regel nicht.

Nun könnte man "port translation" als mögliche Lösung in den Ring werfen. Dabei würde der Router den Quellport der Pakete, die die FBFs an den SIP-Server schicken, gezielt umschreiben, meinetwegen für SIP-Pakete von FBF1 von 5060/udp auf 5070/udp und für SIP-Pakete von FBF2 von 5060/udp auf 5080/udp. Die Antworten des SIP-Servers gehen dann jeweils an die "umgeschriebenen" Ports zurück, und der Router weiss dann, wer der eigentliche Empfänger sein soll.
Bei SIP (und SDP) tauchen Portangaben aber nicht nur im Header der UDP-Pakete auf, sondern teilweise auch im "Inneren" des Paketes. Der Router weiss davon aber nichts, solange kein NAT-Helper für die entsprechenden Protokolle installiert ist, und so greift die "port translation" eben nicht vollständig. Ein NAT-Helper für SIP steht wie gesagt leider nicht zur Verfügung.

Einen SIP-/RTP-Proxy gibt es auch noch nicht (siehe oben), und STUN ist auch keine brauchbare Lösung (bzw. wäre eine, bringt aber neue Probleme mit sich - das würde hier allerdings zu sehr abschweifen). Somit bleibt als einziger relativ problemlos gangbarer Ausweg, eine der beiden FBFs auf andere Ports zu setzen. Und das ist genau das, was casellini hier machen möchte - und zwar so, dass die Anpassung des Portbereiches auch nach einem Neustart beibehalten wird.

cu, otaku

 

[otaku42]

Gehen nicht schon mit einer einzige Fritz!Box 4 Gespräche?

VoIP-seitig geht das sicherlich, die Limitierung liegt in diesem Fall aber beim internen ISDN-Anschluss. Pro S0-Bus gibt es einen D-Kanal (für die Signalisierung) und zwei B-Kanäle (für die Sprache), so dass über einen S0-Bus maximal zwei Gespräche gleichzeitig geführt werden können. Da die FBF nur einen S0-Bus hat, können von der Telefonanlage auch nur maximal zwei Gespräche zur FBF "transportiert" werden.

 

[casellini]

Zur Info:

ich habe das Problem durch eintragen von:

voipd -s
voipd -P 5070

in der debug.cfg gelöst.

Danke an Joe_57 für die Hilfe und an otaku42 für meine Ehrenrettung. Scheint doch kein Quatsch und selbstgemachtes Problem zu sein.

Grüße

Norbert

 

[bodega]

Symmetrische NAT. Das ist echt übel
Heisst also die beiden FBs haben die öffentliche IP mit Port 5060. Da macht das Ändern der Ports auf jedenfall Sinn, wenn kein NAT-Helper vorhanden ist.