New ISP - Yealink phones losing connectivity

[mikkydoos]

Hi all,

 

I'm reaching out to see if anyone has had an issue I have that is driving me literally insane....

 

I changed our ISP to a managed connection over the summer.  They installed a managed router that performs the leased line and backup line failover.

This is connected to a Smoothwall appliance doing filtering and firewall - Port 1 - I configured the external port, configured the LLB pool and clients connected.

 

So far so good until the next day our Yealink phone handsets went offline and wouldn't come back up (T465 model mostly).

I switched over to the old connection and the phones immediately connected.

Reconnected the new connection again,  next day... no service.

They connect to Xelion cloud hosted SIP. Been running for a year without fail.

 

Took one of the handsets to another site, the phone connected, took it back to the original site and it connected... until the next day when it lost connection again.

Our SIP provider has told me that the handsets need to register to Xelion every 24 hours. This occurs at 1:00am.

 

 

I assumed this was firewall and the handsets couldn't get out or packets back into register.

The only firewall log entry I found, querying a phone handset IP address, was rejected packets from 18.169.38.9 - This is apps.xelion.com - however this was fine with the old ISP, so unlikely.

 

 

Smoothwall suggested that the ISP router was performing NAT, as well as Smoothwall's NAT, thereby double NAT'ing .. e.g. packets didn't have Smoothwall's originating IP because it was NATed by the ISP, therefore was rejecting the packets... OK, I get that.

 

Smoothwall insisted that double NATing is bad (which it is) and recommended the ISP remove the NATing.

The ISP configured a different router port, disabled NAT and said to configure Smoothwall to take the backup connection direct to perform the failover.

This lost the ISP's visibility to the backup line and I no longer have a fully managed service.

 

ISP = port 2, backup line port 3 on Smoothwall.

 

Next day... no phones.

 

 

The ISP turned off SIP ALG, so did Smoothwall and the phones connected and stayed connected.

 

Smoothwall configured ports for the main connection and the backup line and the failover is performed by an LLB rule.

E.g. The leased line is connected from a non NATed port at the ISP end, then into Smoothwall port 2.  Back up line is direct into Smoothwall port 3.

 

Next day..  no phones.

 

 

I reconnected the NATed connection on Smoothwall port 1.. phones connected.

 

This got the phones back.

 

 

 

However, this is where things are weird and neither party can find a solution.

 

I'm in a situation where I have to have two external connections, one is NAT'd, one isn't.

 

Smoothwall tell me that only SIP traffic, specifically port 5060 traffic  is going in and out on port 1.

All other traffic is going out via the LLB adapter.

 

They're saying they can only do a proper analysis when the phones are in a failed state...  NOT happening in term time.

 

 

After hours and hours and hours talking to Smoothwall 3rd line and the ISP,  I still don't have a solution.

 

There's no firewalling blocking traffic,  all required ports and protocols are configured.

No double NAT'ing, no SIP helpers, 

 

 

I'm convinced that this is Smoothwall hence the SIP traffic only routing through port 1... according to them it is.

 

 

I've changed ISPs in Smoothwall set ups many many times, but never had a problem like this.

 

 

 

 

Has anyone had anything like this that could shed some light on this.

 

 

 

Cheers in advance  🤔🤔🤔

[ZeroHour]

Out of interest does the new isp and SIP provider support IPv6?

[mikkydoos]

@ZeroHour 

 

Yes I think so.

[ZeroHour]

It may be worth a try enabling it for the phones to use and see if that helps.

Did the new ISP use CGNAT?

Is it possible try a softphone with details like MicroSIP and see if you can get any extra logs/details from it if it drops?

[mikkydoos]

I haven't yet tested whether softphones connect or not.  I need to do that in downtime....   er  time.

 

CGNAT... no idea.  Its Wave9.  They will have this setup in many many schools with Smoothwall.

 

I do have a media converter they have loaned to me... this will remove the ISP router completely.

 

If I still get the same issue then the finger gets pointed squarely at Smoothwall.

Edited October 6, 2025 by mikkydoos

[jthompson]

Can't quite follow all the details in your original post, but we recently switched to Smoothwall and had some intermittent issues with calls not connecting to certain phone handsets. It felt like certain Yealink models were more affected than others.

 

Our solution was to add our VOIP service provider's IP range into "Smoothwall > Guardian > Web Filter > Exceptions > Manage source exceptions". This was because Smoothwall's HTTPS inspection was occasionally breaking stuff, and including the phones' IP addresses in that list wasn't sufficient.

 

I don't know if that helps at all.

[jthompson]

Further to my post, here is a list of IPs used by Yealink handsets for provisioning, etc. regardless (I think) of which VOIP provider you're using them with. IIRC we have the IPs listed here for "Redirection provisioning service" included in our Smoothwall HTTPS inspection exception list.

 

