Changing UDP (RTP) ports away from the 10000-20000 range

[sawgood1000 (Shawn Frye)]

Hi SangomaOS team:

To change the UDP RTP port range from 10000-2000 (to something else):

Is this as easy-as changing the range in the UI (under)
Advanced SIP settings

Change from 10000-20000 (to something else) SAVE and APPLY?

[Stewart1 (Stewart)]

You may also need to restart Asterisk. This change will drop all calls in progress anyway, so you might as well do the restart.

Also, if the PBX is behind a NAT, you should change the port forwarding in your router/firewall to match the new RTP ports.

[sawgood1000 (Shawn Frye)]

Thank you for those tips!

[AdHominem]

You can change it in the UI, but I recommend against it.

And definitely do NOT forward external ports from your router unless it is absolutely necessary. It rarely is.

[Stewart1 (Stewart)]

@AdHominem

You can change it in the UI, but I recommend against it.

I assume that the OP had a good reason to change it, or he wouldn’t have asked. For example, to run two or more PBXes sharing the same public IP address. Or, to avoid a conflict with a non-VoIP application that happens to use UDP ports in that range.

@AdHominem

And definitely do NOT forward external ports from your router unless it is absolutely necessary. It rarely is.

IMO most of the systems out there need it. Very few router/firewalls have proper SIP ALGs that monitor the SDP and open RTP ports correctly, while also avoid mangling the signaling.

In most cases, it ‘sort of works’ because incoming audio appears as a reply to outgoing audio. Consider an on-site system with extensions on the LAN and trunks on the public internet. When you make or receive a call, audio from the extension gets sent to the trunk, so audio from the trunk can pass back to the PBX and be relayed to the extension. Now, if you forward incoming calls to an external mobile, it stops working because each trunk is sending audio, which doesn’t pass because none has yet been sent out. Sometimes the admin will work around the issue by sending progress in-band, or routing the call to a dummy announcement before ringing the extension.

Most cloud systems behind NAT (AWS, GCP, etc.) have this issue because the firewall is not SIP aware. This is also true of most on-site systems with (non-VPN) external extensions.

IMO the risk of forwarding RTP ports is miniscule and the effort required to avoid it would be better spent securing other aspects of the system. AFAIK RTPbleed is the only such vulnerability discovered, and it was never significantly exploited.

[AdHominem]

@Stewart1

I assume that the OP had a good reason to change it, or he wouldn’t have asked. For example, to run two or more PBXes sharing the same public IP address. Or, to avoid a conflict with a non-VoIP application that happens to use UDP ports in that range.

If the OP had one of the reasons you described, I suspect that he would have been able to find the setting in the modules without asking for help finding them in this forum.

@Stewart1

IMO most of the systems out there need it. Very few router/firewalls have proper SIP ALGs that monitor the SDP and open RTP ports correctly, while also avoid mangling the signaling.

Most firewalls handle RTP just fine (or as you say “sort of work”), without enabling SIP ALG, for the reasons you describe. However, changing the RTP ports often breaks their ability to do so, which is presumably why you recommended forwarding the ports.

@Stewart1

Now, if you forward incoming calls to an external mobile, it stops working because each trunk is sending audio, which doesn’t pass because none has yet been sent out. Sometimes the admin will work around the issue by sending progress in-band, or routing the call to a dummy announcement before ringing the extension.

You are 100% correct here, and if this is a necessary feature and you don’t want to use the work-around you described, forwarding RTP ports is essential. Another work-around is to forward the call at the ITSP level and bypass the issue altogether.

@Stewart1

Most cloud systems behind NAT (AWS, GCP, etc.) have this issue because the firewall is not SIP aware. This is also true of most on-site systems with (non-VPN) external extensions.

I always find references to virtual machines amusing, but for a reason that you might not be aware of. If you go back in time in these forums, you’ll see that I was one of the first people who advocated for using FreePBX with virtual machines. I tried it, and it worked great. I posted about it here and told everyone how great it was.

The uniform response that I received from the then regulars (all of whom are gone now) was that I was crazy and it would never work. The argument then was that you needed a dedicated machine to be able to handle the RTP without introducing jitter and latency. I kept replying “but it works great,” and the answer I kept getting was “no, it can’t.”

@Stewart1

IMO the risk of forwarding RTP ports is miniscule and the effort required to avoid it would be better spent securing other aspects of the system. AFAIK RTPbleed is the only such vulnerability discovered, and it was never significantly exploited.

There are known exploits and unknown exploits. By definition, the risk of the unknown exploit is unknown. Opening a port to the world exposes you to both.

IMO- you should only do it when you have to. And since there are always better options (the work-arounds you described, VPNs for remote access, etc.), my view remains that you should almost never have to. It certainly shouldn’t be the routine answer.

[AdHominem]

@Stewart1

For example, to run two or more PBXes sharing the same public IP address. Or, to avoid a conflict with a non-VoIP application that happens to use UDP ports in that range.

I don’t think that these are reasons to change the RTP ports used by Asterisk. Netfilter’s Masquerade function should be capable of managing multiple devices that use the same service ports vis a vis the outside world.

That’s why you can have 30 computers that all use port 80 to send out web traffic, or 30 SIP phones all using Port 5060 for signalling.

@Stewart1

In most cases, it ‘sort of works’ because incoming audio appears as a reply to outgoing audio. Consider an on-site system with extensions on the LAN and trunks on the public internet. When you make or receive a call, audio from the extension gets sent to the trunk, so audio from the trunk can pass back to the PBX and be relayed to the extension.

This is actually only partially true. I agree that it only partially works because you cannot forward calls without actually initiating the RTP stream locally.

But, Netfilter (and most consumer routers that rely upon it) has a well known and often utilized “allow related” function. Even without the dreaded SIP ALG, most routers treat ports 10000-20000 as related to port 5060. When you move outside of that range, you break that functionality.

Once you do that, you’ll either have to manually open the ports, or rely on the outbound traffic to open them using the “allow established” functionality. The latter can cause a noticeable delay in RTP traffic after a call is completed, which is another reason that it’s better leave the ports at default.

[dirk2358]

Very interesting security related issue.

@AdHominem

This is actually only partially true. I agree that it only partially works because you cannot forward calls without actually initiating the RTP stream locally.

But, Netfilter (and most consumer routers that rely upon it) has a well known and often utilized “allow related” function. Even without the dreaded SIP ALG, most routers treat ports 10000-20000 as related to port 5060. When you move outside of that range, you break that functionality.

I did a lot of tests and investigations regarding the “related” function. Besides the point Stewart1 already mentioned, there is another annoying problem: I encounter a lot of calls with dropped first syllables because trunk sends media before asterisk sends media. This is true here for many of completely “normal” calls without any early media in place (SIP and media address differ). I even remember completely broken calls in case of early media / send only. I didn’t hear any announcement because asterisk didn’t send anything to trunk … . From my point of view, it’s kind of stupid to use the related function because you never can be sure to always get each media!

Besides that: I wouldn’t know, why static forwarding of a defined UDP port range (and known remote IP address(es)) to a local dedicated IP (which is used exclusively by asterisk) should harm? Asterisk opens the “RTP” listener exclusively for each stream and closes it afterwards again.

The far more critical and broken (from a security perspective) thing is, that Asterisk / pjsip always opens a SIP listener for each defined transport (e.g. tls / 5061 or tcp / 5060 - but nowadays, you always should / must use tls) without an additional patch though it often isn’t needed at all (RFC5626 “Flow” - pjsip supports the basics of RFC5626)! Nowadays, you shouldn’t need any listener for connection to a (modern) trunk anymore.