Solved Yealink Phones Won't Provision Behind SBC

[TagleRock]

We have a 3CX PBX hosted by 3CX with an SBC setup onsite. The SBC is successfully joined to the PBX. Its a small office, with only about 8 phones and they are all T46G. When I go into phones -> PNP phones they show up but when I assign one to the extension nothing happens after a reboot, it just stays at factory defaults. If I follow the manual provisioning method and select the SBC that doesn't work either. What I have found is that if I don't follow those instructions and instead of selecting the SBC I do this:

1. Select local phone
2. Select the interface with fqdn on it
3. Manually assign Label, Display Name, Username, Password, etc...

Then it works and it provisions. This will only work of course if block non-tunnel connections is disabled.

Is Yealink T46G not supported via the SBC? If so this would mean that having multiple phones is going to be an issue I would imagine since the SBC doens't seem to be being used.

I forwarded 5090 TCP and UDP and 5001 to the SBC.

 

[TagleRock]

UPDATE: So if under the account settings I specify the SBC as the SIP server it registers. Could be a potential work around, but provisioning still doesn't work. None of the timezone or any other settings are getting pushed out.

In other words, if i go onto the extension and add the phone manually and tell it to use the SBC onsite and then go onto the phone and manually configure the settings for the account (auth id, password, etc...) and specify the SBC IP as the SIP server it will register.

 

[TagleRock]

Think I may have figure it out, firmware on the phone was just barely out of date and I think 3CX was wordlessly just ignoring it. Is there a place to see logs for this kind of thing in the future? An event of "{MAC} provisioning was rejected, FW out of date" or something would be great.

 

[SteveITS]

For a router phone, 3CX will detect the failed connection and block the IP.

Times change, but in the past I haven't had problems connecting older firmware as a normal phone behind an SBC or router phone. Then upgrade it through 3CX. But 3CX's position is going to be to upgrade firmware first. (here for other readers) However I don't know offhand if I've worked with that model.

 

[SteveITS]

I forwarded 5090 TCP and UDP and 5001 to the SBC.

SBCs should not have any ports forwarded to them from the Internet.

 

[JohnS_3CX]

Think I may have figure it out, firmware on the phone was just barely out of date and I think 3CX was wordlessly just ignoring it.

There is no such thing as "barely out of date firmware". These are decade, old end-of-life phones, discontinued 4 years ago from Yealink, and you were still 2 years out of date with your updates.

You then assumed that 3CX was rejecting them when the real issue is that the firmware you had was incapable of even communicating with any modern HTTPS servers, not just 3CX V20.

Read this to learn why your End-Of-Life phones would not provision https://www.3cx.com/blog/news/yealink-firmware-release/

An event of "{MAC} provisioning was rejected, FW out of date" or something would be great.

There is no such log event to show because the phone cannot even reach 3CX in the first place, let alone report its firmware version. HTTPS connections to download provisioning are impossible with the old firmware.

What you should do instead is ensure that you always have the latest firmware before you attempt provisioning anything: https://www.3cx.com/docs/phone-firmwares/

Keep in mind we spend a good deal of time discussing with Yealink to give this one last firmware upgrade, 2 years after they were already discontinued because these were very popular models with 3CX customers. If that hadn't happened, provisioning would have been entirely out of the question and you would have to do everything by hand or buy new phones.

So now please go and
- undo all the port forwards you added on the SBC to maintain your network security
- re-enable the "block remote connections" setting to increase the extension security
- delete the phones you added using the incorrect method and factory reset them

Once you install the correct firmware, you may assign them via PnP and within a few minutes they will be able to securely connect to 3CX. But please keep in mind that it's extremely unlikely they will have any more updates, so plan ahead and start replacing them with T4_U or T4_W series phones

 

[alex761414]

Same problem for us for a few days/weeks with all our T46G even though the installation has been functional since 2015...
All T46Gs have been with the latest firmware for a few months.
And problem still present in V20 U3.
We are using Digicert SSL certificates and after analyzing the logs on the 3CX and Yealink sides some time ago, I noticed that Provisioning requests do not even arrive at the 3CX server. By examining the Yealink logs, I also noticed that it was an unrecognized certificate problem (probably because of the old age of the firmware now...).

Two possibilities for our:
Either disable certificate verification on each phone in the Security tab and deactivate the option, which corresponds to "static.security.trust_certificates=0"
The problem, with the default 3CX template, it comes back activated each time it is reprovisioned.
I think you either need to create a custom template or the ideal would be for 3CX to deactivate the default option since this is not going to get better over time....

Otherwise, and this is the solution we used, you must import the trusted certificate from your provider (in our case is Digicert Intermediat crt) still in the Security tab.
The advantage of this solution is that the certificate persists despite reprovisioning.
On the other hand, in the event of a factory reset, it disappears and you have to start again on each phone...

 

[JohnS_3CX]

Otherwise, and this is the solution we used, you must import the trusted certificate from your provider (in our case is Digicert Intermediat crt) still in the Security tab.

Hi Alex, this is an entirely different case, and you will face the same problem even on a new Yealink because phones do not ship from the factory with all the certificates in the world.

You use custom certs, so you need to ensure you pick ones that your phones support by default. You also need to include your own intermediate certs on the server since you went down the custom path, we cannot blame the phone or the latest firmware here. Disabling SSL checks in the phone is also a bad idea overall.

