Telefonanlage funktioniert nicht unter Omada ER7206

[Rene0210]

Hallo zusammen
ich habe ein Problem, ich habe ein neues Omada Netzwerk eingerichtet und es geht alles Problemlos bis auf die Telefonanlage diese ist eine Octupus FX 3 von der Telekom und hat die IP-Adresse 192.168.230.200 diese habe ich im ER7206 (192.18.230.10) unter NAT eingerichtet und die DMZ aktiviert unter ALG ist SIP ALG deaktiviert, die Telefone Klingeln aber mal hört man den jenigen nicht der rein telefoniert und mal den der raus telefoniert, ich weiß leider nicht weiter.

 

[AllesNormal]

Anscheinend versuchst Du mehrere Regeln in einer Regel unterzubringen.
Die Telefonanlage routet die Telefondaten, dabei spricht es immer mit den Telefonen und dem externen Anrufer.

Also LAN zwischen den Telefonen und der Telefonanlage und WAN zwischen Telefonanlage und Aussenwelt.
Wenn die Telefonie von den Endgeräten über SIP läuft gibt es ja die UDP und RTP Protokolle die genutzt werden. Werden diese mit geforwarded ? Wird es unterstützt ?

 

[Raijin]

Die NAT-Regel sieht für mich komisch aus.

Schnittstelle WAN und Quell-IP=lokales Subnetz ergibt irgendwie wenig Sinn.


Eine Portweiterleitung besteht aus 2 Komponenten, dem Matching und der Action. Das Matching beschreibt die Eigenschaften der eingehenden Pakete, die die Regel triggern, und die Action ist das, was passieren soll - bei einer Portweiterleitung ist das der Austausch der Ziel-IP-Adresse des Paketes aka Weiterleitung.

Dein Matching sagt gerade:

• Pakete, die am WAN ankommen
• Pakete, die aus dem Subnetz 192.168.230.0/24 stammen

Und deine Action sagt:

- Weiterleiten an 192.168.230.200


Wie soll das funktionieren? 192.168.230.200 ist doch im lokalen Netzwerk, also LAN (bzw. WLAN) und die Quelle soll ebenfalls eine 192.168.230.x IP haben, aber am WAN sitzen? Das passt doch hinten und vorne nicht.

Abgesehen davon sehe ich keine Porteinstellung. Die ist bei einer Portweiteleitung zwingend erforderlich, steckt der Port doch schon im Namen.


Normalerweise ist bei einer Portweiterleitung die Quell-IP nicht reglementiert, also beliebig bzw. bei Omada offenbar "irgendein". Hier gibt man nur dann eine IP-Adresse vor, wenn die Portweiterleitung ausschließlich von dieser Quelle aus triggern soll. Ist die Quelle jedoch dynamisch oder schlicht und ergreifend nicht bekannt, lässt man die Quell-IP bei der Portweiterleitung leer.

 

[Rene0210]

So habe ich es von TP-Link bekommen und auch so eingestellt. Durch das Aktivieren der DMZ werden alle Ports geöffnet die die Telefonanlage brauch.

 

[redjack1000]

Welche Ports braucht denn die Anlage?

Wie hast Du kontrolliert, das die erforderlichen Ports verfügbar sind?

Cu
redjack

 

[Rene0210]

Diese Portliste habe ich mal von Telekom bekommen. Wenn ich diese in den Portweiterleitung einrichte sind dann Quell Port und Ziel Port immer die selben?
5432 TCP Postgres SQL Datenbank

61740 TCP CLA (bei zentraler Lizenzierung)

5060 TCP SIP / 5061 TCP bei Verschlüsselung

29100-30530 UDP Sprache

SIP-ALG muß deaktiviert sein.

 

[F31v3l]

Ich kenne mich nicht mit der Anlage aus, rate also etwas ins Blaue hinein, weil ich das für SIP-Telefonie bei meinem ISP in der OPNsense einrichten musste..

5432 TCP Postgres SQL Datenbank

61740 TCP CLA (bei zentraler Lizenzierung)

5060 TCP SIP / 5061 TCP bei Verschlüsselung

Diese Ports sollten für die Kommunikation zwischen Telefonanlage und SIP-Anbieter sein Diese muss die Telefonanlage im Internet erreichen können.

29100-30530 UDP Sprache

Das sind die eigentlichen Ports, wo das Gespräch stattfindet. Welche genau verwendet werden, machen der SIP-Server und die Telefonanlage untereinander aus. Hierzu musste ich ein Outbound NAT einrichten.

 

[Raijin]

