Random FusionHub Disconnects 8.1.1

Product Discussion
1

Hi,

FusionHub Solo on 8.1.1
Transit-Duo Max LTE-A Pro on 8.1.1

Today we had again a Tunnel disconnect. On the TransitDuo the WAN and LTE1 was used, and had no online issues. I only see theses logs in the TransitDuo:

|Feb 25 09:51:07|SpeedFusion: FusionHubVM (FusionHubVM, sn:11D4-BE54-XXXX) connected to MEB-FH (2 - JustBonding)|
|---|---|
|Feb 25 09:51:04|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:03|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:02|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:02|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:59|SpeedFusion: FusionHubVM (FusionHubVM, sn:11D4-BE54-XXXX) connected to MEB-FH (1 - Smooth+FEC)|
|Feb 25 09:50:44|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:43|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:42|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:41|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:36|SpeedFusion: FusionHubVM (FusionHubVM, sn:11D4-BE54-XXXX) disconnected from MEB-FH (2 - JustBonding) (default tunnel to this remote peer is disconnected)|
|Feb 25 09:50:36|SpeedFusion: FusionHubVM (FusionHubVM, sn:11D4-BE54-XXXX) disconnected from MEB-FH (1 - Smooth+FEC) (link failure detected)|
|Feb 24 15:54:19|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 24 15:54:19|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 24 15:54:18|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 24 15:54:18|SpeedFusion: Initiated TLSv1.3 connection to x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|

And on the FusionHub Side:

|Feb 25 09:51:08|SpeedFusion: TransitDuo-1 (TransitDuo-1, sn:2938-FC6E-XXXX) connected to TransitDuo1 (2 - JustSpeed)|
|---|---|
|Feb 25 09:51:06|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:04|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:04|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:03|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:51:00|SpeedFusion: TransitDuo-1 (TransitDuo-1, sn:2938-FC6E-XXXX) connected to TransitDuo1 (1 - Smoothing+FEC)|
|Feb 25 09:50:45|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:44|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:43|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:43|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 25 09:50:36|SpeedFusion: TransitDuo-1 (TransitDuo-1, sn:2938-FC6E-XXXX) disconnected from TransitDuo1 (2 - JustSpeed) (default tunnel to this remote peer is disconnected)|
|Feb 25 09:50:36|SpeedFusion: TransitDuo-1 (TransitDuo-1, sn:2938-FC6E-XXXX) disconnected from TransitDuo1 (1 - Smoothing+FEC) (link failure detected)|
|Feb 24 15:54:20|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|
|Feb 24 15:54:19|SpeedFusion: Accepted TLSv1.3 connection from x.x.x.x using cipher suite TLS_AES_256_GCM_SHA384|

We upgraded form 8.1.0 a while ago.

So, how can we debug this whats actually happening here?

Thx!

Best regards, Martin

2

This is caused by the connection issue between MAX Transit and FusionHub. Please provide screenshot below from MAX Transit:

  • Dashboard > Details of WAN and Cellular > Health Check Settings.
  • Advanced > SpeedFusion > PepVPN Settings
4

Thx… here are the settings:

----------------- Transit Duo Side -------------------

WAN:

image
image782×276 7.5 KB

Cellular:

image
image787×190 4.94 KB

PepVPN Settings:

image
image835×192 8.78 KB

image
image784×871 40 KB

image
image810×892 41.8 KB

------------- FusionHub Side --------------

PepVPN Settings:

image
image837×209 9.84 KB

image
image793×739 30 KB

image
image814×795 30.9 KB

5

It worked better with 8.1.0, also the Connection time to establish the tunnel now takes sometimes 2 mins or so… but please see the screenshots provided above. Thank you very much!

6

The health check target between WANs and SpeedFusion tunnel is different. Based on your WAN health check settings, both WANs will declare as down when they continuously lost contact with the health check target in 25 seconds. However, the SpeedFusion tunnel will declare as down when it lost contact with the remote SpeedFusion peer in 2 seconds. I would say the heath check for the SpeedFusion tunnel is too sensitive.

Suggestion

SpeedFusion tunnel

  • Set it back to " Recommeded".

WAN health check setting (both WANs)

  • Timeout = 5 second
  • Health Check Interval = 5 seconds
  • Health Check Retries = 3
    Recovery Retries = 3

You may set FusionHub’s public IP as the health check target. By having this setting, you will know the SpeedFusion tunnel down is due to the WAN lost contact with FusionHub. If the WAN lost contact with the FuionHub very frequent, please complain to the carrier as this is WAN link stability issue.

7

Thx for the feedback, we set now the SpeedFusion Healthcheck to “recommended” on both sides. But i cannot use the FusionHubs IP as the check target, because we also use the FusionCloud as the Fallback solution. In that case the Router would not switch over because it would think that the Internetconnection is down.