I was recently invited to join the closed beta for SpaceX Starlink satellite internet. Over the coming months, I plan to document what I learn, the good, the bad, and the ugly. I will also be posting videos when appropriate on my personal youtube channel. For full disclosure, I am not receiving any compensation for this, but I am an employee of VMware, will be using VMware products where relevant, I will do my best to remain agnostic where possible.
In order to appropriately test this solution, three variables are highly critical.
- Download speed – How fast can you retrieve things from the internet, important for streaming television and music.
- Upload speed – How fast can you send things out over the internet, particularly important for online gaming and video calls.
- Latency – How long does it take traffic to make a round trip from you to your virtual destination and return, critical for voice, video, gaming, basically anything you want to do on the modern internet.
To set up the appropriate test environment I needed an isolated test network that would not impact my current production internet where my family works and plays, but also to be able to access that network securely to review the results. I also needed historical data on the performance as outlined above.
For the remote access, I initially set up port forwarding on my own personal router which I used to bypass the wifi-router that came with the Starlink beta. After testing, and contacting support, it was determined this is on the roadmap but not currently available. I then tried using publicly available cloud-based services for remote connectivity. This was acceptable, but much too slow, mostly due to issues on the Starlink side. I finally settled on leveraging my home wireguard VPN server and a wireguard client on a Linux server running on the Starlink network, effectively bridging the two networks with significant security restrictions, similar to the picture below.
The procedure to install and configure both the server and clients for wireguard can be found at https://www.wireguard.com/. I personally run the Linux Server Wireguard Docker image for my server.
In order to access the test network, I leave the VPN on the Starlink Test Linux Server always connected. I can then VPN into the local VPN server on the production network and then access the VPN interface of the Test Linux Server where I am running my graphing. When I have more time I will add the static routes to my firewall but for now this seems to work well.
Performance monitoring over time was a particular challenge. My original thought was to leverage one of the speedtest CLI scripts, output to a CSV file, and use Python to display that in a website. After some research though and several failed tests, I discovered https://github.com/frdmn/docker-speedtest-grafana. This is far from a perfect solution, I have had it simply stop responding several times, forcing me to restart the docker containers, but for what I need, this is a perfect and simple solution. I deployed, and testing continues, but here are some raw outputs of the script running every 1 min for the past several hours.
As you can see, the latency does have some fairly big spikes, and the speed is pretty variable. I anticipate the speeds to increase latency to decrease as more satellites are launched, which appears to be happening quarterly or more often. I have noticed regular drops every hour or two for 1-3 min, I believe this is due to handoff between satellites, and I believe it will be resolved in the next few launches.
I will write up more of the testing, and post more videos as I find new and interesting things to show, but for now, this is a solid beta product. Some of my upcoming tests will include introducing software-defined WAN products to see if it helps with latency/jitter on the connection, and bonding connections to see if a slow but stable connection can help to smooth out some of the outages.
I firmly believe this is the future of connectivity and can make the world a better place by connecting more people and allowing those living in areas with less internet access to become more self-sufficient. The opportunities are there it is up to each of us to take them and to help each other do more great things.
4 thoughts on “Starlink Beta: The Good, The Bad, And The Ugly”
Thank you so much for sharing! Realizing you’re under the constraints of you contract with Starlink, I am so interested in any info you could provide about hosting. Specifically,
* Does Starlink provide you with a static IP? If not, would you be able to use a dynamic DNS service with it?
* Does the equipment block any ports? For instance, could I host an SSH server on port 22 or 2222? An HTTPS server on port 43? Does the included router support forwarding of the ports?
* Could I attach my own router and log in with PPTP or some other simple protocol?
Absolutely happy to share. More to come on that shortly, likely on the youtube channel. It is a static IP address, but Dynamic DNS does work based on my testing. Port forwarding is not supported, both with their router, and several professional-grade routers I tested. Based on my conversation with support, port forwarding is on the roadmap, but anything inbound appears to be blocked. I was able to bypass this with the reverse VPN described in the article. I plan to do a youtube walkthrough of how I set that up in the coming weeks.
Thank Aaron, great data. I look forward to getting more data though your channel. We are in Western Montana and are running the beta from the Bitterroot Valley.
Awesome, how has your experience been compared to your previous provider?