Dream Team: Starlink Dishy & Big Network

The entire networking industry is going through a cycle of rapid innovation to develop and deploy a new breed of access technologies coming in the form of 5G mobile and satellite-based internet services. These technologies are enabling for consumers a new wave of high-speed connectivity previously never seen before. One of these technologies is SpaceX’s Starlink Internet Service, a satellite internet service that is easy to deploy across much of the United States and Canada.

I was lucky to get access to the Starlink Beta program and received my Dishy McFlatface in January. I’ve been aggressively testing the platform and product to learn about how it works and the benefits it can provide to consumers. My general reviews are all positive. The product is easy to unpack, install, connect, and get running. The speeds it can deliver are impressive; I’ve seen average throughput of 200 Mbps download and 20 Mbps upload connecting to various Speedtest servers.

One critical drawback of Starlink is that the service places its user terminals behind a large-scale carrier grade NAT (CG-NAT), which means that users don’t get a publicly routable WAN IPv4 address. WAN IPv4 addresses come from a shared address space defined by RFC6598 (100.64.0.0/10), which are meant for shared infrastructure within a service provider’s network and are simply not world routable. Given the global shortage and cost of IPv4 address resources, it makes sense that SpaceX would implement the network in such a way.

For a user, however, this means that there is no way to make an inbound connection from the internet to a service running behind a Starlink dish. In prior days, I would use a concoction of dynamic DNS, port forwarding, and DHCP reservations to enable remote access to services. In this case, it is simply impossible.

Fortunately, due to advanced in networking technology, I have a few options to turn to:

• Use cloud-based applications and services to make outbound connections from behind the Starlink Dishy to a series of cloud services, consistent with the expected user behavior of Starlink (e.g. web browsing). The upside is, this approach is well-known today. Thermostats, cameras, etc. all do this. The downside is, this limits my options for services I can run, which in my case, is important to me.
• Deploy a tunneling technology, such as IPSec or VPN, to make outbound connections from behind the Starlink to a remote concentrator hosted somewhere with a static IP or dynamic DNS-enabled WAN IP. Honestly, I didn’t want to take on the hassle of setting up more infrastructure to test this out.
• Look for an alternative, such as Big Network, which would enable peer-to-peer discovery of remote network resources.

Sorry to lead the witness, but as you can imagine, I picked the last option. Using Big Network, I configured a Cloud Network, installed the macOS and Linux clients as needed, and joined devices to a private, secure, encrypted network numbered in RFC1918 address space 10.200.0.0/24. I chose this option because it required no central concentrator to be set up, was completely peer to peer, and fully secured.

Moreover, this provides me full Layer 2 and Layer 3 access into my network behind Dishy. That means native SSH to the environment, access to cameras, and the ability to extend by home NAS file sharing easily. It happened without a static WAN IPv4 address, dynamic DNS, port forwarding, or DHCP reservations, AND with CG-NAT in the path! I changed nothing about my network to make it happen — on either side, local or remote!

When you use Big Network for remote access, you change nothing about your existing network. And that, friends, makes Starlink Dishy and Big Network a dream team!