Solved Unable to provision Yealink Phone when connected with PTP VPN

[deka]

Hello,
We are testing some different scenarios. Currently we two networks connected together via a PTP tunnel e.g. 10.0.0.x <> 10.0.1.x and we have a V15 version of 3CX PBX running on a VLan segment 10.0.50.x (parent network = 10.0.0.x) We created a new tunnel route for 10.0.50.x to 10.0.1.x so as to communicate with teh PBX VLAN on the remote network. We are able to ping the ip address of the PBX server from 10.0.1.x segment and vice versa.

However, we can not manually provision a Yealink T23G with current firmware using the local provision method. When we review the firewall logs we see communication on both ends over port 5000. Specifically we see from 10.0.1.x (ip address of phone) to 10.0.50.x (ip address of PBX server) on the 10.0.1.x subnet and from 10.0.50.x(ip address of PBX) to 10.0.1.x on the 10.0.50.x subnet. However, the phone does not register. (have also tried unchecking trusted certs only just in case)

We have successfully registered the phone using Direct STUN and using an SBC at the remote site. However, we can not use the local provisioning method. We have even tried setting the interface to the fqdn in the management console when provisioning locally with no luck.

More info:
using a 3cx fqdn
Watchguard firewalls at both locations (firewall checker passes)
Can browse 10.0.71.x network from 10.0.1.x network and vice versa with no issues
have used wireshark to see traffic when trying to provision phone (no traffic seems to hit the ip of the pbx eventhough the firewall log shows that traffic is being allowed to the pbx ip on port 5000??

Any ideas?

 

[cobaltit]

Yes. So certificates aren't an issue as you are using 5000 which is the HTTP port. Firewall checker is irrelevant since firewall checker checks the firewall between 3CX and the outside world which is not your scenario. So lets focus on the things that matter.

First, are the phones not provisioning or not registering? There is a difference. Provisioning is the act of pulling the config from 3CX via HTTP or HTTPS and getting the configuration information on the phones. Registering is the act of those phones using that information and connecting successfully to the PBX. They use different ports and protocols so it's important to understand which one is/isn't working. You said you can't do both although its unclear if you manually input settings in the phone to test the registration.

Once you are clear on those let's test the basics. Can you access the PBX via HTTP from the segment the phones are on? If not, then the phones won't be able to either. Fix that and you will fix your provisioning problem. That will most likely fix your registration problem as well.

VoIP is 90% networking. 3CX doesn't care how your network is designed or how the traffic gets there. The network stack handles all of that. 3CX only cares about the traffic once it hits the PBX so if you aren't seeing failed registration attempts in the log and you can't hit the web interface of the PBX from where ever your phones are it's a network problem and not a 3CX problem. There are many 3CX partners out there that *should* be able to help with this.

 

[deka]

Thank you for the reply. I believe it to be a network problem of some type. (As you mention.) The management interface via a web browser on the remote side is NOT accessible. However, traffic does show as allowed on each firewall. This is where I confused. I will continue tio work on it. Thank you for the feedback. And yes entered url manually into phones trying to test. It does not provision.

 

[deka]

I should clarify the management interface is not accessible using the IP of the PBX via a web browser on the remote site. However, The FQDN does work. (provisioning still does not work even if setting to local and changing the interface to FQDN) And I do mean provisioning NOT phone registration.

 

[deka]

After a little more testing. It seems like this has something to do with using a 3cx FQDN and not a custom one. If we use a custom domain it works without issue. Can it be that using the IP address and the local IP not being secure by a root CA have something to do with this? Or, could it be the VLAN and how the PTP tunnel is routing traffic across to and from the PBX side VLAN. What is perplexing is that the routers show the allowed traffic which looks correct.

 

[Saqqara]

If you manually add the T23G phone to the extension within 3CX , on the remote network can you access the cfg file within a browser using the provisioning link

For example

http://x.x.x.x:5000/provisioning/randomcharacters/macaddress.cfg

https://x.x.x.x:5001/provisioning/randomcharacters/macaddress.cfg
https://fqdn:5001/provisioning/randomcharacters/macaddress.cfg ​

On the remote lan does the FQDN resolve to the 3CX server address

Have you upgraded the firmware to the latest version ?

On the remote lan, have you setup DHCP boot option - https://www.3cx.com/sip-phones/dhcp-option-66/ . Does the phone appear in the 3CX console, after a factory reset

Have you checked your blacklist, to see if the IP has been blocked

This doc may help
https://www.3cx.com/sip-phones/yealink-t20p-t22p-t26p-t28p/

 

[deka]

Thank you for the reply. The provisioning url can NOT be accessed from the remote lan using the local IP. The FQDN resolves on the local lan as well as the remote lan. Accessing https://fqdn:5001/provisioning/randomcharacters/macaddress.cfg does work however an error is returned that says Can'y Connect Securly to this page. This might be because the site uses outdated or unsafe TLS security. Firmware is the latest firmware. Option 66 has been set but phone does not show in console. Expicitly set public facing ip of remote site to allow. It is not on Black List.

The TLS issue was just related to a browser setting. The fqdn concatenated with the mac address works. The ip with the mac address does not.

 

[cobaltit]

So if the FQDN works (and you aren't doing split DNS) then that means you have something restricting HTTP access from your phones to 3CX over the VPN. FQDN is resolving to the public IP of your 3CX instance which has the necessary firewall/port forwarding settings and is working but we already knew that because you had phones working via STUN and SBC. So you'll need to revisit your firewall/router config and figure out why traffic isn't passing correctly over your tunnel.

 

[deka]

Thank you for the reply. That is what we are trying to do. It makes no sense that the firewall shows allowed traffic to and from the PBX but nothing ever seems to get to it when using local ip.

 

[deka]

This issue has been resolved. As suspected and as cobaltit pointed out it had to be a networking issue. What made it complicated was the firewalls all showed allowed traffic. I turned on all logging features and tried to provision phones, ping pbx etc.. from the remote LAN. Reviewed logs in detail. Turns out there was an incorrect static NAT that put traffic from localip > public ip. This made the firewall think it was receiving traffic on the Public facing ip (per the NAT) instead of the trusted interface through the tunnel. Removed the incorrect NAT and all is working as it should. Thank you to everyone who helped.

 

[cobaltit]

Glad you figured it out.