Remote phones not auto provisioning

We recently changed ISPs, with that came a new IP address or our PBX. I have a remote Sangoma S500 phone. This phone is not auto-provisioning and grabbing the configuration from the Sangoma server. I have changed the IP/FQDN address on the Sangoma server for the phone to my new IP (http://username:[email protected]:84). I also have all the same port forwarding rules on my router as before (port 84 is open, as well as others). I have tried rebooting the phone, forcing the phone to auto-provision through its GUI, and even changing the config and firmware address on the phone’s GUI (It was still showing the old IP address after several auto-provision attempts), none of that is solving it.

How can I get the phone to grab the config from the Sangoma site?

Sounds like something on your network is blocking it. Also if you change IPs how would the phone reach the new IP without the phone knowing the new IP.

I know you said you changed the config IP on the phone so at least for that test now the phone knows how to reach the PBX and it’s still not updating you said which means something is blocking it.

The phone also is not grabbing the provisioning from the sangoma portal. Would that mean something on the network the phone is on is blocking it?

I had this problem a few months ago. with a S500 and S700.
I just deleted the phone from the portal and added it again after some minutes. And then it worked again :smiley:

Dont know what the problem was but you can try it. Maybe this also works for you.

Thanks for the reply, Matthias. That actually seems like a decent solution, but I don’t seem to have the option to delete a phone from my sangoma portal.

I was able to get the phone to provision from the portal by doing a factory reset on the phone. So, the phone has the configuration, but it is still not connecting to the PBX. I’m starting to suspect the firewall. I have port 84 forwarded to the PBX on my router and my router has a firewall on. I’m also using the freePBX firewall, HTTP provisioning service is set to local and other. Do I need to add the IP address where the remote phone is to get around the firewall? If so, where do I add that? I have confirmed that the firewall does not list the IP address of the remote phone as a blocked host.

1 Like

I was now able to get the remote phone to register with the PBX, however, I had to temporarily disable the PBX firewall in order to get it to register. The phone still works with the firewall enabled now, but obviously I have a bad setting on the firewall.

Do I need to add the IP address where the remote phone is to get around the firewall? If so, where do I add that?

Should I have my PBX in the DMZ on my router?

Is the phone associated with a UCP user?

If this worked with the firewall down AND you’re using UCP for the user interface, it should open the firewall to that user’s network.

It might be time for a bug report or feature request. It sounds like everything is there to get this working except for one or two tweaks.

The phone is associated with a UCP user. I’m unsure what you mean by “you’re using UCP for the user interface”. We use endpoint manager to provision the phone. The phone’s extension is tied to a UCP user. Do I need to have the user login to UCP from their network in order to add the network to the firewall?

On my firewall>Status>Registered endpoints page it says “No Endpoints have been allowed through the Responsive Firewall”

Not necessarily. If you are using responsive to register your remote devices, the provisioning ports are only opened dynamically by Responsive AFTER a successful registration. Obviously you can’t register a device until it has first been provisioned, and if using responsive you can’t provision a device until it has been registered. The first provisioning attempt must be done from a trusted host, which is easily done by temporarily white listing the phone IP in the networks tab.

Thanks Lorne. I have added the IP of the remote phone as trusted in the firewall settings. Hopefully, that will solve the issue.