4G LTE Network Extender intermittently disconnects from Verizon network

[lbo12]

I bought a 4G LTE Network Extender on 4/1/2021 and have had intermittent problems. It works just fine with 3 different phones (including an iPhone 12) when the Extender is connected to Verizon's network. However, the Extender disconnects from the Verizon network several times a day. I can't discern a pattern and I don't know why it happens or how to fix it.

I contacted Verizon tech support. The rep's suggestions weren't helpful so I escalated it and got a ticket number. I promptly received a response from Verizon that they couldn't find anything wrong so they closed the ticket. But wait, it's an intermittent problem, and OF COURSE, there's no problem to be found when the Extender is connected to Verizon's network. It seems they didn't look at the Alarm History (which I asked them to do). I will paste the Alarm History for 4/12/2021 as an example. That's the same day Verizon said everything's just fine.

Intermittent problems are the worst. Can anyone suggest a fix? Thanks!

Here's the Alarm History for 4/12/2021:

1	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 22:11:44 MDT
2	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 22:11:16 MDT
3	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 21:43:42 MDT
4	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 21:43:14 MDT
5	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 20:40:26 MDT
6	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 19:24:17 MDT
7	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 19:23:42 MDT
8	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 18:45:04 MDT
9	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 18:44:01 MDT
10	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 18:09:14 MDT
11	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 16:51:56 MDT
12	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 16:47:09 MDT
13	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 16:34:29 MDT
14	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 16:34:03 MDT
15	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 15:36:23 MDT
16	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 14:13:16 MDT
17	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 14:12:21 MDT
18	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 13:32:41 MDT
19	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 13:32:23 MDT
20	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 12:58:27 MDT
21	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 12:58:07 MDT
22	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 03:09:18 MDT
23	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 03:08:13 MDT
24	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 02:58:28 MDT
25	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 02:57:31 MDT
26	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 01:56:48 MDT
27	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 01:55:43 MDT
28	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 00:48:51 MDT
29	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 00:47:45 MDT
30	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 00:39:09 MDT
31	SCTP link failure	[Cleared]  SCTP HB failed over criteria	04-12-2021 00:13:54 MDT
32	IPSec down	[Cleared]  This alarm is an indication of un-successful IP Sec tunnel set up with the SeGW (Security Gateway), due to failing DPD, etc.	04-12-2021 00:13:31 MDT

[cfogri1]

Seems one of the 6 active Verizon servers is having problems with a high failure rate on pings while the other 5 are at 100% success.  Almost like everybody is connecting to the one server and overloading it.

Ping status

[cfogri1]

Last capture is too small...let's try this one

[vzw_customer_support]

cfogri1, our goal is to work toward a resolution to ensure that you have a great experience. We can attempt general troubleshooting through this platform and escalate the issue to our network team on an individual basis if the issues persist. Please check your Private Messages for assistance. 

[cfogri1]

Thanks for the offer to help again but your level of Tech. support have not been able to fix this issue for me and many others, who have posted in this blog for months, about random disconnects.  The issue with  Error 32/ SCTP link failures has finally been escalated by Leadership to The Network Dept. 

Thanks

[pichael]

solution is to block the red ip addresses that cfogri1 put together. thanks man.

[kayakboy000000]

I am not seeing where the IP addresses that are failing 100% correlate to any of the addresses in this list:

https://www.verizon.com/support/knowledge-base-25525/

Has anyone confirmed blocking IPs is a fix?

As of now, VZW sent me a new extender running GA4.30 - V0.4.030.310 and am NOT seeing any issues.  My previous extender was running GA4.36.

I *hope* the new extender remains on GA4.30 until this is sorted out.  I am about 4 days in with no errors.

Side note, on my previous extender running GA4.36, I would see the Error32 events between 11am and 7pm mountain time....daily.  There were few, if any, fails outside of that time window.

good progress by others!  thank you!

[vzw_customer_support]

