Welcome, Guest
Username: Password: Remember me

TOPIC: SunSDR over VPN (based on Starlink): background and basics.

SunSDR over VPN (based on Starlink): background and basics. 05 Feb 2022 09:15 #1

  • VK6NX
  • VK6NX's Avatar
  • Posts: 296
  • Thank you received: 138
The question about SunSDR capability to work over VPN is regularly appearing on this forum. Below information will allow you to understand the basics, potential performance impact and set your expectations prior starting experiments.

This is first post of the series: it is more concentrated on theoretical aspects. It is my intention to post second one later, containing practical measured results.

I am using Starlink in the following example; primarily because I am doing VPN tests over Starlink; and also because using Starlink example it would be easier to highlight important VPN nuances.

The following information assumes reader's basic (important "basic" is NOT equal to "sound") knowledge of the networking and the VPN principles.

There are number of reasons why SunSDR user may need VPN. Using Starlink example, VPN is needed because of current (as of Feb 2022) CGNAT over IPv4 setup, used by SpaceX, whuch does not allow common port forwarding and hence preventing from use of typical and proven NAT port forwarding configurations.

Below diagram demonstrates typical setup.


Please note, that when using other than Sartlink provider, the VPN Server/Client can be on either side. However, with Starlink the connectivity has to be initiated from SunSDR site; hence VPN Client has to be located at this site only.

OpenVPN is used as an example due to large list of known configurations for this VPN type, hence it is much easier to find configuration for your router/FW/device on Internet.

OpenVPN can ron on many routers/firewalls; in this example we are using OpenVPN on pfSence and Ubi (FW and Router) - recommended configurations can be easily found for those (just use search).

VPN considerations.
When using VPN it is important to understand the principles of VPN to establish end-to-end connectivity; and implications + overhead VPN is bringing to the combined traffic flow.

Why overhead?
A packet (or frame) destined to a remote network is encapsulated at the source by adding extra header payload. The it is sent via network to the remote site, where added header payload is removed and the packet (frame) is sent out to the final destination. Encapsulation/de-incapsulation is happening within VPN Server and VPN Client, consuming platform resources (CPU, memory, bandwidth).

What implications?
1. Choise of Transport Protocol - TCP or UDP. Both have known advantages and disadvantages and on top of those:
  • a) VPN over TCP has undesirable negative effect such as TCP stacking. By nature TCP was designed to be not stacked; hence when it is used for VPN, the commonly observed result is an unreliable medium and retransmits packets when a timeout occurs. It is critical when we are talking about any real-time traffic, such as network stream between SunSDR and ESDR.
  • b) VPN over UDP is affected by common UDP characteristics: UDP is non-reliable protocol and does not perform verification and retransmits. Hence VPN over UDP heavily relies on site-to-site connectivity stability (the parameter which is outside of end-user control).

    2. Metrics:
    The performance (both network and VPN) is typically measured a set of performance criteria (or metrics). For most VPNs (including OpenVPN) the metrics list is following (sorted in importance descent order):

  • 2.1 Overhead
  • 2.2 Throughput
  • 2.3 Link bandwidth utilization
  • 2.4 Jitter and Round-trip time
  • 2.5 Server and Client CPU utilization
  • 2.6 Errors probability and re-occurrence time.

  • Overhead was partially discussed above. The encapsulation process adds overhead to each packed (this process is commonly combined with symmetrically reduce the MTU size). When a payload is encapsulated into VPN tunnel, the headers and trailers added to the payload. Another overhead layer aded by encryption ciphers (more secure cipher algorithm - more overhead it brings into). The typical observed result - the reduced bandwidth of the encrypted stream - brings us to 2.2 Throughput

    Throughput is usually depends on the VPN Server and Client hardware and software parameters (aka more powerfull CPU of the platform is less impacting throughput). Examples of measured throughput for different hardware/software can be easily found on Internet (example for Vault: protectli.com/kb/openvpn-performance-on-the-vault/).

    Link bandwidth utilization is the combined parameter. For example (using above diagram), the LAN bandwidth required for SunSDR set with 39 kHz resolution is 12 Mbps. AES128/SHA128 (minimal!) encryption algorithm will add approximately 12% overhead. VPN encapsulation will add another 4%. As the result, encrypted and encapsulated stream will be approx 14Mbps of bandwidth. Looking at the above diagram - the maximum observed uplink speed for Starlink is 24Mbps, hence, it should be capable to carry dedicated SunSDR traffic for 39 kHz resolution ... assuming the uplink will not drop to 8 Mbps (minimal observed uplink speed).

    For the given example, the Jitter is is the variation in the latency of packets sent from Client and received by Server. Starlink typical Round Trip Time is 40ms (maximum observed is 75ms). Jitter overhead may be added by ciphers (dependent on combination of CPU type, chosen cipher complexity and SunSDR bandscope resolution). Hence, the estimation while using Starlink, the usability of the setup for CW operations is under question, when SSB and DIGI should be fine.

    Hopefully Server and Client CPU utilization is self explainable. Unfortunately it is very hard to predict how much CPU itilization will be for particular platform; it is more the experimental question. Obviously, it is also value-for-money question.

    Errors probability and re-occurrence time are mainly dependent of VPN transport protocol choice combined with site-to-site path reliability (this last parameter is outside of end-user control, we are dependent on chosen providers and their interconnects/loads/policies/etc.).

    3. Considerations for VPN Server/Client hardware choice.
    The following typical parameters should be taken into consideration when choosing hardware for your VPN Server and Client (sorted in importance descent order):

    3.1 Speed of the router CPU
    3.2 Memory
    3.3 Interfaces count
    3.4 VPN Transport Protocol
    3.5 Encryption cipher type
    3.6 Encryption key size
    3.7 Compression algorithm
    3.8 Network topology and speed
    3.9 VPN topology

    4. Performance analisys and tools
    Obviously (and unless "I believe" approach is in use), to confirm that VPN definitely has expected parameters, it is recommended user to become familliar with Wireshark.

    iPerf is an additional recommended tool, which may be able to explain bandwidth-dependent caveats.
    The administrator has disabled public write access.
    The following user(s) said Thank You: Rome, lz2aov

    SunSDR over VPN (based on Starlink): background and basics. 05 Feb 2022 09:51 #2

    • danielwee
    • danielwee's Avatar
    • Posts: 209
    • Thank you received: 29
    Good start! Might be worth adding a section on subnets, masks and DHCP within the VPN environment.
    The administrator has disabled public write access.

    SunSDR over VPN (based on Starlink): background and basics. 05 Feb 2022 11:50 #3

    • VK6NX
    • VK6NX's Avatar
    • Posts: 296
    • Thank you received: 138
    I am sorry, primary school of networking is located at Udemy and other learning resources. I have mentioned that what I have posted (quote) "assumes reader's basic (important "basic" is NOT equal to "sound") knowledge of the networking and the VPN principles".
    The administrator has disabled public write access.
    Time to create page: 0.120 seconds