OpenWRT-Router hinter Fritzbox 7430

[StevieCG]

Hallo Zusammen,

nachdem ich festgestellt habe, dass mein Provider mir bis auf die internen LAN-Ports der FB schauen kann, habe ich mir ein zweistufiges Firewall-System eingerichtet.
Vorne an der Front die FB 7430. (Aktuelle FW)
Dahinter ein OpenWRT-Router (18.06.4, mit klassischem NAT)
Im LAN ein CommuniGate-Server (CG-Server) an dem sich die VoIP-Cients registrieren. Der wiederum soll die FB, über den OpenWRT-Router, als reinen Switch benutzen.
Ziel ist, sich möglichst wenig mit dem intransparenten AVM-FritzBox-Murks beschäftigen zu müssen. Die FB soll einfach nur meinen Provider "beruhigen" und gut ist.

Was bisher funktioniert:
Intern: VoIP-Registrierung, Anrufsignalisierung (SIP) und Sprachübertragung (RTP)
Intern2Extern: Anrufsignalisierung
Extern2Intern: Anrufsignalisierung
Die Konfiguration zwischen CG-Server und FB funktioniert also.

Was nicht funktioniert:
Intern2Extern: Sprachübertragung (also RTP)
Extern2Intern: Sprachübertragung
Der OpenWRT-Router will also noch nicht so richtig die RTP-Ports durchreichen.

Auf dem OpenWRT-Router habe ich für SIP den UDP-Port 5060 von der FB zum CG-Server freigeschaltet und weitergeleitet. Darum funktioniert auch die Anrufsignalisierung von intern2extern und vice versa.
Für das Durchreichen der RTP-Ports stehen verschiedene Lösung zur Verfügung:

• Dumpf, gefühlt, 10000 RTP-Ports statisch aufmachen
• Einen STUN-Server (auf dem CG-Server???) einrichten
• Auf dem OpenWRT-Router einen Siproxd einrichten
• Auf dem OpenWRT-Router conntrack mit entsprechenden Helpern an den Start bringen

Ich baue so ein Setup jetzt zum ersten mal auf und verfüge daher diesbezüglich über keinerlei Erfahrungswerte.
Ziel sollte schon sein, dass sich die VoIP-Clients am internen CG-Server registrieren und der auch das SIP-Handling macht, weil ich sonst einige Synergieeffekte verliere (Gemeinsames Adressbuch, Anrufbeantworter, doppelte Pflege der Benutzer etc.)
Was wäre wie der charmanteste Weg, damit die Clients auch von / nach anrufen bzw. angerufen werden können?

Vielen Dank im Voraus und Gruß
Stevie

 

[sonyKatze]

mein Provider [kann] mir bis auf die internen LAN-Ports der FB schauen

Was genau meinst Du damit?

Der charmanteste Weg ist, wenn der Haupt-Router das Telefon-Gateway macht. Dann hast Du nicht mit NAT, Firewall, Double-NAT und Zwangstrennung zu kämpfen. Ist Dein SIP-Provider wer anderes als Dein Internet-Provider? Wenn ja, wer ist es?

 

[StevieCG]

Hallo und danke für deine Antwort.

Die FB ist mein Hauptrouter und davor (aus Sicht meines LANs) sitzt mein OpenWrt-Router. ...über den müssen SIP und RTP also sowieso drüber.
Wenn ich die Telefone an der FB registriere, werfe ich jede Menge Synergieeffekte weg, die mir ein CommuniGate-Server bietet.
Für den OpenWrt-Router gibt es ja auch die entsprechenden nf-Helper-Module. Diese bekomme ich zwar geladen, kann sie aber mittels itapbles -A bla bla nicht ansteuern. Das scheint noch ein Syntax-Problem zu sein.

 

[sonyKatze]

mein Provider [kann] mir bis auf die internen LAN-Ports der FB schauen

Was genau meinst Du damit?

 