One of our main concerns is to provide you with reliable service and great experience. We are concerned to learn you are experiencing issues. Please respond to our Private Note, so we can further assist you.

[cfogri1]

I am still getting disconnects, all ports open, and i tested Verizon servers with test pings. Testing the Verizon servers shows that there is a huge delay on ping turnarounds with all the "NEW" servers that I reported earlier in this post. Verizon should have a network person view the error logs on these servers and view all the servers they are using for Extender Network boxes. One of the servers shows a major failure rate with a high ping failures, of the 6 servers online only the 1st few of the servers are being used and the 1st one seems with the highest failure rates and has the highest amount of traffic. Again, looks like the turnaround delays are what is causing the Error 32 which reflects a "SCTP link failure". When this error occurs the Extenders are dropping offline and dropping our calls/connections to the Verizon network and then about 5 minutes after a disconnect the Extender will connect back up, and clears the error... below is another log of these errors from my log....

A VERIZON HIGH LEVEL NETWORK TECH. NEEDS TO VIEW THE ERRORS THESE VERIZON SERVERS AND THE REPORTED POSTINGS HERE IN THIS BLOG. 

[vzw_customer_support]

We would love to be of assistance to you. Please send us a Private Note. *Cecile

[cv59hm]

I have the same issue, i get an error code 32 every day and have to power cycle my extender to get it to work again. I moved into an area that only gives me 1 bar. Verzon provided me the extender. I get 900+Mbps down and 40+Mbps up, my computers are all hard-wired like the extender is, I work from home and use a VPN daily, no VPN disconnects or other internet issues.

my extender sits on a window sill.

i tried setting my router to the ports in the instruction manual, it shut down my entire wifi service but ethernet service was unaffected.

i pay almost $300/month for my verizon service. i was a loyal ATT customer for 10+ years before i switched to tmobile because of the military discount but their service just dropped to **** as everyone was trying for the 5G race, leaving 4G to the crapper. I was happy with my verizon service until i loved into an area with poor signal with only 1 cell tower several miles away used by houses and business with a buttload of trees inbetween.

[iuzhrtuba]

I've been having this issue now for several weeks. Several bars indicate service from extender but our iPhone XR's will not connect. STCP link failure and IP Sec down are the alarms that show up daily. Satellite strength is strong from GPS and our internet is working and super fast. Very frustrating. 

[vzw_customer_support]

iuzhrtuba, we always want you to stay connected, so we're here to help! Have you been able to unplug your router for a few minutes, plug it back in, turn off the network extender for few minutes & then turn it back on to test services? About how far away do you have the network extender from where you're using your device? AliciaD_VZW

[cfogri1]

Update, All good news!

OK, I was just able to get to a Leadership support at level 2 at Verizon, on the phone today. He reviewed this blog, and took down all the information I had debugged so far related to Error 32 and SCTP failures alarms, and he agreed that a ticket needed to be started and sent to the NETWORK TEAM! , so lets hold tight while they catch up on this issue....

I am sure they will address this issue...

[sileasresearch]

cfogri1 - looking at your ping screenshots, I'm a bit confused - you have 140.xxx.xxx.xx IPs in your tests, but the link to the Verizon IP addresses you posted all have 141.xxx.xxx.xxx IPs.

Can you clarify the discrepancy?

Given what you were seeing (bad load balance? Not using randomization in the extenders against the IP pool?), I was thinking of sinkholing some of the overloaded IPs with my router so that my extender would (hopeful) move off right away to other IPs in the list.

Once I understand the 140 vs 141 thing, I will start trying this.

[sileasresearch]

Another thread on this, someone saying they had a fix - VZW deleting their extender from system, then re-adding.

https://community.verizon.com/t5/Network-Extender/SCTP-link-failure-happening-multiple-times/td-p/12...

[cfogri1]

Had a typo in the ip list -- so fixed it and here are the results sorted by Maximum ping time.

The Average is highly correlated with the Maximum so the max values are not just freaks.