https://support.yealink.com/en/portal/knowledge/show?id=6476e6806a27da76bd06a8d2 (the breadcrumbs in that page will link to IPs used in regions other than Europe).

 

Again, I don't know if that helps but it might give you some more stuff to try.

[mikkydoos]

That's helpful... thanks @jthompson

[mikkydoos]

41 minutes ago, jthompson said:

Can't quite follow all the details in your original post, but we recently switched to Smoothwall and had some intermittent issues with calls not connecting to certain phone handsets. It felt like certain Yealink models were more affected than others.

 

Our solution was to add our VOIP service provider's IP range into "Smoothwall > Guardian > Web Filter > Exceptions > Manage source exceptions". This was because Smoothwall's HTTPS inspection was occasionally breaking stuff, and including the phones' IP addresses in that list wasn't sufficient.

 

I don't know if that helps at all.

When you say your VOIP providers IP range...  are these the IP's they would have sent to configure your firewall ?  or your LAN IP addresses ?

[jthompson]

18 minutes ago, mikkydoos said:

When you say your VOIP providers IP range...  are these the IP's they would have sent to configure your firewall ?  or your LAN IP addresses ?

The former. For reference, we use Yealink handsets with a service hosted by Telavox, so after referring to their firewall support article (https://support.telavox.com/en_US/network/firewall-and-network) we added into our Smoothwall exceptions list 80.83.208.0/20 (i.e. the telavox network) and the two IPs listed there for Yealink. We did also add in the LAN IP addresses of our phones. I don't know if that's needed (probably?) but certainly just the LAN IPs wasn't sufficient to solve our problem.

[SchoolsBroadband]

Try send voip out of one connection only rather than by and kind of load balancing.

 

Id suggest you have phones on their own vlan too so its easy for the smoothwall box to identify them and create a policy for them.

 

You could try so that via either connection too to further test where the issue is.

 

Dave

[mikkydoos]

On 07/10/2025 at 11:34, jthompson said:

The former. For reference, we use Yealink handsets with a service hosted by Telavox, so after referring to their firewall support article (https://support.telavox.com/en_US/network/firewall-and-network) we added into our Smoothwall exceptions list 80.83.208.0/20 (i.e. the telavox network) and the two IPs listed there for Yealink. We did also add in the LAN IP addresses of our phones. I don't know if that's needed (probably?) but certainly just the LAN IPs wasn't sufficient to solve our problem.

 

Thank for the info @jthompson .  I assume the exceptions you refer to are HTTPS (dont inspect) exceptions  ?..   I'd set with a Location in Smoothwall.

[mikkydoos]

Think I got to the bottom of this one. This post hopefully will help someone in the future.

 

It seems that this was the issue... its worked so far....

 

 

So I had three external interfaces configured on SW:

 

eth 2 - New ISP

eth 3 -  Backup connection

eth 4 - Old ISP (disconnected - cable pulled)

 

(LLB pool is set to eth2 and eth3 in failover)

 

 

Smoothwall have built an eth interfaces table they call Conntrack.

I've been told this hasn't been updated in years and was developed by SW to record interface information - this might be a bit like a MAC address table ?

 

Basically, VOIP and handset registration traffic was being routed through eth 2 that I'd reconfigured the IP address and gateway on.

 

194.x.x.x  was changed to 62.x.x.x

 

Smoothwall did a TCP dump and packet capture of the traffic from a failed Yealink handset.

 

The Conntrack table does/did not update the interface information correctly when I changed the IP and gateway, hence this traffic (and only this traffic for some weird reason) was being told to route through interface 2 to 194.x.x.x and the old gateway when in fact interface 2 had been reconfigured with 62.x.x.x, hence the traffic wasn't going anywhere.

 

 

Outbound traffic when in a fault state:    >>>     13:10:39.944124  IP   194.168.x.x.2723  >   18.169.38.9.5060: UDP,  length 618

 

This is after the interface had been reconfigured with 62.x.x.x.x

 

 

 

Changing the LLB pool did force the traffic via eth 2 & 3 but the Conntrack table still held the wrong IP and gateway data.

 

 

 

Support flushed the table and bingo. The phones stay registered, and all the traffic is now routing via eth 2 to 62.x.x.x

 

 

 

Moral of the story is... any change to interfaces, internal or external, require a reboot of the box to flush the Conntrack table to ensure the old interface records are removed. Simply deleting the IP/gateway and/or changing the interface from external to internal doesn't update the table.

 

 

SW say they will raise this internally.

 

 

3 months and my nervous system this has taken to resolve!!!

 

 

********

 

 

 

 

 

Edited November 6, 2025 by mikkydoos