I have a Balance One (v8.5.4), currently with three WANs connected via Ethernet:
• T-Mobile SIM in an original carrier device
• T-Mobile SIM in a BR1 Mini 5G (v8.5.4)
• AT&T hotspot
All indications are that all three links are robust: They always show green-connected in the Balance UI. The BR1 Mini 5G always shows green “Connected to T-Mobile 5G” with 5 bars signal strength. I can send non-SF Connect traffic on all three links simultaneously with good reliability and throughput.
BUT, one or more of the WANs often show “Not Available - Link Failure No Data Received” in the Balance’s SpeedFusion VPM - Remote Peer" status display. It’s usually the BR1 Mini 5G link, which is especially concerning. But sometimes it is one of the others, and occasionally two of the three links are shown as “Not Available - Link Failure No Data Received”.
I’ve searched this issue, but I don’t see clear indications of what the real problem is, or clear solutions. I have tried:
• changing outgoing ports for SF Connect
• reducing the number of SF Connect locations from three to two
• disabling, then re-enabling, the offending link
• rebooting the hotspot device of the offending link, and / or rebooting the Balance
None of those are guaranteed to fix the issue. As a result, usually the BR1 Mini 5G is NOT being used by SF Connect.
It seems to me that the link detection within SF Connect is prone to mis-diagnose, and very poor at recovery. It defeats the purpose of SF Connect if I can’t use the available WANs, especially when only one WAN is properly recognized as operational.
When I saw this kind of message, about "not available - link failure "… I do a reset of the LTE modem and after get another ip address for the sim card on it… it is show conected at SF HUB and at SFC.
This kind of situation… I believe is some ISSUE between sim card provider and the internet bpg/ospf/route to final ip destination.
even, when the sim card get public ip address, this kind situation happened, few times.
Thank you. Worth a try, but does not help in my case. Resetting the cellular modem does result in a new IP address, but the device still isn’t recognized as good for SF Connect.
This issue is intermittent, but pretty persistent once it kicks in. Very odd though that two SIMs from the same carrier have such different rates of this occurring. At least 80% of the time, it’s the BR1 Mini 5G that can’t be used by SF Connect. I invested quite a bit in that device and the Antenna Max less than a year ago. It works fine for normal traffic, but only occasionally works for SF Connect.
My WAN config has evolved since the original post, but the behavior continues, even with a new B One router and 8.6.0. The attachment image actually looks relatively good compared to most times. Usually, the “TMUS” WAN (BR1 Mini 5G) is not available on any of the SpeedFusion Connect links, and almost always even when it is available on SFC 2 and 3, it is still not available on SFC 1 (Chicago). All of these links work fine directly, with good response and good bandwidth.
the “VZ” WAN (USB) is usually pretty good, “ATT” drops off one or more SFC occasionally, TMUS and the Wi-Fi WAN drop off the most, sometimes on one SFC, often on multiple or all.
The intermittentness, and the fact that one or two SFC might be fine, but another isn’t, leads me to think that there is some firmware issue or issue at the SFC hub location, probably among other factors. Why would a given WAN be fine on one SFC peer but not another?
Possible, but quite honstly I’d be quite surprised, especially if it is some persistent recurring issue like this, but it is simple enough to see if you can ping the IP of the SFC endpoints though from each WAN to prove end to end connectivity.
It’s the same system used for SpeedFusion when you terminate the tunnels on your own hub or other Peplink devices and generally works fine, ultimatley if it cannot build the VPN tunnel via that path then there is little else it can do - this is not a WAN health check failure, it is the VPN not establishing on a given path, which could be related to end to end connectivity, it could also be a carrier messing with your traffic in some novel fashion, or poor luck with hitting some badly behaved NAT gateway in the carriers network, but given you are persistently seeing this across multiple providers suggests there is something more subtle at play here I’d think.
Some sanity checks:
Are there any event logs you have across the devices that can be correlated, for example the Br1 Mini and Balance One are they in Ic2, do any of the WAN/LAN event logs line up with the loss of or interruptions in SFC working across that path?
Does the BR1 Mini have SFC configured on it out of interest and you’re not accidentally sending traffic via a tunnel, or is the BR1 Mini basically factory defaults?
Are there any weird overlaps or conflicts between the subnets being advertised from the various WANs and what is configured on the LAN side of the Balance One?
I would almost say to ditch SFC for the moment and build a FusionHub Solo in a cheap public cloud so you can get more logs and debugs from the hub or see if the issue persists.
Nothing indicating any issue. Nothing unexpected in the BR1 Mini 5G event logs. I’m not on IC2.
I can ping the IP addresses indicated in the message above (“Initiated TLSv1.3 connection to… {IP address}”) from any WAN, though ping is unsuccessful from anywhere to the exit IP addresses of SFC.
The BR1 Mini 5G is pretty default. And there are no subnet overlaps or conflicts.
It may well be oddities within the carrier networks, worse with some than others. It could help explain why the Chicago SFC misbehaves more than the others with certain WANs.
This is my home router. I’ll have to look into FusionHub Solo to see if it’s something I could do. My “solution” so far is to add WANs so that I hopefully always have at least two working on any SFC most or all of the time. VZ almost always works, but unfortunately it’s the most limited of the WANs (lowest monthly cap).
Might be worth seeing if there is a modem firmware update available, probably doesn’t explain the issues but worht a go as they are often released to address specific “compatiability” with specific carriers.
You can check this by going to the support interface, log into your devices and change the path of the URL to be:
Not clear what protocol or route this uses, but WAN Connection Status = 4 bars, Connected, , and 5G, and I’m still able to download at over 100Mbps on this link. All normal usage indications are that the link is always working fine.
Also, perhaps worth noting that I can see the three SFC sessions in the sessions list on the BR1 Mini 5G, but all three on the main router show “Not Available - Link Failure No Data Received” on the SpeedFusion VPN - Remote Peer status page. So the BR1 Mini 5G is not being used at the moment for any active SFC.
You can see that, this morning, “TMUS” has dropped off of all SFCs, and “Wi-Fi WAN on 5 GHz” (ATT) is still/again dropped off of the Chicago SFC:
, and 5G, and I’m still able to download at over 100Mbps on this link. All normal usage indications are that the link is always working fine.