Seems like all the servers should have approximately equal average values but they don't.  If the SCTP software is configured with a timeout of around 300ms or so and just 2 or 3 retries you'll end up getting random timeouts.  Also have the traceroute below which shows a notably slower link to the worst node as opposed to the best node in this list...a different route is happening presumably on a failover over backup link.

Tracing route to 225.sub-141-207-212.myvzw.com [141.207.212.225]
over a maximum of 30 hops:

3 463 ms 32 ms 25 ms cpe-174-111-096-112.triad.res.rr.com [174.111.96.112]
4 16 ms 18 ms 17 ms cpe-024-074-250-192.carolina.res.rr.com [24.74.250.192]
5 31 ms 24 ms 30 ms ge-5-1-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.26]
6 26 ms 32 ms 24 ms 66.109.6.224
7 30 ms 26 ms 29 ms 209-18-43-59.dfw10.tbone.rr.com [209.18.43.59]
8 26 ms 26 ms 28 ms &#10.11.148.204.in-addr.arpa [204.148.11.85]
9 * * * Request timed out.
10 92 ms 91 ms 95 ms 100.sub-69-83-144.myvzw.com [69.83.144.100]
11 101 ms 95 ms 95 ms 185.sub-69-82-65.myvzw.com [69.82.65.185]
12 * * * Request timed out.
13 * * * Request timed out.
14 102 ms 118 ms 109 ms 225.sub-141-207-212.myvzw.com [141.207.212.225]

Trace complete.

C:\Users\ERIC\Desktop\pinginfoview>tracert 141.207.151.235

Tracing route to 235.sub-141-207-151.myvzw.com [141.207.151.235]
over a maximum of 30 hops:

3 105 ms 32 ms 169 ms cpe-174-111-096-114.triad.res.rr.com [174.111.96.114]
4 21 ms 24 ms 27 ms cpe-024-074-250-194.carolina.res.rr.com [24.74.250.194]
5 20 ms 23 ms 15 ms 24.93.67.204
6 188 ms 17 ms 18 ms 66.109.7.196
7 27 ms 163 ms 55 ms 66.109.9.103
8 20 ms 20 ms 18 ms &#10.241.179.152.in-addr.arpa [152.179.241.97]
9 * * * Request timed out.
10 18 ms 31 ms 48 ms 91.sub-69-83-36.myvzw.com [69.83.36.91]
11 31 ms 23 ms 31 ms 91.sub-69-83-36.myvzw.com [69.83.36.91]
12 * * * Request timed out.
13 * * * Request timed out.
14 39 ms 39 ms 40 ms 235.sub-141-207-151.myvzw.com [141.207.151.235]

[iuzhrtuba]

Yes I have completed that process. No change, no service. Sitting next to the extender with my device.

[vzw_customer_support]

cv59hm, we are sorry to hear about your experience. Making sure your Network Extender is working correctly is important. Allow us the opportunity to take a closer look at the details. We have sent you a Private Message. Can you please respond to that message? Thank you. 

  -Sylvia

[cv59hm]

by the time i got the link, it already expired.

my net extender disconnects all the time, then comes back online with no changes made on my end. i even used the GPS extension cable and i get a better signal strength and more satellites, but i still get disconnected about 100 times a day (100 is an over statement, but its down as much as the time its up)

[vzw_customer_support]

cv59hm,

I'm terribly sorry you've been dealing with this for so long. That's the last thing we want. I appreciate you trying that but it certainly shouldn't continue giving you this issue for so long. Let's try that again and see if we can get access.

By connecting with us, you grant us permission to review your services so we can offer you the best value. Refusing to authenticate will not impact your current services. It is your right and our duty to protect your account information. For quality, we may monitor and review this conversation. Please note, the link we provide has a timed expiration, so we encourage you to continue as soon as possible.

Authenticate and continue here:http://spr.ly/6002yc61k

-Andrew

[vzw_customer_support]

Thank you for meeting me here in this Secure Chat. Please bear with me for a few minutes while I access and review your account details. -David