Registration Issue with VPN connected Yealink phones

[nfletcher2]

So we have ran into an issue that I am stumped on and am hoping for some help.

We have several customers that have 3CX phone systems. 3CX versions ranging from 12 to the 15.5. Several of our customers have remote sites. They are connected via VPN with Mikrotiks and routed. All traffic between sites is allowed and unfiltered. The phones at the sites (typically Yealink T42G or T42S) pull their configuration information from DHCP and point to the 3CX server at the main locations.

This works well 90% of the time. On multiple occasions we have had the remote site phones lose registration. There will be a log on 3CX of the phone just unregistered and then you can log into the web interface for the phone and it will show registration failed. We have tried rebooting phones, network equipment, etc...

The only way we have found to get the phones to re-register is to change the SIP server transport from UDP 5060 to TCP 5060. As soon as we do this the phone will register.

This only occurs on the remote sites over the VPNs. We can factory reset the phones and they will pull the correct information but fail to register.

Thoughts?

 

[eddv123]

As advised in this guide you must setup the routing between gateways correctly (if used): https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

The“remote” phone is seen as just another local user in a different network. The routing in this case is made by the router/gateway. This becomes a LAN to LAN connection over the internet.

What was the reason you wanted to use VPN and not SBC ? these devices are supported with 3CX for SBC deployments.

 

[Saqqara]

Do you see any vpn timeouts / lose of link when the phones lose registration.

 

[nfletcher2]

As advised in this guide you must setup the routing between gateways correctly (if used): https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

The“remote” phone is seen as just another local user in a different network. The routing in this case is made by the router/gateway. This becomes a LAN to LAN connection over the internet.

What was the reason you wanted to use VPN and not SBC ? these devices are supported with 3CX for SBC deployments.

Everything is routed correctly. The VoIP phones are just a small part of what these remote sites rely on for connectivity. There is full communication and I can even scan and see the correct ports open on the phone server from the remote site. I can access the web portal of the phones persistently from the phone server and vice versa.

What benefit would the SBC provide when you have full connectivity? Doesn't SBC require something to be installed and running at the remote site? The problem is most of these sites that I have seen this behavior (3 now) do not have servers or devices that are persistently on.

 

[nfletcher2]

Do you see any vpn timeouts / lose of link when the phones lose registration.

Not while troubleshooting. We can run pings and see persistent traffic successfully across. That is not to say the VPN doesn't drop for a second before we see the phones fail to register. But when we begin troubleshooting, and trying to get the phone to register, the VPN is up and consistent. We have monitors on the VPNs with pretty tight notification limits and we never receive notices that the VPN is down.

 

[nfletcher2]

Anyone?

 

[andrewm30]

For what it's worth, I've had similar issues with FreePBX and sonicwalls.

Remote sites would become unregistered, and changing the routing metric on the firewall resolves the issue. Sounds like a similar issue - I'd lean toward it being the firewall.

 

[Andy Oberlin]

Looks like Mikrotik doesn’t treat SIP to well.
https://forum.mikrotik.com/viewtopic.php?t=35196
My guess would be you have a hung SIP connection not being cleared. You could run a packet capture from 3CX and search for the IP of the phone when you reboot it and see if you see any 5060 UDP but my guess would be you will not. When you switch it to TCP it creates a whole new connection and works.

On that post there are people complaining about this less than 2 months ago. There is a bandaid for you with creating a script.