Expert Remote over Starlink       

For ESDR3 Releases 1.1.x / Expert Cloud release 1.1.x and further.

Expert Remote Ecosystem Overview

Expert Remote represents a unique software-defined ecosystem, officially launched in late December 2025 alongside the latest release of ExpertSDR3 and the newly introduced Expert Starter.

A key advancement over the previous remote-access solution (Remote RC) is in the transition from a (previously) fully proprietary authentication, authorization, and communication protocol to (current) open WebRTC standard. This architectural shift significantly enhances system performance and reliability, enabling a broader range of remote functionalities and eliminating the requirement for a Virtual Private Network (VPN) in the communication path between ExpertSDR3 and the SDR hardware.

As of this release, the legacy Remote RC solution has been permanently decommissioned. Consequently, Expert Remote now serves as the sole and fully operational successor, offering both a functional replacement and a substantial upgrade.

For a comprehensive overview of the Expert Remote architecture, components, and operational principles, readers are directed to the official ExpertSDR3 User Manual, which provides detailed technical documentation on the system.


The implication to existing Starlink-based Remote communication scenarios
While new Expert Remote undeniably constitutes a significant advancement in remote SDR operation, its adoption may necessitate a reassessment—and potential redesign—of network architectures employed by users relying on Starlink or comparable satellite-based internet services, particularly with regard to Remote Shack and Operator Location configurations.

Is a Virtual Private Network (VPN) still required?
The answer is both yes and no, depending on the specific operational context.

Yes, in the sense that the communication pathway between ExpertSDR3 (ESDR3) and the SDR hardware no longer requires a VPN. The integration of the WebRTC protocol enables end-to-end discovery of network parameters, dynamic determination of the optimal connection topology (e.g., direct peer-to-peer or relayed via TURN/STUN), and establishment of a secure, low-latency data channel. Practically, this eliminates the latency and overhead traditionally introduced by VPN encapsulation. Consequently, in the vast majority of deployment scenarios, it is now strongly recommended to exclude VPNs from the ESDR3–SDR signaling and data traffic path to maximize performance and reliability.

No, however, in the broader operational context: a VPN may still be necessary at the Remote Shack side to support auxiliary management functions, such as remote software updates, hardware reboots, and power control operations—tasks that (at this stage and in this release) currently fall outside the scope of the WebRTC-based SDR data plane.

Changes in Starlink subscription/service plan?
A reassessment of the current Starlink service tier may be warranted, though the necessity ultimately depends on the specific operational requirements and network topology currently employed by the user. Key considerations are outlined below.

In general, the adoption of WebRTC in Expert Remote partially mitigates the traditional requirement for publicly routable IPv4 addresses at either the Operator Location or the Remote Shack. This is achieved through the use of a cloud-hosted STUN (Session Traversal Utilities for NAT) server, which facilitates initial session negotiation, endpoint discovery, and NAT type characterization. In a wide range of network environments—including those behind common consumer-grade firewalls and non-symmetric NAT implementations—this mechanism successfully enables direct connectivity without the need for static public IP addresses.

By design, once the STUN-assisted discovery phase is complete, Expert Remote defaults to establishing a direct peer-to-peer (P2P) data channel between the two endpoints to minimize latency and maximize throughput.

However, a notable exception arises in scenarios involving Carrier-Grade NAT (CGNAT), which is inherent to Starlink’s default residential subscription tier. Under CGNAT, end-user devices are assigned private IP addresses not only within the local network but also at the ISP level, effectively preventing the establishment of direct inbound connections from external peers—a fundamental requirement for WebRTC-based P2P communication. Consequently, in such topologies, the STUN discovery process will correctly identify the presence of CGNAT and automatically fall back to a TURN (Traversal Using Relays around NAT)-mediated relay path.

In practical terms, this means that Expert Remote deployments involving one or more Starlink residential connections will operate via a TURN server, introducing add-on latency (not that significant as with VPN) and potential bandwidth constraints (due to TURN traffic is often chargeable by providers) compared to a true P2P link. Users requiring guaranteed low-latency, high-throughput operation (for CW and contest scenarios) — or seeking to avoid reliance on relay infrastructure—may therefore need to consider upgrading to a Starlink Business plan (or equivalent Priority service tier offering public IP addressing and CGNAT bypass) to fully leverage the native P2P capabilities of the Expert Remote architecture.

Typical scenarios when “peer-to-peer” is not possible and “TURN fallback” is engaged:


TURN fallback scenario 1: both locations on CGNAT-based Starlink basic WAN


TURN fallback scenario 2: locations on CGNAT-based Mobile and Starlink basic WAN


TURN fallback scenario 3: Operator location on CGNAT-based Mobile* with Starlink Priority WAN

* Note that not every 4G/5G operator uses CGNAT, hence scenario 3 is also subject to test in practical application; with some providers around the world described scenario may support P2P.

In the TURN fallback scenario, session negotiation still uses STUN, but the ESDR3 ⇄ SDR data path is relayed through a TURN server instead of a direct peer-to-peer link. While TURN introduces significantly less overhead than a traditional VPN, it still adds latency and potential packet loss compared to P2P.

Practically, performance hinges on the inter-location round-trip time (ping). An average ping below 50 ms is generally sufficient for AM, SSB, and most digital modes.

CW operation, however, is more sensitive—particularly above 25 WPM—as TURN-induced delays can impair TX/RX switching responsiveness. Even with ~50 ms latency, some operators may find CW (specifically in 35-45 WPN range and contest environments) performance is less then desired with TURN relay .

Ultimately, suitability is highly individual and best determined through practical testing aligned with specific operational needs.