[StevieCG]

Sorry, das ist hier nicht wirklich das Thema. Ein zweistufiges FW-System macht in vielerlei Hinsicht Sinn.

 

[sonyKatze]

Also, um Deine Frage zu beantworten: Du brauchst weder STUN noch irgendwelche zusätzlichen Packages auf OpenWrt. Punkt. Ende. Aha:

Die Telefonie irgendwo ins Heimnetz packen, macht in vielerlei Hinsicht keinen Sinn – wie wild Probleme.

Aktuell hast Du durch das Port-Forwarding Deinen VoIP/SIP-Gateway komplett ins Internet gestellt. Hört sich jedenfalls so an. Besonders Einsteiger, die nicht selbst einen Mirroring-Port bzw. Paket-Dumps auswerten können, sollten sich das nicht nur zweimal sondern mindestens zehnmal überlegen. Normalerweise bahnt sich ein SIP-User-Agent seinen Weg selbst. Das bedeutet er hält die Verbindung für die Signalisierung offen und wenn ein Anruf rein kommt „puncht“ er mittels RTP-Paketen auf dem ausgehandelten Port in die Firewall ein Loch. Port-Forwarding ist eigentlich der völlig falsche Weg, weil die SIP-Partner dafür (auch für SIP) jeden Port nehmen könnten – es sind Client-Connections.

Bei Dir kann alles Unmögliche kaputt sein. Wir wissen nicht, welchen VoIP/SIP-Anbieter Du nutzt. Wir wissen nicht, ob Du UDP, TCP oder TLS für SIP nutzt. Wir wissen nicht, ob Du IPv4 oder IPv6 nutzt. Vielleicht sind OpenWrt die ankommenden RTP-Pakete bereits zuviel, eine Storm-Protection greift und das Punshen schlägt fehl.

Das alles bekommst Du nur raus, wenn jemand Deine Konfiguration 1:1 nachbaut und alles für Dich auswertet. Oder Du fängst an – mittels Mirroring-Port bzw. Paket-Dumps –, den Netz-Verkehr vor OpenWrt und vor Deinem CommuniGate zu ziehen. Wenn Du nicht weißt wie das geht, einfach fragen. Wenn Du die Daten nicht mit Wireshark nicht selbst auswerten kannst, einfach fragen.

 

[StevieCG]

Mir ist schon seit meinen Asterisk-Zeiten (2008 ff) bewusst, dass dieses Setup tricky ist. Daher habe ich ein solches bisher vermieden. Allerdings will ich mich der Sache nun doch noch mal annehmen.

Du gehst hier von einigen unbestätigten und teils falschen Annahmen aus.

• Die WAN-Seite der FB (des VoIP/-SIP-Gateways) is untouched und nur für meinen Provider sichtbar. ...und das soll ja auch so sein.
• Portforwarding (SIP) findet derzeit source based, testweise, auf meinem OpenWrt-Router (zwischen FB und meinem internen LAN) statt. Da ist also auch nichts "mal eben so" für Traffic aus dem Internet offen. Da müsste dann also erst mal jemand die FB hacken. Das ist nicht völlig ausgeschlossen, aber einen Tod muss man sterben.
• Ich bin seit Linux-Kernel-Version 0.9.x dabei und habe mein Geld jahrelang als Pen-Tester verdient. Also, einem packet dump kann ich mit einem wireshark schon die erforderlichen Informationen entlocken. Weder auf der FB noch auf einem Standard-Home-Consumer-Router (OpenWrt) ist der von dir erwähnte Monitoring-Port vorhanden, aber dafür gibt es natürlich andere Lösungen, um an einen dump zu kommen.
• Bei einem Trunking handeln die UAs die SIP-Session nicht mehr zwingend selber aus. ...bei RTP, klar...weil ist eine P2P-Verbindung zwischen den UAs.

