Requirements

This section gives an overview of the requirements to use SDA's connectivity v2 service.

Required firewall settings

The following firewall settings need to be implemented for the gateway device. Please contact SDA to get your <tenant_id>.

  • The connectivity service will soon work via TCP ports only

  • In case you firewall has issues with using/resolving the FQDNs (fully qualified domain names), there is an alternative firewall based on AWS IP Ranges mentioned below

During installation, access to domains for installing or updating OS packages is needed. In Debian-based linux, the corresponding domains can be found via executing

cat /etc/apt/sources.list

in the command line. For Debian those domains will typically be

  • deb.debian.org

  • security.debian.org

For Ubuntu it is

  • ports.ubuntu.com

Access to those domains is needed for TCP port 443 and 80.

Alternative Firewall configuration

In case you firewall has issues with using/resolving the FQDNs (fully qualified domain names), you can use the IP Ranges published by AWS (see https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)

The SDA Connectivity Service needs access to the following AWS services:

  • Cloudfront (Region GLOBAL) (TCP on port 443)

  • EC2 (Region EU-WEST-1) (TCP Websocket on port 443 or UDP on port 20000-60000)

These IP ranges cover the domains api.softwaredefinedautomation.io, iot.softwaredefinedautomation.io and sdagateway.softwaredefinedautomation.io mentioned above. Note that some firewall vendors (e.g., Palo Alto Networks) offer these AWS IP Ranges as preconfigured aliases in the firewall configuration.

Running on Linux (recommended)

In addition to the firewall rules above, for initial installation you will need access to the OS-specific domains listed /etc/apt/sources.list (see note above).

The following requirements need to be fulfilled by the device or VM on which the local connectivity client is installed:

  • x86_64 or ARM64 architecture CPU (32 bits Raspberry Pi OS not supported)

  • Minimum of 1 GHz Dual-Core CPU and 512 MB of RAM

  • Debian-based Operating System

    • We currently maintain Ubuntu Focal, Ubuntu Jammy, Debian Bullseye, and Debian Bookworm, supporting both x86_64 and ARM64

    • Windows is supported with WSL 2, running one of the Linux versions above — check the note below.

    • More Debian versions are available upon request (other Linux distributions coming soon)

  • Linux Kernel Version 5.6 or newer

  • Python 3.8 or newer

Running on Windows with WSL 2

We currently do not support running the connectivity client in native Windows, but it runs with a Linux subsystem like WSL.

  • The Linux image should be one of those mentioned in the Linux requirements section above, namely Ubuntu Focal or Jammy, and Debian Bullseye or Bookworm (recommended).

  • Setting up the gateway requires having systemd enabled in the WSL instance, see instructions below

  • Running WSL 2 requires Hyper-V, therefore the connectivity client does not run in Virtual Machines, only in bare metal

  • The setup method of the connectivity gateway is the same as in Linux, described in How to set up a Gateway, since executed in WSL 2, but mind any extra software firewall blocking traffic from WSL to the local network — Windows native firewall was tested and should not have issues

Configuring WSL Version 2 with systemd enabled

Make sure your WSL version is above 2 by running the following in PowerShell or in the Command Prompt:

PS C:\> wsl --version

You can list your installed Linux distributions and check the version of WSL each is set by entering the command wsl -l -v in PowerShell or in the Command Prompt.

In case the result does not match the requirements, we recommend updating WSL and installing Debian Linux:

PS C:\> wsl --update
PS C:\> wsl --install -d Debian
PS C:\> wsl -l -v
  NAME      STATE      VERSION
* Debian    Running    2

# If VERSION is not 2, run
PS C:\> wsl --set-version Debian 2

The systemd flag must be enabled in the WSL instance, what can be done by running the following in the WSL terminal:

$ sudo nano /etc/wsl.conf

Make sure the following lines are added to the file.

[boot]
systemd=true

Save the changes with Ctrl+O and exit the editor with Ctrl+X and restart the WSL instances by running in PowerShell:

PS C:\> wsl --shutdown

Upon launch you should have systemd running, what can be validated with the following command in the WSL terminal, which should return the status of your services:

$ sudo systemctl list-unit-files --type=service

For more information about Hyper-V and WSL on Windows:

If you have a device with different requirements, please get in touch with us.

PreviousOverviewNextHow to set up a Gateway

Last updated