Setting up Sangoma phones to use VPN. (FreePBX 13)

I currently use FreePBX 13 / Asterisk 13 / Firmware 10.13.66-17 on-premise PBX server. I’m trying to utilize the VPN server and setup a Sangoma s700 IP phone. I’ve followed the “Sys Admin - VPN Server” article on the Sangoma support site but the phone fails to establish a connection. The server is directly connect to the internet and uses the builtin firewall. I’ve verified OpenVPN is permitted through internal, other and external connections. I’ve verified a listening port 1194 is open using NETSTAT. I’m at a lost at this point. Any suggestions?

Before the VPN can be established, the phone must provision itself, which means that in addition to VPN service access, it also must have access to the provisioning protocol of your choice. First get the phone provisioned and working without VPN.

Hello lgaetz. The s700 has already been provisioned with the PBX server. When the phone is directly connected to the network, I’m able to use the phone freely. I’ve verified the extension is using the VPN profile setup within the VPN server settings section. I’ve also perform a “save, rebuild config and update device” with in the extension mapping section. I’ve also used the OpenVPN client on my laptop and verified I can connect to the PBX server. Is there a log that the FreePBX server uses for OpenVPN connections? It’s difficult to determine if the IP phone is even reaching the PBX server.

I am at the same point over here. I have gotten the phone to provision and use VPN but it wont register. I can ping the phone from the PBX with its VPN address and it responds but no registration. What else could be going on?

**** Update ****

I did away with the FQDN in the VPN service and put in the IP address and everything started to work.

So under system admin /vpn server did you put in the static ip of the server?
My phone has loaded the config, however won’t register
it shows vpn enabled and when i go to the gui of the phone in account 1 the Primary Sip Server is

Any help would be much appreciated

The right way is for the template to have either the public or the private IP in the template.

If the phone is going to be on the same LAN, then put in the redirect server.

If the phone is going to be outside your LAN, put http://(httpUsername:HTTPpassword)@FQDN:83 as the redirect server.

Port 83 and 1194 need to be open.

The Httpusername and httppassword can be found under the system Admin/Provisioning Protocols. Note, there is a colon between them. username:[email protected]:83

Guys let me hop in with an additional question that you seem to have gotten past already…

Are you downloading the VPN config from the UCP page to upload to the phone? I followed the same guide, but when I download the VPN client config from the UCP, it’s an empty zip file. Any of you seen this behavior?

The phone should automatically download the config from Endpoint manager when extension mapping is setup properly.

One thing I noticed with the Sangoma S700 IP phone is that it’s expecting a TAR file. When downloading the VPN profile from the PBX server, it’s in a ZIP file, containing 3 files. I’ve archived the 3 files into a TAR file manually but I’m still not having any luck with this VPN server.

Guys I think you are all way over complicating this

The wiki here outlines it.

You dont have to download any tar files, you dont have to change templates.

Once you enable VPN for a user in user manager and have your VPN server running all you do is in end point manager you go edit extension routing and tell the extension what VPN client to use. This will rebuild the config for that phone and have it connect to the PBX using the VPN IP not the IP defined in the template.

1 Like

Sangoma support was finally able to get things working but it took them several hours. We had to configure the phone locally first and then send it out into the wild after it had configured locally. I’m not sure what all they did because they were doing it but a few days later, they got it to work.

It was much harder than I’d expected and if I had to add another one, I don’t know how to do it because I don’t know what they finally ended up doing to make it work.

I’ve been beating my head against a wall trying to do the same thing with my S300. I finally just got it working. As mentioned above I also had to put in the IP of my VPS, I had to enable the Endpoint Manager template as both Internal and External default. The part that I believe finally got it working was that I had to enable DDNS in System Admin. My VPS has a static IP so I never even thought about using DDNS until I downloaded the OpenVPN files from UCP and inspected the config file. I noticed that for some reason it has the automatically created DDNS address above my server’s static IP in that file. I don’t know why DDNS was configured automatically and even though I had it disabled in System Admin the address was still placed in the OpenVPN config file. I don’t know when that all happened because as soon as I purchased System Admin Pro I enabled OpenVPN and downloaded the files from UCP and that DDNS address was not present in that config file. Tomorrow I’ll post the details of my setup, but for now it’s working and I’m way too tired to go through everything right now.

I don’t think it was the DDNS. Mine is still set to off. There is a deployment number in the DDNS info box that was put there during installation.

I am using Endpoint Manager for the Sangoma phones as it’s required (but free for Sangoma phones). In the Endpoint Manager template I have the SIP Destination address set to external with a FQDN listed. We had tried using an IP but were having no success. We went to a FQDN as part of our efforts to get it to work. I don’t know if that’s actually needed as that wasn’t what allowed it to work but with over 100 hours invested in trying to get a Sangoma phone to register with a Sangoma appliance I wasn’t about to start undoing things to figure out what finally made it work. Of course I dread trying to do it again because I’m not sure what we finally stumbled over to make it work.

Provisioning Protocal is HTTPS (I think it’s important that this matches what you show in the Portal IP/FQDN protocol).