Firewall port closed - RTP still flowing

[George Ts]

Hello,

Let's assume the following simple setup:

Internal 3cx (RTP port 9000) - - - > Firewall - - > Internet - - > Provider (RTP port 10000)

The internal 3cx has a SIP trunk with the provider and UDP port 5060 is open on the local Firewall, so SIP negotiation is OK.
However, RTP port 9000 is NOT open.

Let's assume that the provider is calling towards 3cx and let's assume that in the SDP, 3cx has negotiated its port 9000 and the provider its port 10000.

If the provider starts sending media first from its port 10000, the first UDP packets towards 3cx's port 9000 will be blocked, as port 9000 is not open in the firewall.
However, a few milliseconds later 3cx will start sending media from its local port 9000 to the provider's port 10000 (as this was agreed in the 200 OK's SDP).
Thus, the Firewall's stateful inspection will allow backwards traffic from the provider's 10000 to the internal port 9000, even if the very first RTP packets were blocked.

At least, this is my understanding.
If this is the case, why do we even need to open UDP (RTP) ports on the firewall?

Hope my question is clear.

Regards,
George

 

[YiannisH_3CX]

Hello @George Tsionos

That is a very good question that should also be answered by firewall vendors as this may not always work as you describe. If you want to rely on your firewall doing this correctly then you could in theory do it. But i think you will find many recent threads in the forum with people having no audio because we increased the media server ports and those ports were not opened on the firewall.

Also there are a few scenarios where you need to receive audio and the PBX has not yet sent anything or will not send anything. A good example is early media where you get Early media from the provider with a Receive only message. In that case you will be able to hear the message from the provider.
Opening the ports covers most if not all scenarios and you do not need to worry about what the firewall will do or might not do in each of them. Also something to note is that the 3CX media server will drop all packets that arrive from a non negotiated port and IP so from a security perspective you have nothing to worry about.

 

[cobaltit]

@George Tsionos

I have a much simpler answer than @YiannisH_3CX . I want my audio to work all of the time, not most of the time. Thus I port forward the necessary ports.

 

[George Ts]

Hello,

@YiannisH_3CX , I believe that Early Media is the answer to my question. Unless a port is open on the Firewall, this scenario will not work. Thanks for reminding about that. It's also good to know that 3cx will not accept packets to a non negotiated port.

@cobaltit well - excluding the early media scenario - it works all the time with a Cisco ASA firewall. I guess it's a decision between guaranteeing two-way audio and exposing as less ports as possible.

Thank you for your prompt responses.
George

 

[cobaltit]

@George Tsionos

That's just it, it works all the time until it doesn't. You'll see hundreds of threads that start out with "nothing changed in my network but I have audio issues all of a sudden" with responses from 3CX or folks like myself asking if it passes the firewall checker and if they did the port forwards. Then you'll see something like "it's always worked this way before" and then when they make the recommended changes things work. It's about preventing problems.

If you are really security conscious you can just use an ACL to restrict access to those ports instead. Considering how SIP is really the port to be concerned about anyways as far as hacks/toll fraud/etc I imagine you are already filtering that port so just expand that ACL to include the RTP range as well. And if your not, well.....

 

[YiannisH_3CX]

I am glad we could help