Aber...während ich das hier schreibe, kommt mir noch eine andere Idee...das muss ich die Tage mal ausprobieren.
Insofern: Erst mal Danke für deinen Input!

 

[sonyKatze]

Gerade dann müsstest Du wissen, dass die Angaben nicht ausreichen. Wir können nur raten. Und ein Ansatz ist, zu überprüfen, ob Du überhaupt weißt, was Du da tust. Und selbst wenn Du einen Doktor-Titel in Informatik hast und schon Speaker auf der DEF CON warst, müsstest Du auch wissen, dass man sich verlaufen kann. Daher sind gerade bei Informatik-Themen Nachfragen nichts Ungewöhnliches.

Auf der FRITZ!Box kannst Du den Datenverkehr sowohl vor als auch hinter der Box mitschneiden. Für OpenWrt existieren einige Lösungen, aber das Schnellste dürfte ein Managed-Switch (mit Port-Mirroring) zwischen OpenWrt und CommuniGate sein. Dann kannst Du live mitschneiden. In Wireshark filterst Du beispielsweise auf „sip.CSeq.method == INVITE“. In der SDP/Media-Line siehst Du den ausgehandelten RTP-Port. Auf diesen Port filterst Du dann UDP, weil oftmals der RTP-Strom nicht als solcher gefunden wird.

Bei der FRITZ!Box solltest Du aufpassen, dass alle Rufnummern gelöscht sind… und wenn Du Deinem Internet-Anbieter so wenig vertraust, bedeutet das, dass er jederzeit wieder Rufnummern hinterlegen und damit Port 5060/udp blockieren kann. Ergo, musst Du den SIP-Port im CommuniGate von 5060 auf was anderes legen (oder statt UDP doch TCP bzw. TLS verwenden).

Portforwarding (SIP) findet derzeit source based, testweise, auf meinem OpenWrt-Router (zwischen FB und meinem internen LAN) statt.

Muss ich nicht verstehen … oder?

mir [kam] noch eine andere Idee

Wenn Du die uns verrätst, könnte man vielleicht abschätzen, ob es was bringt.

 

[StevieCG]

Bevor wir weiter machen: Bekommst du es hin, deine persönlichen Anfeindungen zu unterlassen? Nicht jeder der hier eine Frage stellt, ist automatisch ein dummer Junge.

Mit Verweis auf meinen OP, hier noch einmal ein paar Infos...damit die Hilfe auch zielführend ist:

• Netz-Konstrukt wie folgt: Internet =>> FB =>> OpenWrt-Router =>> LAN (im LAN steht auch der CG-Server)
• OpenWrt-Router muss im Spiel bleiben, weil darüber u.a. weitere Netze geroutet werden.
• Wenn auch derzeit per Port-Forwarding auf dem OpenWrt-Router, reicht die FB UDP/5060 (Anrufsignalisierung) an den CG-Server weiter. Der CG-Server reicht das auch brav an die UAs weiter.
• Kommunikation per RTP will derzeit nicht funktionieren (hier muss ich tatsächlich noch mal mit dem Tracer 'ran). Eigentlich möchte ich jedoch nichts statisches, sondern suche eher nach einer smarten / dynamischen Lösung (wenn das möglich ist).
• Neue Info: Provider ist NetCologne und der steht im Ruf, die REGISTERs darauf zu überprüfen, ob sie von der dem Anschluss zugeordneten FB stammen. Ist dies nicht der Fall, wird das geblockt. Nach meinem Kenntnisstand muss die FB also den REGTISTER beim Provider durchführen und den gesamten VoIP-Traffic über den OpenWrt-Router an den CG-Server weiterleiten.
• Neue Info: LAN-Protokoll, bis einschließlich LAN-Ports der FB, ist IPv4.

 

[sonyKatze]

OpenWrt-Router, reicht die FRITZ!Box UDP/5060 an den CommuniGate weiter […] NetCologne [soll die] REGISTERs darauf […] überprüfen, ob sie von der dem Anschluss zugeordneten FB stammen

Ahh. Du nutzt die FRITZ!Box als SIP-Registrar. Puh. Dann mein Tipp vor und nach dem OpenWrt den Datenverkehr mitschneiden. Normalerweise „punched“ ein SIP-User-Agent (hier CommuniGate) sich die Löcher für RTP ins NAT selbst, indem er selbst RTP-Pakete auf diesem Pfad schickt (Transport gleich, Quell- und Ziel-Ports gleich). Die RTP-Pakete von Außen (hier FRITZ!Box) kommen dann durch. Ganz ohne Exposed-Host oder Port-Forwarding. Das klappt bei Dir nicht. Meine Vermutungen: Entweder

a) Dein CommuniGate punched nicht – Sache der Konfiguration? Oder​

