Solved Yealink T4XG/S Will Not Provision STUN

[theMightyMacBoy]

As the title says, I am having issues getting our Yealink T42G and T46S phones to provision via STUN.

Specs:
Windows 10
3CX 16.0.622
T42G Firmware 29.83.0.130 Stock Template
Firewall Sophos UTM SG
Valid HTTPS cert on 3CX Web Services

We have all of the required firewall ports open and DNAT properly. To confirm they are:

TCP 443
TCP/UDP 5060
TCP/UDP 5090
TCP 5061
UDP 9000-10999

Then we have a SNAT rule that translates all outbound traffic on the dedicated IP for 3CX.

Phone work via STUN when outside the network for calls but when they boot up or you force a configuration upgrade they do not update. If I navigate to the provisioning URL for the handset (https://3cx.company.com/provisioning/provstring/macaddress.cfg) on my laptop from an external network my browser will download the configuration file for the phone. I checked my live logs on my firewall and i see the following on our firewall

20:31:09 NAT rule #25 TCP MyHouseWAN : 50123 → 3CXWANIP : 443 [SYN] len=52 ttl=57 tos=0x00 srcmac=bc:26:c7:4f:7f:80 dstmac=00:1a:8c:f0:81:2c

20:31:09 NAT rule #25 TCP MyHouseWAN : 50124 → 3CXWANIP : 443 [SYN] len=52 ttl=57 tos=0x00 srcmac=bc:26:c7:4f:7f:80 dstmac=00:1a:8c:f0:81:2c

20:31:09 Default DROP TCP MyHouseWAN : 50123 → 3CXWANIP : 443 [RST] len=40 ttl=57 tos=0x00 srcmac=bc:26:c7:4f:7f:80 dstmac=00:1a:8c:f0:81:2c

So there is SYN packets coming from the desk phone to the 3CX WAN IP on the firewall, which is getting translated to the local IP of the PBX. There are two SYN packets followed by a RST packet and that is it.

I have looked inside the provisioning file that is downloaded from the PBX via web browser and auto_provision.server.url is set as follows:

auto_provision.server.url = https://3cx.company.com/provisioning/provstring

Will note that the same behavior happens on my home network, work test internet circuit, call center reps homes, etc. Not just isolated to my home.

Does anyone have any ideas?

 

[cobaltit]

Valid HTTPS cert on 3CX Web Services

Does this mean you did something silly like use your own FQDN? Valid is a relative term. Just because your laptop likes it doesn't mean the Yealink phones will like it. Browsers generally have more root certificates that devices. You'd want to check that your certificate is one that Yealink will trust.

Another possibility could the PCI compliance setting although I think TLS1.2 was supported since v81

And speaking of firmware you may want to follow the guide as you are not on a supported firmware version for the T46S:

https://www.3cx.com/sip-phones/yealink-t4-series/

 

[theMightyMacBoy]

Does this mean you did something silly like use your own FQDN? Valid is a relative term. Just because your laptop likes it doesn't mean the Yealink phones will like it. Browsers generally have more root certificates that devices. You'd want to check that your certificate is one that Yealink will trust.

It's an SSL cert from GoDaddy, which is listed in Yealinks Trusted CAs list. http://support.yealink.com/faq/faqInfo?id=691

And speaking of firmware you may want to follow the guide as you are not on a supported firmware version for the T46S:

https://www.3cx.com/sip-phones/yealink-t4-series/

As for this, I only have the T42G at home to do testing, but I just confirmed that my desk phone at work is running 66.85.0.5, which is greater than 66.84.0.35 that is listed in the docs you mention.


I guess I will go the avenue of trying to create a custom template for testing and see if I can ignore SSL certs and some of the other TLS compatibility issues just to see if I can isolate out what the issue is.

Edit - found a T46S in a box at the house and going to do some testing. Seems like it's on old firmware, will upgrade and do some testing and report back.

 

[theMightyMacBoy]

Ok -- verdict is out. It comes down to Yealink's laziness. GoDaddy's Root CA is in the Yealink Firmware, but the intermediate certificate is not.

I found this post: https://www.3cx.com/community/threa...46s-dont-work-with-15-5-sp6.59445/post-254652

Within this Thread @JParo mentioned that he had to add GoDaddy's intermediate certificate into his root certificate, per DigitCert's instructions. Once I did that, everything worked like a charm.

Another way I was able to point to the cert being an issue was I disabled cert checking and it allowed the phone to get the new config, but it caused some weird issue where the phone couldn't register with our 3CX... Really weird, but I guess secure.

In the end, GoDaddy cert needs the intermediate cert added to the bottom of the cert file and then all is well.

Thanks for chiming in and pointing me in the right direction.

 

[ltctech]

Intermediate certificates are not really optional for many embedded devices. Always use OpenSSL to verify that the complete chain is being sent by a server:

HTTPS:

openssl s_client -showcerts -connect 3cx.contoso.com:443

SIPS:

openssl s_client -showcerts -connect 3cx.contoso.com:5061

What's really annoying is that Sectigo (former Comodo) is not trusted by Yealink as of May 30, 2020 due to the old AddTrust root expiring. Yealink has not updated the firmware with the new Sectigo root nor do they trust the AAA cross signing root.

I really wish 3CX would support automatic Let's Encrypt cert issuance for custom domains. Certs have to be renewed annually as of September 1, 2020 (thanks to Apple) so it'd be one less thing to forget. 3CX could easily use ACME HTTP-01 challenge, no need for DNS.

 

[cobaltit]

As for this, I only have the T42G at home to do testing, but I just confirmed that my desk phone at work is running 66.85.0.5, which is greater than 66.84.0.35 that is listed in the docs you mention.

If the phone at work is the 46S then on v85.0.5 then that is the current firmware. If you re-read the doc the link to the firmware shows that version. The 66.84.0.35 is the intermediate version you would upgrade to if you were below that version due to another Yealink issue preventing upgrades from lower version directly to v85. But sounds like you got it sorted out.

 

[JohnS_3CX]

If you take the custom FQDN route you might come across these issues, but one thing I can recommend for these situations is to run a capture on the phone or PBX and look for SSL handshake errors to help you track it down

Glad to hear it was resolved in the end