Sangoma Connect Keeps Trying To Register

We have Sangoma Connect setup and according to the system it is showing that SangomaConnect and CloudConnect Agent Status are Running.

Utilizing the cellular network, I installed the android app and used the link in the SangomaConnect email to setup the app. All of that seems to work fine. However I noticed that the phone pulled my extension, but keeps showing “registering” after a little while it shows “error” and goes back to “registering”. According to the SangomaConnect module it shows my extension as being “Authenticated” and I can see details about my calls that were answered, missed, etc…

We have the Sangoma IP addresses added to the sangoma firewall as trusted networks and looking into our corporate firewall I don’t see any blocked packets to our public address for our phone server.

Any ideas why the phone isn’t full registering?

1 Like

Sounds like the client can’t reach the PBX, but the push servers can. If the the firewall(s) don’t permit the client from connecting, you might see this. Feel free to open a support ticket if needed:

Lorne, I’m having a similar problem but when I go to open a ticket it says there are no Commercial Modules, despite us purchasing Zulu in March of this year.

*Never mind, apparently we have multiple IDs. I found the right one.

1 Like

pvr2002 I worked with support and had to open up my firewall for TCP and UCP 5060 to forward to the PBX

External IP address changed on our server. Sangoma Connect phones just said registering afterward. Admin->Sangoma Connect>Domain Action->Update Certificates resolved that issue.

In my book this is a problem. Opening up the world to the sip port on a server is never a good idea. Even on this forum alone you can search and find the horror stories of what can happen when you do this.

If someone is NOT comfortable opening up the world to their SIP port and having it sniffed and hacked what is the other option? It would be great to have some secure connection method to the client device that doesn’t involve a separate VPN app on the phone and forcing Connect through that app. This solution works great for me, however when thinking about the general user population that’s not an option. They simply want to open the app and be able to make a call and receive calls.

Any solutions out there to use this securely w/o opening 5060 to the world?

If your only take-away from those horror stories is not to open up the SIP port, then you are missing the point.

SIP is an internet protocol. So are smtp/imap. No one goes around saying “don’t open your email ports!” Instead, what do they do? They use secure email transport and good passwords. That’s exactly what you should do with SIP.

On another thread, I read that TLS is on the roadmap for Sangoma Connect. If you are concerned about SIP over TCP, wait for the TLS feature.

I never said NOT to open it, just don’t open it to the world. You think having a password means you can’t be hacked? Interesting…Password protection was great in the 70’s and we’ve evolved.

I don’t have my SMTP open to the world either, there’s no reason for it. Use a good provider for mail filtering and then ONLY allow their servers inbound to your SMTP.

Opening ANY port to the world and trying to buy layers on top of it to secure it is the worst possible security scheme. Control who and what has access to it and stay off the radar.

What ever happened to DENY being the default over ALLOW?

Anyway, I digress…I’ll wait for some evolution on the product before expanding the use.

1 Like

You can certainly do this with your firewall but you have to know what to allow. That limits your mobility, doesn’t it? What would you propose?

Plenty of options, none baked into the app however.

  1. Client VPN as mentioned in my OP, then force app through it - not ideal for novice users and lots of “I’m not connecting” calls
  2. If you have company paid phones on the same provider, add their netblocks to your firewall for inbound. It works, we’ve tested. Some use the same netblock regardless of your physical location as I’ve seen a user in Miami have the same netblock as one in Chicago. I’ll take my chances with 70 million IPs instead of 4.294 billion.
  3. Cell providers allow for static IPs now on handsets. This is another good option.

As with most things technical, there are lots of ways to slay the dragon and you pick what works best for you as a balance of security, cost and convenience to the users.


I use a few lines of defense, none of which are onerous to enable:

  1. SIP ports are chosen randomly in the 30k-50k range
  2. responsive firewall enabled
  3. fail2ban acts as backup to responsive
  4. I’ve setup APIBAN

Point 1 means I get a few brute force attempts per year instead of per minute. Point 4 eliminates most of the active SIP exploits from even getting past iptables. Point 2 blocks hackers that APIBAN misses, and fail2ban only kicks in when something comes unglued. I sleep fine at night.

I’m doing TLS + SRTP for all endpoints, and leaving the standard port 5061 open. I have very few concerns about this and scanners don’t really bother to poke at it. (I get some probes just once in a while.) There could be more controls in place, but I do not see the point. I do not see VPN as a better option if the VPN terminates at your PBX (you still have an open port there).

I just came back here because I checked out our CDR reports looking for a call from last week, and my extension is getting hammered.

VPN isn’t an option, no personal devices connecting to the corporate network.

Lorne, is there a write-up anywhere of those 4 steps? I can search, obviously, but maybe someone has a how-to and I can be pointed at that.

The usefulness of the app is high; to the point that it might be worth switching from our Mitel early and just eating that extra expense, but security makes me nervous.

Turning off Anonymous SIP and Allow SIP Guests should stop the CDR noise while allowing the remote extensions through. Unmatched/unauthed SIP requests just get challenged by PJSIP and they go away.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.