Mitigating CGNAT Limitations with Starlink
When Starlink is the sole connectivity option, two primary workarounds exist to circumvent CGNAT-induced restrictions on peer-to-peer connectivity..

The most straightforward approach is to upgrade to a Starlink Priority (Business) subscription and request a public IPv4 address through the Starlink account portal. While this enables direct inbound connections and full P2P WebRTC operation, it entails higher recurring costs, necessitating careful cost–benefit analysis..

An alternative—but technically demanding—option involves leveraging IPv6 on a standard (residential) Starlink plan. This requires:.
* Coordination with the ISP (which may incur fees or be unsupported);
* Advanced competency in IPv6/IPv4 dual-stack configuration, routing, and failover mechanisms;
* Awareness of inherent IPv6 limitations, such as inconsistent application-layer support and asymmetrical firewall behavior;
* Potentially upgrading consumer-grade networking hardware, as many devices lack robust IPv6-to-IPv4 translation (e.g., NAT64, DS-Lite) or proper ICMPv6 handling..

Given these complexities, adopting IPv6 should only be pursued after thorough technical evaluation and realistic self-assessment of networking expertise.

Typical scenarios with “peer-to-peer” while using Starlink:


Peer-to-Peer scenario 1: Common NAT in Operator location with Starlink Priority WAN


Peer-to-Peer scenario 2: Starlink Priority WAN in both locations

In both above scenarios there is no limitation for peer-to-peer to be established after STUN handshake and network discovery phase; TURN remains available for fallback situations, when connectivity quality between locations is temporarily reduces due to any provider-related issues.

Same “average inter-location ping around 50ms” rule apply in both above example scenarios, but now there the TX/RX switching delay is minimal, which connectivity suitable for CW WPM 25-45.

Should you continue using VPN and stay on basic subscription with new Expert Remote?
Strictly speaking, VPN is not “banned” from WebRTC-based communication, however it is not recommended. WebRTC performs best without a VPN, as tunneling can add latency, hinder NAT traversal, and trigger unnecessary TURN fallbacks—even when P2P is possible. While retaining a VPN (e.g., for remote management), be aware of potential performance and connectivity impacts. Thorough testing under your specific conditions is advised.

TURN Fallback: Options, Efficiency, and Cost Considerations
At launch, Expert Remote includes a single, Europe-based built-in TURN server, enabled by default for all users. Expansion to Americas, APAC, and Africa is planned but will require time. Regional proximity matters: WebRTC selects the TURN server with the lowest latency and best network metrics, so distant servers can degrade performance—highlighting the need for geographically distributed infrastructure.

Built-in TURN may become subscription-based in the future, as TURN services are resource-intensive and costly to operate at scale.

During Expert Remote closed testing phase (Sept-Nov 2026), several third-party TURN providers were evaluated (Xirsys, Twilio, Metered CA, Turnix, ExpressTURN, Cloudflare). All—except Cloudflare—require paid subscriptions with usage caps starting from byte 1. To calculate you potential subscription cost, note estimated Expert Remote traffic ranges from 250–400 MB/hour, depending on ESDR3 mode and sample rate.

Cloudflare is the single tested provider offers a free tier with 1 TB/month, charging $0.05/GB beyond that (note that Cloudflare requiring a credit card while subscribing even to free services). A key limitation in Cloudflare: there are global and user credentials, and last are configurable in 1-48 hours range, necessitating periodic regeneration and manual updates in the Remote Cloud configuration. On the other hand, Cloudflare’s globally distributed anycast network provides robust, low-latency TURN access wherever its data centers exist (see actual CloudFlare DC map):


Each “dot” represents the local Data Centre and there is TURN service in each.

From Expert Cloud configuration simplicity perspective: it is enough to configure single address and CloudFlare will automatically connect via “network closest” TURN server:


Note that only TURN server is required add-on. You can add Cloudflare STUN as well, but in some scenarios it was found breaking session initial negotiation phase, hence use of in-build STUN is currently recommended.

For those who will be interested to try CloudFlare TURN, it can be found in https://dash.cloudflare.com here:

From practical test perspective note the results obtained during Expert Remote test phase:

- 45-55ms average ping, while using 4G mobile hotspot (CGNAT, operator) and Starlink basic (CGNAT, remote shack) with all-in-one geographic location (AU mobile, AU Starlink, AU CloudFlare TURN).

- 300ms average ping with Europe-based operator connecting to remote AU-based sheck (AU Starlink and AU CloudFlare TURN).

Please note, that all measurements and described/tested networks/scenarios are effective for the period Expert Remote service initial launch in December 2025. With Expert Remote service growing it is very much expected more options when in-build TURN network will grow and services availability will expand.


Expert Remote Sharing Service: Overview and Use Cases
A notable addition in Expert Remote release is the built-in Sharing service, now live and freely accessible. It enables SDR owners to grant temporary remote access to their hardware—no registration required for guests—offering newcomers an outstanding opportunity to explore the ExpertSDR3 ecosystem and Expert Remote features before purchasing. The Expert Cloud registration is only required for Sharing party, not for Guests.

In this initial release, sharing is time-limited only: SDR owners (hosts) can set session duration but cannot yet restrict transmit (TX) permissions, band selection, or antenna control. SDR owners are advised to exercise caution when granting access, as full operational control is currently shared with ESDR3; and also provide necessary guidance to their Guests. The additional safeguards are under active development and expected in an upcoming update.

In general, what Sharing is enables to everyone an opportunity:

- DXpeditiors using Starlink Roaming to provide remote access to their setup
- Prospective users testing functionality before investment;
- Collaborative operation from a common QTH under a shared expedition callsign or foreign station callsign
- Real-time monitoring of propagation conditions by listening to your signal from distant locations.
- And more … as more feature to come in Sharing service