b) im OpenWrt greift eine UDP-Storm-Protection bevor das Loch im NAT aufgeht. Oder​

c) das NAT im OpenWrt lässt sich so nicht öffnen? Oder​

d) die FRITZ!Box routet die RTP-Pakete falsch (weil in SIP/SDP eine unbekannte IP-Adresse steht).​

Eigentlich müsste das alles automatisch funktionieren und Du dürftest dieses Problem überhaupt nicht haben. Es ist aber wie es ist. Warum, dazu müsste man Deine Konfiguration nachbauen und analysieren. Daher mein Tipp mit dem Tracen. Wenn Du mit dem Auswerten der Traces Hilfe brauchst, einfach sagen.

Selbst Vermutung D ist normalerweise kein Problem: Wenn die IP-Adresse unbekannt ist, dann sendet man an die IP-Adresse zurück, von der das SIP kam. Kann sein, dass der SIP-Registrar in der FRITZ!Box das nicht macht. Mal sehen, ob ich heute Zeit habe, dass zu kontrollieren … in dem Fall müsstest Du die IP-Adressen in den SIP-Nachrichten ausgehend vom CommuniGate auf die IP-Adresse des WAN-Ports des OpenWrt umbiegen. So wie ich Dich verstehe, ist der CommuniGate auf dem SIP-Layer ebenfalls ein SIP-Registrar für die angeschlossenen SIP-Telefonen. Folglich spielt der CommuniGate (genau wie die FRITZ!Box) nicht SIP-Proxy (einfache Durchleitung der SIP-Nachrichten) sondern spielt Back-2-Back-User-Agent (B2BUA; ändert die Quell- und Ziel-IPs). In dem Fall – wenn Vermutung D zutrifft – müssten wir herausbekommen, welche IP-Adresse der SIP-Registrar in der FRITZ!Box aus der SIP-Nachricht für sein Routing nimmt. Dann müssen wir schauen, wie wir diese IP-Adresse ändern (im CommuniGate oder im OpenWrt).

Du merkst, es ist nicht so einfach, weil wir die Ursache nicht kennen.

Bekommst du es hin, deine persönlichen Anfeindungen zu unterlassen? Nicht jeder der hier eine Frage stellt, ist automatisch ein dummer Junge.

Wenn Du es nicht schaffst die Sache von der Person zu trennen, dann haben wir ein Problem. Du kannst das Problem selbst nicht lösen. Du lieferst keine Traces. Du lieferst nicht genug Informationen. Das hat nichts mit Dummheit zu tun. Aber ich muss jetzt schauen, wo ich Dich abhole und ob ich Dich bzw. Deine Situation voll verstehe. Ich habe kein Problem damit, wenn Du schlauer bist als ich. Aber wenn ich Dir helfen soll, dann muss ich halt nachfragen. Und sich verlaufen, hat auch nichts mit Dummheit zu tun.

 

[StevieCG]