Die ersten beiden Ports kann ich nicht nachvollziehen (Postgres + CLA), aber das sind ggfs separate Ports für andere Zwecke. Dagegen sind die SIP- bzw. Sprachports essentiell. Vereinfacht ausgedrückt findet über SIP (5060/5061) lediglich die Steuerung des Anrufs statt, Anrufen, Klingeln, Annehmen, Auflegen. Beim Verbindungsaufbau werden hier die eigentlichen Kommunikationsparameter der Verbindungspartner ausgehandelt, zum Beispiel die RTP-Ports, über die letztendlich das eigentliche Gespräch läuft. Diese Parameter werden automatisch ausgehandelt, beinhalten jedoch dynamische Ports, da es ja auch mehrere parallele Gespräche geben kann, und sind somit nicht so einfach zu identifizieren.

Das heißt: Wenn deine TK-Anlage angerufen wird, signalisiert sie, dass sie das Gespräch über zB Port 29123 UDP führen wird und genau über diesen Port kommen nun die Sprachdaten am Router an, der sie entsprechend weiterleiten muss. Beim nächsten Gespräch ist es aber womöglich Port 30278 UDP, für den die Portweiterleitung benötigt wird.

An dieser Stelle sollte SIP ALG einschreiten, den SIP-Traffic überwachen, die Ports auslesen und im Hintergrund die nötigen, temporären Portweiterleitungen erstellen. Wenn das nicht klappt, bleibt einem nichts anderes übrig als die Sprach-Ports als Portweiterleitung im Router einzurichten.

Problematisch wird es, wenn es mehrere SIP-Geräte gibt, die dieselbe Portrange verwenden, weil Portweiterleitungen nicht mehrdeutig sein dürfen, jede Range bzw. jeder Port darin darf also nur ein einziges Ziel haben. Dann müsste man in den jeweiligen SIP-Geräten die Portrange ändern bzw. einschränken, so dass sie sich nicht überschneiden. Das ist hier aber wohl nicht der Fall.

Wenn ich diese in den Portweiterleitung einrichte sind dann Quell Port und Ziel Port immer die selben?

Ich sage mal unter Vorbehalt: Ja. Es kommt letztendlich darauf an welche Ports deine Telefonanlage für die Sprachverbindung nutzt und genau diese Ports musst du im Router weiterleiten. Da deine Anlage von der Telekom ist, gehe ich mal davon aus, dass die von der Telekom genannten Ports die Standardports der "Octopus FX 3" sind.

 

[WhiteHelix]

5432 TCP Postgres SQL Datenbank

61740 TCP CLA (bei zentraler Lizenzierung)

Die kannst du dir sparen, die sind für Lizenzserver und Co. Aber bei der Anlage werdet ihr zu 99% die lokale Lizenzierung nutzen. Ansonsten, dürfen die UDP Ports auch in der Firewall rein/raus? Portforwarding der UDP Ports habe ich noch nie gebraucht, solange die Firewall das durchlässt reicht das. SIP ALG Erfahrungsgemäß auch immer aus, hat noch nie korrekt funktioniert.

Die Quellports für UDP von deiner Anlage hab ich grade im Default leider nicht mehr im Kopf, die Daten von der Telekom sind aber die Zielports auf der Telekom Plattform.

Die FX3 ist übrigens ne Unify X3, ggf. findest du die Default RTP Ports sogar im Internet. Nachdem was ich an Telekom Anlagen gesehen hab sind die auch zu 99% nicht geändert.

 

[Rene0210]

Vielen Dank ich werde das mal ausprobieren.

 

[norKoeri]

die Telefone Klingeln aber mal hört man den jenigen nicht der rein telefoniert und mal den der raus telefoniert

Auch im IP-Phone-Forum häufen sich die Meldungen, dass mit jenen Omada ER, die Telefonie nicht klappt.

Muss es überhaupt Omada auch als Router sein?

Der nächste Schritt wäre den Omada ER aus dem Controller herauszunehmen, auf dessen Web-Oberfläche zu gehen und den WAN-Port über Port-Mirroring in Wireshark mitzuverfolgen. Dann parallel noch den LAN-Port an der Telefonanlage mitschneiden. Normal sollte man keine Port-Freigaben für VoIP/SIP machen. Und schon gar kein Exposed-Host, weil solche Anlagen oft nicht dafür gedacht sind ungeschützt im Internet zu stehen. Und auch weil modernes VoIP/SIP das eigentlich gar nicht braucht. Mittels Wireshark müsste man dann sehr genau sehen, was genau verworfen wird.

 

[WhiteHelix]

weil solche Anlagen oft nicht dafür gedacht sind ungeschützt im Internet zu stehen.

Unify verkauft das sogar als offizelle Fernwartungsmöglichkeit das Webinterface einfach ins Internet zu stellen. Aber ja, sollte man natürlich nicht machen. 5060 musst du aber bei manchen Providern tatsächlich freigeben (Hust Vodaschrott).

Bzgl. Wireshark bietet die Anlage ja auch direkt die Möglichkeit für nen TCP Dump, dann lässt sich schonmal erkennen was ander Kiste ankommt/abgeht. Ansonsten gehe ich da komplett mit was den Wireshark vom Router angeht

 

