Why does everyone say change default SIP 5060 port when VoIP Providers don't support it?

Hello,
I have multiple FreePBX 13 cloud servers setup. I have them secured with the responsive built-in firewall. As expected I see tons of scans and attacks from random IPs. I would really like to change the default port from 5060 to something random like 485069. I built a test server and changed the 5060 port to a random high number port and was able to get my phones to connect to it. I registered the trunks with my VoIP Provider, Vitelity. I was able to make outgoing calls but incoming calls were not working.

I reached out to Vitelity and they told me that their system will only work on port 5060. I got a few different answers and one tech told me that IP authentication will not work but a register string with port defined in it should work for incoming trunk. I tried that and still no go.

My question is everyone recommends you to change the default SIP port but what good is it if the VoIP providers don’t support it?

Is there a way to have only the trunk IP address access to 5060 but all phones (located in many different offices) connect to FreePBX server on a predefined random high port.

I know VPN may be a solution but I am trying to avoid having to add extra configuration on each phone for VPN. I know that having a high port number is not 100% safe and there is a risk, but it significantly lowers the risk compared to running the system on port 5060. When I changed the port in my testing trial to a high port number my system was not attacked even once on SIP for an entire month.

Any suggestions will be appreciated.

Assuming the IP of your VoIP provider never changes, you can create a firewall rule that only allows connectivity on port 5060 for Vitelity. Set up your endpoints on any other port you want using sip over TLS and SRTP if you want as well.

setup your firewall to only allow trusted ip’s but make sure the responsive firewall is enabled for chan sip. white list the vitelity ips in fail2ban and make them trusted ips in the firewall zones. leave the sip port alone. be sure to use ip authentication with vitelity as well. this should allow any remote phones that don’t have static ip’s to register but should for the most part secure your system.

You can listen on (almost) any ports you want. Vitelity is telling you they only listen on 5060. That means you connect to them on 5060. It does not mean you have to use the same port on your side.

The top of the ports range is 65535 so you will not be able to use your example of 485069.

1 Like

Thank you all for your reply. I understand there are only 65xxx ports avaiable on an IP address the 485060 was a typo on my part.

@billsimon - I want to do something like what you are suggesting. I am afraid I am missing something. Once I go into the Chan SIP setting under Advanced SIP Settings and change the bind port from 5060 to 45069 for example, doesn’t that set the entire server to only listen on port 45069 for SIP traffic. Once I do this my phone can connect up to the FreePBX server and I can make outgoing calls. When i try to call (incoming) I get a busy signal. This is because the FreePBX server is now configured to listen on 45069.

bksales - I have the system setup like you suggested right now with SIP running on 5060. The responsive firewall is enabled and does show me the attackers that have been banned. I just hate seeing those IPs there. I would like to completely minimize the exposure of my PBX system on a common known port, if possible!

Kolpinkb - if you can provide some more input on how I can do that, My understanding is once I set the PBX server to listen on 5060 for SIP my phones have to be configured for 5060 also and brings me back to the same spot of being exposed on 5060 to the world with a responsive firewall.

Thanks for all your help! I really do appreciate it.

If your PBX registers to the provider then this action should handle the alternate port (i.e. Asterisk tells the provider its contact address including the :45069 part). I can tell you I have changed my SIP port and use Vitelity and did not have to do anything special for it to work.

Review logs and see if you can find the incoming call traffic.

http://wiki.freepbx.org/plugins/servlet/mobile#content/view/64946938

Default is 5061 but you can change it to whatever you want.

Also, important to choose an ambigious subdomain. I made the rookie mistake once of setting up an A record along the lines of pbx.example.org and i got flooded with attacks. Lol

Billsimon,
Thank you for the follow up. I have spoken to vitality support reps and they keep telling me that if my FreePBX server tries to make a connection on any other port other than 5060 it will not work. When I change the port to 45069 for example, outgoing calls work but income does not work at all. When I change the port back to 5060 I start getting incoming calls.

Would you mind sharing your configuration settings / truck settings for Vitelity for alternate port? I have tried everything but can not get it to work.

That is correct. The wording is exact, but I think you’re mis-reading it.

If it tries to make a connection to any other port, it won’t work. It must connect to port 5060.

When you send your registration string, FreePBX tells the other server what port it is listening on. You have no need to change anything, as long as it is set correctly in SIP Settings.

Your server (port 12345) → Other server (5060): Hi. I’m user abc, and I’m on port 12345 (REGISTER)
Other Server (5060) → Your server (12345): OK!

