Yealinks randomly unregistering

[BEAR1410]

Have a newer install of phones that talk to PBX over VPN, with no latency issues. QoS setup on switching that phones are behind an all software and firmware up to date on firewall/switches (all Meraki).

Most of the time phones check in and everything is fine. But several times a day, random phones will simply unregister, and we have to go to phone UI and toggle registration to use TCP; it then registers. Later, it can be moved back to UDP and it also works. All very random.

Took a pcap from the PBX when this happens and the phone sends repeated Request: REGISTER attempts and within the header shows 'Unrecognized SIP header (mac)' followed by the PBX response Status: 407 Proxy Authentication Required. So I frantically go to the multiple phones UI, swap to TCP, and it gets a 200 OK response from PBX.

Tried researching this without any success so here I am.

Thanks for any direction.

 

[Charles_3CX]

I take it that this is not for the 3CX SMB since you have a VPN. In any case, this issue is because your VPN is likely blocking UDP traffic for port 5060. Check the network traffic and ensure that packets are not dropped for either end of the connection.

 

[Guillaume Bourgeois]

Hello,

I've experienced the same with Fortinet routers.
We have the solution : On Fortinet, the solution is called a "Blackhole Route" with a higher distance than the route for the VPN.

It's a well-known phenomenon for Fortinet ;
Warning : this is an external link to 3CX.
Fortinet : Technical Tip: Use of Black hole route in site to site IPsec VPN scenarios

On Meraki, it doesn't have a "specific" name, but an equivalent can be achieved.

Add a "static route to null" or "null route" with a higher distance for VPN traffic. This configuration directs traffic to a "null interface", a pseudo-interface that acts as a black hole for network traffic. By setting up a static route with a null destination (for example, specifying a next hop IP address that is unused or reserved for this purpose), all traffic matching this route will be discarded and not forwarded.

So, if for some reason UDP traffic no longer goes through the main route (VPN), it would be routed to be discarded, the aim being to force the phone to initiate a new session with a new source port.

This needs to be done on both routers, for outgoing traffic (to VPN interface), a second route to direct packets to « null » (Drop).

Consult Meraki support for further assistance.