SpeedFusion with WiFi WAN (Starlink) and WISP

Hi folks, I’m starting from scratch but would really love to build a ‘Starlink recipe’ of hardware/software/services that I can purchase to achieve the objective of minimizing or eliminating impacted Zoom calls and remote VDI sessions while I’m working (currently average 3+ micro outages in every zoom call with zero obstructions).

What I’ve got:

  • Starlink dish handing off 1G Ethernet, 30+ interruptions per day of 20+ seconds.
  • 15Mbps/850kbps DSL connection handing off 100M Ethernet, 3-4 interruptions per day of 60+ seconds
  • Sophos firewall with 4 Ethernet ports

Today I’m just doing gateway failover with the firewall which only helps avoid prolonged outages.

What I’m hoping to do is build something that will duplicate Zoom streams or have <2 second failover for Zoom calls and everything else just go to Starlink.

What would I need to get hardware/service wise to enable this? Looks like a Balance 20 would work, is there anything else?

What about the headend? Is that Speedstream Cloud?

Might be worth you while to use the status page to view ports/IP’s in use during a call.

The Balance20 will top out at 150Mbits… And the Spec sheet says that the SpeedFusion on a B20 won’t do bonding, or smoothing. My Starlink currently peaks in the 300Mbit range.
The Balance20X with a USB Ethernet Adapter would work and leave headroom.

SpeedFusion Cloud would be the internet endpoint of the bonded sessions. It does make Zoom and other protocols immune to the network drops. If you need to VPN back into your private network, or provide services behind the CGNAT then you would host your own SpeedFusion HUB.

With 1 server you could also look at speedify… but I think that needs multiple NIC cards on your workstation.

Thanks Paul, I think that’s exactly what I needed. I did try Speedify but for some reason kept getting little drops and glitches in the voice, so I want to try something that was hardwired and built for purpose.

I appreciate the help!

Hi Paul, can you help with this?

I keep getting this error when I connect to the Dashboard

Failed to receive DNS response from the health-check DNS servers for WAN. But public DNS server lookup test via the WAN passed. So please check the DNS server settings.

I used the health check settings you suggested - what am I missing?

Thanks

Maybe try ping instead? This seems to work for me.

For very specific reasons I don’t check DNS servers (AT&T wireless specific issues).
(many ISPs intercept DNS queries)
So I would use ping, or manually specify 8.8.8.8 and 1.1.1.1 or similar DNS server.

2 Likes

thanks I will start doing that!

I thought this graph was pretty neat. Starlink has had a rough couple days, but, because of SFC my Zoom meeting never so much as stuttered. You can clearly see Starlink dropping 4 times in this time period and ATT LTE picks up the slack. :star_struck: Good stuff.

I, for one, could not work from home solely with Starlink. It’s just not there yet.

6 Likes

Spot on - one of the unwritten rules of the internet IMO - Your ISP sucks at DNS, no matter how big they are.

I’ve seen too many “outages” caused by ISP DNS misbehaving.

2 Likes

I’m having issues with Zoom not getting routed to SFC. Even with a rule for “zoom.us” this doesn’t seem to be working.

any thoughts?

routing by domain name only works when the reverse lookup matches that domain name. Most cloud services don’t have matching reverse DNS entries.

Based on your screenshot, you might be able to use Destination Port and UDP to route this particular traffic. Change the protocol to UDP and the “Port” options should appear - use “Single Port” and 8801, change the destination address to ANY. 50/50 shot that it moves it over when you apply the config. You should be able to disconnect/reconnect the tunnel to force traffic to use the new rule immediately (because of the terminate session on link recovery option).

1 Like

Thanks for that. I was hoping it was less “trial and error” since surely others are using Zoom over SFC. Will certainly try.

I can assure you that domain outbound policies have nothing to do with in-addr (reverse) lookups. Or it would never work.

The logical process of how this works, is that A record queries via the router (required for domain lookup) are processed and end in a set of A records.

Like this:

www.zoom.us. IN CNAME zoom.us.
zoom.us. 59 IN A 3.235.71.136

The peplink router would then put in its outbound IP table:

traffic from All → 3.235.71.136 goes via SpeedFusion#1

Alas, it won’t keep it there forever, it will have a default timeout… what one?.. perhaps the 59 seconds of the TTL of the A record… perhaps 5 mins… perhaps longer, but eventually a cleanup process will say “remove that temporary entry”.

This also works even if the service is handled via a CDN provider.

www.amazon.com. 453 IN CNAME tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com. 45 IN CNAME d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net. 45 IN A 13.225.224.25

Hey, who knew they use cloudfront? but your outbound policty for amazon.com has now added an entry for 13.225.224.25. No need to know they went via cloudfront.

Many things can interfere with domain outbound rules, and peplink does not tell us how the rules are actually implemented and give us any access to the caching table.

First,
I would take a wireshark trace and view all of the DNS queries. It is possible that zoom can reach out to properties not in the zoom.us domain.
Second, it might have been quite a time between the last time that zoom.us had a DNS query. and you requested another zoom session. This is entirely up to the client app, and there is no requirement to ever request another DNS entry.

I would quit and restart zoom and see if a fresh session always triggers the rule (it just did on my system) Then you would know that there is probably a lifetime to the domain policy rule, and that the zoom app can exceed that.

Now, that port# does seem pretty zoom specific… but again, you will need to test it.

Something must have changed since the last time I asked this specific question

The way you describe it as working is how I imagined it should work - especially since the Balance is a DNS caching server (the way I have mine configured). Perhaps some of the Peplink gear does work that way now. I haven’t tried DNS based outbound policies for quite some time.

Now that I know that Cisco Anyconnect will work over Starlink, I am curious if I go to Speedfusion Cloud if Anyconnect will be able to create a tunnel over the SFC tunnel.

I have sites with users using CISCO Anyconnect over SpeedFusion VPN to a self hosted FusionHub. I haven’t tried that with SFC though.

2 Likes

I use CiscoAnyconnect over SpeedfusionVPN + Self Hosted Fusionhub (in AWS). Works great.

Starlink + Tmobile + (campsite Wifi sometimes).

Now, if I could just give some hints to SpeedFusion to try a little harder to use the Starlink for most of its data. The latency changes/packet blips cause the weighted bonding to lean a little to heavy into the Cellular connection… :-/.