I have been recently testing the commercial EPM module ahead of rolling out a bunch of new phones to be installed in another state and country.
I have to say, its not been a smooth introduction, some useful tips would be helpful, its been 2 days of work with mixed success.
My setup comprises an (FPB14 and ASTX13). I have the commercial module and am testing with the Yealink T21PE2. The system is cloud hosted with the phone running openvpn. I am not using the redirect service offered by Yealink as yet, instead I am manually entering the provisioning server (hard provisioning) on the phone. At this point, I am using http (84) but will upgrade to https (1443) once it all works fine. The firewall is temporarily fully open both ways between the two endpoint IPs.
First of all, the phone works fine when configured manually through the phone web gui (including openvpn). The vpn config files are downloaded from the UCP and arranged as required by yealink.
When I go to test an end to end implementation, partial success. After a factory reset of the phone, the phone will semi-provision, ie. all the settings and line/account is correct but openvpn is not working. It looks like the client VPN files were not correctly loaded into the phone. If I then upload the vpn config file manually, it works fine…
Besides a rooking mistake :[ , if I was to guess the issue, the client vpn config files are not properly constructed. The symptoms are similar if you stuff this up manually…
Any suggestions or a pointer as to which specific logs might be useful?
OK, I think I worked it out.
I entered the provisioning address correctly in the phone, which included the http prefix and the port suffix (http://xxx.xxx.xxx.xxx:84). The userid-password were separate input boxes.
After the provisioning step, the provisioning address was updated by the server to: http://password:[email protected]://xxx.xxx.xxx.xxx:84
Essentially, it was picking up the external IP from the EPM Global Settings. In this box I had also used the http:// prefix. As a consequence, after the phone was provisioned we ended up with a ‘broken’ provisioning server address with two http references. I removed the http from the server and all is good, so far anyway.
It looks like the VPN was a red herring. My guess is that vpn files may be downloaded in a second step, after the ip address is updated…
Well, we continue to make slow but solid progress. I am getting through the idiosyncrasies of the system, a few notes while I remember.
I was getting a lot hit and miss provisioning and the inconsistencies were clearly showing it worked sometimes but need to have the right work flow. A couple of tips so far:
- Start at the bottom and finish at the top, updating config at each step. Base File > Phone Model Config (In Template) > Template > Extension Mapping.
- Update the phone after Extension Mapping is configured.
- If you have multiple lines and using VPN (not sure about no VPN), update the config from the main line, (Line 1 for me). It wont update from line 2,3 etc.
- If you delete Line 2,3… etc on Extension mapping, dont forget to reconfigure the display in the Phone Config (In template). ie. if you leave Line 2, 3 etc displayed and you delete the extension map, the display remains. It therefore looks like the line is still active per the display and did not get removed, it obviously wont work as nothing behind it.
Hope that helps someone.
Another update. Finally managed to get https autoprovisioning to work. HTTP was straight forward but took forever to get HTTPS working.
In summary, certain yealink phones’ firmware have a problem with letsencrypt. It appears to be specific only to FPBX14 according to the forums. From my research, you can do one of the following:
- Purchase a cert and install manually (eg comodo).
- Use cerbot and generate letsencrypt certs yourself, instead of the system GUI approach.
- Try a different version of the firmware that does not have this problem.
In my case the firmware choices available on EPM were quite old and I had no success. I uploaded the latest firmware from yealink as a ‘custom firmware’. Renamed the firmware file to match the same name for the same phone (as per the other slot).
After that, all good.
Does anyone know how to check whether the other lines (2,3,4) will also use the VPN tunnel for line 1?
I am using Yealink phones and I noticed that Line 1 has the openvpn subnet address listed in the phone and on extensions mapper page. Its also shown as connected by the vpn server.
For Line 2 etc, its a bit more weird. If the Line ext has VPN created, no IP will be displayed on the ext mapper page, weather you bother to use it or not. If you do use it, it does not show as connected by the vpn server. Also, the phone shows the public ip as the server address and not the VPN gateway address (as per Line 1).
If VPN is not created for a user, then you obviously cant adopt/use it. In this circumstance, the external IP address will be displayed on the ext mapper page.
None of this answers my concern that I cant determine whether traffic for line 2 etc is encrypted or not…Anyone please?
Since this is a commercial module, you might be able to get a better response from Sangoma.
I don’t know if this is on point but you should take a look at this post on the yealink forums
Yealink introduced an auto provision parameter on the T23G firmware to set an account to either use the VPN or local network. It was my understanding that previously, if one account was set to use VPN, all traffic would go through the VPN.
A user wanted one line for a local PBX and another line for VPN and reported using these parameters worked for him.
Thanks for responding, it got me thinking and I did some more scenario testing.
I put the phone on a network that was totally locked down, except for port 1194. Line 1 worked fine but line 2 would not register. I tried to use VPN for line 2, no luck. I then went into the phone and changed the server address for line 2 from the external server IP to the 10.8.0.1 gateway. This worked! BTW, using the external server address in an open network works fine, ie. line 2 can register.
In summary, it looks like if you point the line 2 to the main external IP, its outside the VPN but if you point it to 10.8.0.1, it will be directed via the VPN.
This can be hard-coded in the base file:
PJSIP allows for multiple endpoints with the same ext, its a nice feature which I enjoy.
However, the VPN config file only allows 1 connection. Besides the poor security practice, any objections adding duplicate-cn to the server config file?
And yes, it works nicely although its not listed as a connected device in the openvpn section of sysadmin.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.