[Raijin]

Ist denn der SIP-Zugang ansonsten vollständig konfiguriert, inkl. STUN-Server? Dessen Aufgabe ist es nämlich, genau solche Port-Arien zu vermeiden. Dabei wird eine Art Hole Punching betrieben. Der Client (die TK-Anlage) verbindet sich mit dem STUN-Server - eine ausgehende Verbindung - und der Router legt dafür automatisch eine temporäre Portweiterleitung für die Antworten an, die Firewall wird also geöffnet wie es bei jeder ausgehenden Verbindung ins www passiert - auch in diesem Moment für die https-Verbindung zu computerbase.de. Dadurch kann eben dieser Port für das Telefongespräch verwendet werden, weil der Port offen bleibt.

 

[norKoeri]

Telekom braucht kein STUN, aber man kann es mal probieren. Die Frage ist, ob Unify überhaupt UDP-Hole-Punching macht. Genau das sieht man dann in Wireshark. Ich befürchte, diese Omada haben einen Rate-Limiter, den man nicht abschalten kann. Weil RTP sehr schnell eingehend kommt, greift der dann. Aber wilde reinste Spekulation.

 

[WhiteHelix]

Bei der Telekom läuft zumindest beim Company Flex Latching, daher kein STUN.

Rate Limiter wäre auch so ein Klassiker, wenn die Dinger das nicht deaktiveren können sind die ja ein ähnlicher Ausfall wie die UniFi USGs. Wobei es da auch SIP ALG als Option gab, sobald das aus war liefs bei mir problemlos.

 

[Raijin]

Telekom braucht kein STUN

Bei der Telekom läuft zumindest beim Company Flex Latching, daher kein STUN.

Die Telekom bietet aber nun mal einen STUN und dann sollte der auch das tun können wofür er gedacht ist. Sonst würden sie in den VoIP-Daten ja nicht explizit einen STUN angeben, oder?
Probieren geht über studieren und eventuell lässt sich das Problem mit dem Telekom-STUN-Server binnen Sekunden lösen.

Wobei es da auch SIP ALG als Option gab, sobald das aus war liefs bei mir problemlos.

Das ist ja gerade das Bekloppte an SIP ALG. Eigentlich sollten damit die via SIP/SDP ausgetauschten Ports automatisch weitergeleitet werden, so in etwa wie bei dynamischen Portweiterleitungen via UPnP. Aber bisher scheint das mehr Probleme zu verursachen als dass es welche löst. Fast überall wird beim Troubleshooting zu SIP geschrieben: ALG deaktivieren.
Verrückte Welt..

 

[WhiteHelix]

Das Thema bei der Telekom ist halt, das STUN allein nicht reicht. Wenn das Latching nicht durch läuft legen die nach 20-25 Sekunden einfach auf. Also ohne Latching keine Chance.

Ja das mit dem SIP ALG ist wirklich so, immer deaktiviert und seitdem läufts Gibts oft bei übereifrigen Netzwerk Admins, die das ganz begeistert aktivieren, vor allem wenns ne neue FW gibt, dann kommst du als VOIP Mensch daher und sagst ihm mach aus

 

[norKoeri]

Die Telekom bietet aber nun mal einen STUN und dann sollte der auch das tun können wofür er gedacht ist. Sonst würden sie in den VoIP-Daten ja nicht explizit einen STUN angeben, oder?

Historisch gewachsen. STUN dient erstmal dazu dass in SDP die richtige IPv4-Adresse steht. Problem ist, dass es verschiedene STUN-Implementierungen gibt und auch hier Inkompatibilitäten in der Vergangenheit gab. Auf gut deutsch: STUN ist meiner Meinung nach durch, aber jetzt in der Situation schadet es nicht groß, es zu probieren.

SIP ALG. Eigentlich sollten

SIP-ALG ist nicht definiert. Es kann alles Unmögliche machen; normal ist sogar dass SIP und SDP umgeschrieben werden. 3CX bietet ins seiner Variante On-Premise die Möglichkeit eines Firewall-Checkers … Der arbeitet sehr gut, ich kenne nichts Vergleichbares und kann es daher nur weiter empfehlen, lohnt sogar dafür sich kurzzeitig 3CX zu installieren.

die via SIP/SDP ausgetauschten

Ich kenne jene Unify zu wenig, aber wenn SIP-over-TLS zum Einsatz käme, dann sieht das SIP-ALG gar nichts mehr. Auch sind manche SIP-ALGs nur für SIP-over-UDP ausgelegt und greifen nicht bei SIP-over-TCP.

 

[WhiteHelix]

Ich kenne jene Unify zu wenig, aber wenn SIP-over-TLS zum Einsatz käme,

Die Anlage kann das und der CLFEX macht das mittlerweile eigentlich auch. Ist n bisschen die Frage welches Produkt genau da dran hängt.