3CX in DMZ - local Firewall Traffic <=> Ports

[iphh]

Hallo zusammen,

ich habe das erste mal einen 3cx on prem Server in einem eigenen/getrennten VLAN laufen. Die Desktop Telefone (Snom), Windows Phones etc. befinden sich in einem anderen VLAN.

- Die Firewall Ports (extern) sind entsprechend eingerichtet.
- Auch die internen Ports (zwischen den VLANs) sind konfiguriert
(nach anfänglichen Problemen mit dem Desktop Phone Audio habe ich dazu noch diese Port Range gefunden, die nicht in der 3CX Doku aufgeführt waren: UDP 7000-8999 3CX Media Server (RTP) – LAN audio/video/t38 streams

Firewall check läuft durch, Audio Streams sind in beide Richtungen möglich, sowohl bei den lokalen Desktop Phones als auch bei den Tunnel nutzenden Apps.
Soweit alles gut, aber ich bekomme im Firewall Log noch zwei geblockte Ports angezeigt (rote Zeile). Ich versuche es nachzuvollziehen:

10.10.40.30 3CX Server (TK-Netz)
10.10.30.28 Desktop Telefon Snom (VLAN-Produktiv)

Da es zwei aufeinanderfolgende Ports sind, sieht es nach RTP Traffic aus. Habe dann nach etwas Recherche gefunden, dass SNOM im Deskphone immer Default folgende dynamische Port Range benutzt:
Dynamischer RTP-Startport 49152 UDP
Dynamischer RTP-Endport 65534 UDP

Das würde von zu den geblockten Ports passen. Im nächsten Test wurden z.B. 63460 + 63461 geblockt.

Liege ich mit der Vermutung richtig? Ändern sich die Ports durch Firmwareupdates in der Regel nicht?

Dann müsste ich die UDP Port Range 49152-65534 noch zw. 3CX Server und VLAN Produktiv zulassen und die Sache sollte erledigt sein.

Ich beschreibe es so im Detail, da ich es gerne vollständig verstehen möchte. Zusätzlich frage ich mich, warum trotz Port Block die Audio Streams in beide Richtungen möglich sind.

Im Screenshot seht ihr, dass der Traffic in die andere Richtung (Deskphone 10.10.30.28 => 3CX 10.10.40.30 7036/63460) problemlos durchgeht, da UDP 7000-8999 3CX Media Server (RTP) geöffnet wurde.

 

[bitn]

Im englischen Forum gibt es die Auflösung dazu:

Solved - No audio between two LANs

HI there, We have a number of local networks. It seems that the audio track in getting blocked. We have opened the requested ranges of ports between subnets, however it seems that the audio (udp) ports shift and eventually wonder out of opened range. Are the ports required for the firewall...

www.3cx.com

 

[fxbastler]

Liege ich mit der Vermutung richtig?

Kann sein.

Ändern sich die Ports durch Firmwareupdates in der Regel nicht?

Das kann dir nur der Hersteller beantworten. Das ändert sich nach deren Gutdünken (gern erklärt mit techn. Erfordernissen) und kann von Hersteller zu Hersteller anders sein (und ist es i.d.R. auch).

habe ich dazu noch diese Port Range gefunden, die nicht in der 3CX Doku aufgeführt waren: UDP 7000-8999 3CX Media Server (RTP) – LAN audio/video/t38 streams

Die waren schon in der 3CX Doku aufgeführt. Die Betonung liegt auf waren. Die Website https://www.3cx.com/docs/ports/ ist nicht mehr direkt abrufbar, nur noch über die wayback machine. Da stehen deine monierten Ports 7000-8999 und die Erklärung wann man die handhaben muss. Wenn man sich genau in einer 3CX umschaut, dann sieht man auch deren Firewall Einstellungen. Das ist ein weiterer guter Ansatz benötigte eingehende Verbindungen zuzulassen. Über die 3CX Parameter sind diese auch sichtbar. Das ist nicht festgelegt, ist alles parametrisiert, kann man alles ändern - sollte man nur tun bei Bedarf und wenn man damit umgehen kann.

Die Herangehensweise der Regulierung ist fragwürdig. Das erklärt deinen Satz:

Ich beschreibe es so im Detail, da ich es gerne vollständig verstehen möchte.

Das sind die Grundlagen von Kommunikation über IP, nichts anderes. Hier noch dazu SIP wegen der Aushandlung auf einem höheren Protokollniveau.

Beschrieben ist, an was für eingehenden Ports eine 3CX Verbindungen annimt und aufnimmt und wofür. Grundsätzlich sind nicht die ausgehenden Ports von Verbindungen zu hinterfragen (das können über 60k sein, macht keinen Sinn das regulieren zu wollen) sondern das Ziel und deren Ports an denen Dienste Anfragen annehmen können.

Neben den div. RFC und allgemeinverständlicheren Abhandlungen über IP Kommunikation sind folgende Links vielleicht hilfreich:

• https://www.3cx.com/blog/voip-howto/sip-invite-header-fields/ besonders auch die unten aufgeführten Links mit weiteren Erklärungen
• https://www.3cx.com/blog/voip-howto/nat-stun-network-configuration/ trifft auch das Innenverhältnis

Nachtrag: hab zu lange daran geschrieben, bitn war nur eine dreiviertel Stunde schneller