• Mein OP fragte nach einem grds. Mechanismus, der möglichst simpel / smart funktioniert. Da war also von tracen noch keine Rede.
• Als User Agent (UA) werden, der reinen Lehre nach, die Endgeräte bezeichnet. Der CG-Server ist in diesem Sinne kein UA. ...aber das ist jetzt eher akademisch.
• Auf der FB ist ein Account eingerichtet, mit dem sich der CG-Server dort anmeldet. =>> SIP-Kommunikation funktioniert (von / zu extern komplett, intern sowieso, weil da die FB 'raus ist) in beide Richtungen.
• Ebenfalls ist auf der FB derzeit eine eigene Ruf-Nr. eingerichtet, damit mein Provider "glücklich" ist. Einfacher wäre tatsächlich ein Setup, in dem der CG-Server die FB nur als Router nutzt und sich selbst direkt beim Provider registriert.
• Die Endgeräte registrieren sich ausschließlich am CG-Server. =>> Interne Kommunikation funktioniert vollständig. Externe Kommunikation funktioniert bis einschließlich RING (SIP) auf dem Endgerät.
• Wenn ein Call (von / zu extern) zustande kommt und die Endgeräte untereinder die RTP-Verbindung aufbauen, sollte (man beachte den Konjunktiv...hier bin ich mir derzeit nicht absolut sicher) das für die FB nur noch RTP-Traffic sein.
• Ja, ich stimme dir zu: Jetzt ist der Zeitpunkt gekommen, sich noch einmal die Traces anzusehen, um Konfigurationsfehler auszuschließen. ...das kann jetzt aber 1 bis 2 Tage dauern, bis ich ein bisschen Zeit dafür finde. ...mal sehen.

Wenn ich es nicht schaffen würde, die Sache vom Problem zu trennen, hätte ich das Thema nicht bei dir angesprochen! Dein Ton ist doch in deinem letzten Post OK!! ...von daher: Alles gut.

 

[sonyKatze]

Der grundlegende Mechanismus ist der, dass Dein Setup eigentlich so einfach schon bereits funktionieren müsste. Wenn es nicht klappt – warum auch immer –, ist eine charmante Lösung, die Telefonie in dem Gerät zu machen, wo auch die Firewall sitzt. Ganz vorne in der FRITZ!Box willst Du das nicht machen. Bei Deinem Setup hättest Du auch noch die Möglichkeit einen Digium Asterisk bzw. FreeSWITCH im OpenWrt zu installieren. Dann hast Du drei B2BUAs in Reihe und könnte zu Medien-Verschleppungen und daher zu Echos führen. Wenn Du OpenWrt = B2BUA machst, hättest Du auch die Möglichkeit auf den CommuniGate ganz zu verzichten und alle Telefone im OpenWrt zu registrieren.

Wenn Du sowieso eine Separierung anstrebst, dann könntest Du auch statt zur Firewall zu einem Medienbruch greifen. Also den CommuniGate über einen der analogen Anschlüsse an der FRITZ!Box anbinden.

Als User Agent (UA) werden, der reinen Lehre nach, die Endgeräte bezeichnet. Der CG-Server ist in diesem Sinne kein UA.

Dann habe ich Deinen Aufbau noch immer nicht verstanden. Ich dachte in Deinem Aufbau wäre die FRITZ!Box ein B2BUA und der CommuniGate ebenso. Im Fall von B2BUAs „ändern“ sowohl FRITZ!Box als auch CommuniGate die SIP-Nachrichten. Ein Anruf kommt rein, die FRITZ!Box leitet das an seine Nebenstellen weiter (DECT, Analog und SIP). Der CommuniGate erhält eine SIP-Nachricht von der FRITZ!Box. Der CommuniGate leitet das an seine Nebenstellen weiter. In beiden Fällen werden komplett neue SIP-Nachrichten = neue SIP-Sessions erzeugt ohne irgendwie auf die ursprüngliche SIP-Session zu verweisen. Die Verknüpfung beider Call-Legs passiert intern im B2BUA. Die FRITZ!Box kann auch Media-Plane-B2BUA – dabei werden die RTP-Pakete umgesetzt, wenn die Audio-Codecs auf den Call-Legs sich unterscheiden. Mhm. Ich kenne jetzt Deinen CommuniGate gar nicht – könnte jetzt auch sein, dass der kein Media-Plane-B2BUA spielen kann. Aber wann sollte das ein Problem sein … G.722?

Also nochmal, ich verstehe das so, dass die FRITZ!Box und die CommuniGate bei Dir jeweils ein B2BUA sind. Das bedeutet aber auch, dass Du die Maximale-Anzahl-Gespräche beachten musst. Eine FRITZ!Box kann so nur zwei Telefonate gleichzeitig. Reicht Dir das überhaupt?

 

[StevieCG]

Hi, Hi!
Danke für dein Engagement!!!
Hier liegen jetzt ein paar neue Infos und Fragen auf dem Tisch, die ich ohne einen Trace nicht beantworten kann. Die FB könnte ich, zeitlich versetzt (also mit dem bekannten Verfahren), tracen. Auf meinem OpenWrt-Router sind alle LAN-Ports mit diversen VLANs belegt. Da ist nun kein Port für Mirroring (=>> Monitoring) mehr frei.
Da ich hier aktuell keine HW mit Port-Mirroring verfügbar habe, muss ich mir da erst etwas besorgen.
Das kann nun ein paar Tage dauern. Darf ich auf das Thema zurück kommen, wenn ich aussagefähig bin?

Zwei Telefonate gleichzeitig wären ausreichend.

 

[stoney]

Eine zweite, ausrangierte F!B hast Du nicht zur Hand?

 

[sonyKatze]

Jederzeit. Ich sehe wenn sich der Thread aktualisiert. Oben unter dem Link „Managed-Switch“ finden sich einige günstige Switches, die man auch bei Media-Markt bzw. Saturn direkt im Laden findet. Aber wie stoney schon schrieb, eine weitere FRITZ!Box tut es auch.

Selbst Vermutung D ist normalerweise kein Problem: Wenn die IP-Adresse unbekannt ist, dann sendet man an die IP-Adresse zurück, von der das SIP kam. Kann sein, dass der SIP-Registrar in der FRITZ!Box das nicht macht.

Ich habe mal Deine Konstellation so gut es ging nachgebaut:

• Sipgate Basic (IPv6)
• FRITZ!Box 7590 (07.12; Haupt-Router, also NAT)
• OpenWrt 18.06 genauer Turris MOX (4.0.5; Router, also NAT)
• FRITZ!Box 7412 (06.86; IP-Client-Modus)
• FRITZ!Fon C5

Die FRITZ!Box 7412 ist als IP-Telefon in der FRITZ!Box 7590 eingebucht. Vermutung D konnte ich so gar nicht testen, weil die FRITZ!Box 7412 die IP-Adresse vor dem OpenWrt selbst herausbekommen hat. Ich musste nichts, aber auch gar nichts besonderes einstellen. Auch habe ich auf das Port-Forwarding für 5060 verzichtet. Allerdings musste ich in „FRITZ!Box 7412 → Telefonie → Eigene Rufnummern → (Reiter) Anschlusseinstellungen → Telefonieverbindung: Einstellungen ändern → Portweiterleitung des Internet-Routers für Telefonie aktiv halten: 1 Minute“ wählen, weil OpenWrt bereits nach 60 Sekunden UDP-Ports schließt. Alternativ setzt Du in OpenWrt

net.netfilter.nf_conntrack_udp_timeout = 300
net.netfilter.nf_conntrack_udp_timeout_stream = 300

in der Datei /etc/sysctl.conf, weil 300 Sekunden der Wert von Expires im SIP-REGISTER einer FRITZ!Box ist. Folglich halten so die re-REGISTER Deines CommuniGate die NAT aufrecht. Auch musste ich beide Werte ändern, einen allein ändern reichte nicht, warum auch immer. Soviel zur Signalisierung (SIP).

Warum Sprache = Medien (RTP) bei Dir nicht geht … vielleicht komme ich morgen dazu mal selbst ein CGatePro aufzusetzen.

 

[StevieCG]

@stoney Danke für den Tip. Aber eigentlich habe ich meine FB bisher nur als zwangsweise aufdoktrorieten Zwangsrouter betrachtet und war froh dieses Ding nach der Grundeinrichtung nicht wieder anfassen zu müssen. Ergo: Nein, ich habe keine zweite FB hier herumliegen.

@sonyKatze Das Setup passt hinsichtlich Netzkonstrukt, allerdings wirst du mit der FB 7412 den CG-Server tatsächlich nicht simulieren können. Wenn du dir den CG-Server aufbauen willst; nur zu...das Ding ist nicht schlecht. Macht allerdings nur Sinn, wenn man sowieso einen HomeServer betreiben will.

Das Netzwerkschnüffelgerät wird wohl zum WE bei mir sein. Sorry für die Spielverzögerung. :-(

 

[sonyKatze]

So, CommuniGate läuft. Übrigens: Du brauchst kein Switch mit Port-Mirroring. Weil CommuniGate nichts anderes als Software für ein Host-System ist, kannst Du Wireshark direkt auf dem Host-System mitlaufen lassen. Und den Daten-Verkehr zwischen FRITZ!Box und OpenWrt schneidest Du auf der FRITZ!Box 7430 mit.

Problem 1
Obige Vermutung D trifft zu; die FRITZ!Box sendet total dumm direkt an die Contact-IP (SIP) bzw. die Media-IP (SDP) und nimmt nicht die Quell-IP aus RPort bzw. abgleitet aus UDP. Man kann jetzt lange streiten, ob das ein Feature-Request wäre oder ein Software-Bug ist. Im Jahr 2020, nein, selbst für das Jahr, in dem AVM seinen SIP-Registrar programmierte, halte ich das für einen Software-Bug. Egal. Das kannst Du im CommuniGate fixen: WAN IPv4 Address (← LAN-IPs ← Network ← Settings ← Web-Oberfläche Port 9010 ← CommuniGate). Dort gibst Du WAN-IP des OpenWrt ein. Dann klappt die Signalsierung (SIP) in beide Richtungen auch ohne Port-Forwarding.

Problem 2
Theoretisch, denn der CommuniGate will einfach nicht alle 60 Sekunden ein SIP-REGISTER machen oder wenigstens ein Keep-Alive schicken. Obwohl man 60 Sekunden für „Register Every“ (← RSIP ← Real-Time ← postmaster ← Objects ← Deine Domain ← Domains ← Users) eingeben kann, überschreibt CommuniGate das mit der Antwort von AVM = 300 Sekunden. Das ist ein Software-Bug im CommuniGate. Folglich musst Du, um das Port-Forwarding für 5060/udp zu vermeiden, OpenWrt anpassen (siehe oben Post#15). Problem 2b: Für SIP anstatt auf UDP zu TCP wechseln, ist auch nicht, denn ich habe keine Ahnung wie ich das einstellen soll. Problem 2c: Für SIP anstatt auf UDP zu TLS wechseln, geht zwar, aber FRITZ!OS 07.12 kann das noch nicht.

Problem 3
Dass der CommuniGate das NAT für RTP punched, will mir nicht gelingen. Entsprechend lässt die Firewall des OpenWrt die Sprache von AVM zum CommuniGate nicht durch. Workaround: In OpenWrt (A) CommuniGate als Exposed-Host deklarieren bzw. (B) Port-Forwardings ab 5000/udp einrichten.

Fazit
Am Ende der Analyse sind wir so weit wie am Anfang. Weil Du drei verbuggte Implementierungen miteinander in Einklang bringen willst, geht es schlicht nicht „charmant“. Die Lösung wäre entweder (A) CommuniGate in die Firewall zu legen – OpenWrt anpassen –, oder (B) den CommuniGate zur Firewall – zum Edge-Router – machen. Vielleicht kommt hier noch jemand vorbei, der eine Idee hat, wie OpenWrt die RTP-Ports „automatisch“ aufmachen kann. Ansonsten mein Tipp: Stell die Frage in einem Diskussionsforum mit OpenWrt als Schwerpunkt, aber bitte verlinke den Thread dann hier.

 

[StevieCG]

Hallo sonyKatze,

das sind ja insgesamt gute Nachrichten. Ich komme wohl erst am WE wieder dazu mich mit dem Thema zu beschäftigen. :-(
Exposed Host meint dann: Alle Ports des CG-Servers für die FB auf dem OpenWrt-Router freischalten?!

Problem 2 klingt nach einem Bug. Nach deren Doku sollte sich das Register-Intervall manuell konfigurieren lassen.
Mit derzeit aktiviertem Portforwarding auf dem OpenWrt-Router (5060 von FB auf 5060 CG-Server) funktioniert die Signalisierung in beide Richtungen ebenfalls. Damit könnte man ja noch leben.

Bis hierhin noch mal ein Danke für dein Engagement. *BothThumbsUp*

 

[sonyKatze]

Ich habe meinen Post #17 und #15 nochmal überarbeitet. Also 5060/udp geht automatisch, wenn Du OpenWrt anpasst. Selbst getestet. Ansonsten Port-Forwarding. Und, ja, das ist ein Software-Bug im CommuniGate.

Exposed Host meint dann: Alle Ports des CG-Servers für die FB auf dem OpenWrt-Router freischalten.

Ja, das wolltest Du vermeiden, siehe Post #1. Die Alternative wäre Port-Forwarding ab Port 5000/udp. Das scheinen die RTP-Ports des CommuniGate zu sein. Wo auch immer man das einstellt. Aber auch das wolltest Du ja eigentlich vermeiden. Der nächste Schritt wäre, OpenWrt aufzubohren, dass es den SIP/RTP-Verkehr analysiert und so die RTP-Ports aufmacht. Auch das hattest Du schon angesprochen, also SIP-Proxy bzw. -B2BUA auf OpenWrt installieren. Aus Deiner Liste wäre nur der Punkt mit STUN die falsche Richtung gewesen – das ist mit der Lösung zu Problem 1 gefixt.

Übrigens: Wenn FRITZ!Box und CommuniGate im selben Sub-Netz sind, geht alles einfach so. Du tust Dir mit dem weiteren Sub-Netz einfach keinen Gefallen. Übrigens, übrigens: Leider lohnt es sich nicht, mittels IPv6 den CommuniGate direkt bei NetCologne anzumelden. Die SIP-Infrastrukturen unserer deutschen Internet-Anbieter sind dermaßen fragil, dass ich keine (von denen) ungetestete SIP-Implementierung – wie einen Communigate Pro von Stalker Software – direkt verbinden würde.

 

[StevieCG]

Wie schon gesagt, würde kann ich den CG-Server auch gar nicht bei Netcologne registern, da die das tracen und alles was nicht FB ist, einfach 'rausschmeißen.
OpenWrt aufbohren, um den SIP/RTP-Verkehr zu analysieren, war das erklärte Ziel welches ich mit den nf-conntrack-Modulen ansatzweise verfolgt habe.
EDIT: Zwischenzeitlich habe ich herausgefunden, dass bestimmte conntrack-Module in OpenWrt aus Sicherheitsgründen (und weil sie wohl eher Schaden als wirkliche Lösungen verursachen) disabled sind. Anyway...wenn sie nicht richtig funktionieren, fällt diese Lösung also schon mal flach.