Speedfusion using Priority 2 connection when Priority 1 is healthy

Product Discussion SpeedFusion Connect
1

Hello,

I have unexpected behavior happening after setting up a tunnel that has a public IP on both sides of the tunnel.

This may be working as designed, but it is working unexpectedly for what I’m trying to do.

I currently have a fully meshed topology configured using a BR2 in a mobile unit, a Balance 20 in MA, a B One in AZ and FusionHub Solo

The only devices in question are between the BR2 and B One and tests have been done on 8.5.2 5862 and 8.5.3b02 6005 with the same result

On the BR2 I have Starlink providing the public IP in Priority 1 on the BR2 and Priority 2 in the tunnel. (Note, I really want Starlink in P2 for everything, but there are other issues that go along with this, so it must be in priority 1 for now)

On the B One, I have a Verizon Cellular connection with the public IP, similarly in P1 on the B One but in P2 in the tunnel.

On both devices I want any connection not providing the public IP to be used for the bulk of data. I only want the public IP connections to keep the tunnel up and make all other WANS available to the tunnel.

Actual behavior
When I tunnel to my B One from my BR2, Starlink is the connection being used even though it is P2 in the tunnel. The UI shows it yellow and in the current scenario my WiFi WAN 5g is green and the primary connection, yet it isn’t being used.

Is this the expected behavior since Starlink is providing the public IP even though I have it set to P2 in the tunnel, or is it expected that that Wifi 5g be handling the bulk of the data?

Thank you,
Keith

2

Can you add screenshots of the priority on the dashboard.
The priority on the tunnel config
and the status of both wans of the speedfusion status page?

3

If you could include the “show remote connections” and Show IP and port.

Status → Speedfusion VPN

Click on the “>” for the VPN in question and then select “show remote connections”
Show IP and port Do this for both sides.

I think you will then see the asymmetric traffic flows, and that the routing engine sends the traffic back along the original tunnel.

Only public IP’s can be SF VPN destinations, so the SF configuration is more restricted than you think when you have CGNAT on the other WAN.