Paste your FQDN with port here and find out why you have this problem https://www.sslshopper.com/ssl-checker.html

Enter it like my example: pbx.mycompany.com:5001

Consider changing to certs that Yealink supports out of the box, or better yet use a 3CX FQDN which guarantees compatibility.

 

[alex761414]

Hi Alex, this is an entirely different case, and you will face the same problem even on a new Yealink because phones do not ship from the factory with all the certificates in the world.

You use custom certs, so you need to ensure you pick ones that your phones support by default. You also need to include your own intermediate certs on the server since you went down the custom path, we cannot blame the phone or the latest firmware here. Disabling SSL checks in the phone is also a bad idea overall.

Paste your FQDN with port here and find out why you have this problem https://www.sslshopper.com/ssl-checker.html

Enter it like my example: pbx.mycompany.com:5001

Consider changing to certs that Yealink supports out of the box, or better yet use a 3CX FQDN which guarantees compatibility.

Hi
when I blame the firmware, it is in the sense that the cert in place has been the same supplier for several years (Digicert) and the problem only happened a few days/weeks ago (last renew of the cert ago almost 1 year). So I immediately after check the log thought that the Digicert root cert (and maybe others?) of the Yealink would have expired. On Yealink website V83 to V85 all cert from Digicert is supported (and in my case : DigiCert Global Root G2 is compatible cf Yealink website)

There are no errors on SSLchecker. Moreover, on nginx or apache there is no even need to insert the root cert for the certificate to be recognized. This is a reputable certificate provider...

So perhaps too quick a shortcut to the problem but quite strange...

But otherwise yes the FQDN 3cx solution seems to be the simplest.

NB : Sorry for my English if there are spelling mistakes

 

[JohnS_3CX]

There are no errors on SSLchecker.

I'm doubting that because you said you put the intermediate on the phones.

The intermediate should go on the server, not the phones.

Are you sure you checked the PBX FQDN there of perhaps your checked your main domain?

 

[alex761414]

No I checked FQDN of PBX 3cx with port 5001.
On phones, we only just loaded the intermediate cert a few days ago because it has only been working for a few days/weeks. Previously, we had no problem provisioning our T46Gs.

Whether we add the ssl_trusted_certificate on Nginx or not on the 3CX side does not change the problem of provisioning T46G and the SSL error message that we have only had for a few days.

Moreover, the DigiCert Global Root G2 certificate of authority is clearly indicated as compatible with V83 on the Yealink website.

For our part, we no longer have any problem by manually injecting the certificate of authority which is valid until 2027 now. After this date, we will have to load the new root cert again if we still have our T46G
I bounced back on this message in case the author might have the same problem but that doesn't seem to be the case based on your feedback. So sorry not to be able to intervene further on this resolution.

 

[alex761414]

Hi
Do not take my comments into account because after discussions with John and after another try with the intermediate certificate option on Nginx, we have just realized that it works well!

In any case, if it can help other people in this case and avoid spending hours searching or manually entering phones....

Thanks JohnS for your help!

 

[JohnS_3CX]

Ok so as we said originally this is a separate issue from the OP:

Case 1 was missing ciphers on the phone due to outdated firmware
Case 2 was missing certs on a custom FQDN server

We do recommend that you use a 3CX FQDN when possible as this means the phones are tested to work with the certs we generate, and the renewal is also fully automated saving you time as well as money spent on custom certs. Glad to hear its all sorted now!

 

[TagleRock]

There is no such thing as "barely out of date firmware". These are decade, old end-of-life phones, discontinued 4 years ago from Yealink, and you were still 2 years out of date with your updates.

You then assumed that 3CX was rejecting them when the real issue is that the firmware you had was incapable of even communicating with any modern HTTPS servers, not just 3CX V20.

Read this to learn why your End-Of-Life phones would not provision https://www.3cx.com/blog/news/yealink-firmware-release/


There is no such log event to show because the phone cannot even reach 3CX in the first place, let alone report its firmware version. HTTPS connections to download provisioning are impossible with the old firmware.

What you should do instead is ensure that you always have the latest firmware before you attempt provisioning anything: https://www.3cx.com/docs/phone-firmwares/

Keep in mind we spend a good deal of time discussing with Yealink to give this one last firmware upgrade, 2 years after they were already discontinued because these were very popular models with 3CX customers. If that hadn't happened, provisioning would have been entirely out of the question and you would have to do everything by hand or buy new phones.

So now please go and
- undo all the port forwards you added on the SBC to maintain your network security
- re-enable the "block remote connections" setting to increase the extension security
- delete the phones you added using the incorrect method and factory reset them

Once you install the correct firmware, you may assign them via PnP and within a few minutes they will be able to securely connect to 3CX. But please keep in mind that it's extremely unlikely they will have any more updates, so plan ahead and start replacing them with T4_U or T4_W series phones

There are some issues that I would like to point out with your reply here, however I don't wish to debate or argue in a public forum. My issue has been resolved, I will leave it at that.

I will say this though as a friendly remark, declaring what I did is in and of itself an assumption. It is advisable to stay away from those and use facts, or conclusions drawn from them, my statements are based on data I gathered in my troubleshooting.

Thank you for the reply, my customer is happy, and so am I!