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>.
Outbound
TCP
443
api.softwaredefinedautomation.io
Outbound
TCP
443
sdagateway.softwaredefinedautomation.io
Outbound
TCP
443
Outbound
TCP (Websocket)
443
Outbound
UDP
20000-60000
Outbound
TCP
443, 80
Domains listed under
/etc/apt/sources.list
for OS updates (see note below)
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 with Docker (recommended)
In addition to the firewall rules above, you'll need access to Docker hub to pull the official image from our public registry. Read our repository usage documentation to learn how to run the connectivity agent with Docker:
The Dockerized application has a built-in Web UI on port 8186 to configure and manage active gateways. However, in contrast to the standard version, the Docker application will not automatically update, delegating this responsibility to the user.
If running the container in an external device, like a VM somewhere in your network infrastructure, make sure that you provide access form its local network to the Web UI port which the container will be listening to.
The Docker container needs to run with administrative network capabilities (
NET_ADMIN) for network operations.The application container listens on port 8186 by default. This port is required to access its built-in Web UI. If port 8186 is already in use on your host system, when launching the container, you will need to select another free port to avoid conflicts.
A persistent store using a Docker volume is highly recommended to ensure that your data is retained even if the container is stopped, updated or removed.
Running on Linux
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, Ubuntu Noble, 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
systemdenabled in the WSL instance, see instructions belowRunning 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
systemd enabledMake sure your WSL version is above 2 by running the following in PowerShell or in the Command Prompt:
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:
The systemd flag must be enabled in the WSL instance, what can be done by running the following in the WSL terminal:
Make sure the following lines are added to the file.
Save the changes with Ctrl+O and exit the editor with Ctrl+X and restart the WSL instances by running in PowerShell:
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:
For more information about Hyper-V and WSL on Windows:
If you have a device with different requirements, please get in touch with us.
Last updated