Later …

Other Server (5060) → Your server (12345): You have an incoming call.

1 Like

See Rob’s answer. He explained it nicely. To be clear, I do not have any “settings for Vitelity for alternate port” – just the regular Vitelity setup that they prescribe. The only place I changed the port is in the Asterisk SIP Settings - bindport field. This does not in any way change how I connect to providers, only how clients (my own phones & softphones) connect to my PBX.

That inbound calls from Vitelity don’t work when you change the listening port doesn’t make any sense, maybe points to a network configuration problem. You should start a new thread and describe your network topology a bit. I recommend ending this one because the premise is not true - VoIP providers don’t care what port you listen on locally.

Xrobau - Thank you for the explanation!

Billsimon - Thank you too! I will go back and play with these settings. I wanted a more experienced person to tell me what their thoughts were on this problem I am having. I will troubleshoot it more on my end and start a new thread as needed!

Okay I have an update.

I tried the settings on a FreePBX 12 system. I registered my pbx system to Vitelity and I was able to receive phone calls.

I tried the same on a FreePBX 13 system. The phone system registers (i am able to make outgoing calls). When i try to test an incoming call I get a fast busy. I contacted Vitelity and they said My server isn’t responding to Invite to setup the calls. he sent me a log of this

Dec 13 16:01:53.498 PM 66.241.99.83 > 45.xx.xx.xx INVITE sip:[email protected]:5060 SIP/2.0
Dec 13 16:01:54.498 PM 66.241.99.83 > 45.xx.xx.xx INVITE sip:[email protected]:5060 SIP/2.0
Dec 13 16:01:55.498 PM 66.241.99.83 > 45.xx.xx.xx INVITE sip:[email protected]:5060 SIP/2.0
Dec 13 16:01:57.497 PM 66.241.99.83 > 45.xx.xx.xx INVITE sip:[email protected]:5060 SIP/2.0

If I change my SIP bind port back to 5060 i can get incoming calls. I have tried to turn off / disable the built in firewall in 13 but still get the fast busy. Could it be that the invite is coming in on port 5060 on my server which I have changed to 4xxxx INVITE sip:[email protected]:5060

Thanks

Yes, it says in the log that he sent that they are sending the calls to sip:[email protected]:5060 <—

Which means that your server registered port 5060 with Vitelity. Something must be different between the way you are setting up the trunk on FreePBX 12 and 13. Are you using chan_sip in both cases? Are trunk settings and Asterisk SIP Settings identical?

If you are using Vitelity’s ip authentication, then you will need to add a PAT (port address translation) from 5060 to 4xxxx for the ip’s from vitelity’s ‘inbound’ servers (use 64.2.142.0/24 for the source, I believe it covers them all) You can do that on your firewall (hopefully) or locally in iptables.

Billsimon - I copied and pasted the Chan_SIP settings from the 13 to the 12. (i setup a new test server in the cloud to see if that makes a difference)

I am not sure why the 13 version is doing the registration on 5060.

dicko - I am using FreePBX built in firewall and I don’t see an option for PAT anywhere in it. I see custom service and only ability to define name, protocol and port range.

http://wiki.freepbx.org/display/FPG/Firewall

I read through here but couldn’t find anything with PAT. Is it even possible in this version of the firewall to forward a port to another one ?

Pretty sure dicko’s recommendation does not apply since you stated you are using SIP registration. (His advice pertains to IP-based routing, unless I misunderstood.)

Billsimon - I am open to IP Authentication. This is how I usually set up my PBX Servers. I went the registration string route because I was told by Vitelity to trythat along with a few other people. I would be open to port translation and apply the rule to Vitelity’s IPs. I don’t see that feature in FreePBX 13 Firewall.

Give it a try and see how it works. Just remember to add the port at the end of your IP when you enter it into Vitelity’s config. E.g. 45.xx.xx.xx:45069

If that works for you then your problem is solved, but I am curious why the SIP registration isn’t working out as expected.

Billsimon - I got it to work. It worked exactly like you and others described it. I used a same test phone number to test on my freepbx 12 box. The incoming worked with standard registration of the server with Vitelity. Then when I booted up 13 PBX and in Vitelity routed the phone number to the 13 box it didn’t take and was routing to an account that did not exist. I have spent over a month on this issue that really wasn’t even an issue.

Thank you all for you time and advice, much appreciated!