Connectivity & ports

What a device must reach and what it listens on, for planning firewall rules.

This page lists what a device needs to reach on the network and what it accepts on its own interfaces, so you can plan firewall rules for the sites where your devices run.

Outbound connectivity (required)

A device reaches the SPEKTRA Edge platform over secure, outbound connections. Devices do not need any inbound connections from the platform — all communication is initiated by the device.

DestinationPortPurpose
*.edgelq.comTCP 443Everything the device needs from the platform: onboarding, configuration, telemetry, log forwarding, remote access, and OS downloads.
Your container registryTCP 443Image pulls. The device connects to the registry directly — see Private registry.
Your time sourcesUDP 123Network time synchronization. See Time synchronization.
Public STUN serversUDP 3478, UDP 19302External IP address discovery.

All platform traffic is TLS on TCP 443. Allow the whole edgelq.com domain rather than individual hostnames: a device is directed to different service endpoints depending on its project and region, and the set changes as the platform grows.

At minimum, allow outbound TCP 443 to *.edgelq.com and outbound UDP 123 to your time sources. If you use a proxy, the device’s platform traffic egresses through it.

Match subdomains at any depth

Platform hostnames carry several labels, so the rule has to match more than one level below edgelq.com.

Many firewalls and proxies treat *.edgelq.com as matching every subdomain at any depth, which is what you want. Some treat * as exactly one label — and on those, *.edgelq.com matches a two-label name but not a deeper one, which lets a device get far enough to onboard and then stops it.

If your equipment behaves that way, express the rule as a domain-suffix match on edgelq.com instead. Squid spells this .edgelq.com; most next-generation firewalls offer a “domain suffix” or “subdomain” match type.

DNS

The device must be able to resolve every destination above. A device on a network with filtered or split-horizon DNS can pass a connectivity test to a raw IP address and still fail to reach the platform. If you run internal resolvers, confirm they resolve edgelq.com names and your registry’s name.

Inbound (on the device)

By default a device exposes only what is needed to administer it locally:

PortPurpose
TCP 22SSH access. Can be restricted or disabled — see SSH access.

The device also responds to local network discovery (mDNS) so it can be found by name on the local segment; this can be turned off with the device discovery setting.

Any ports your workloads expose are determined by the workloads you deploy, not by the OS.

Remote access does not require inbound ports

Operator actions such as opening a remote shell, transferring files, or streaming logs are carried over the device’s existing outbound connection to the platform. You do not need to open inbound ports to use them. See Remote access.

Firewall planning checklist

  • Allow outbound TCP 443 to *.edgelq.com (directly or via proxy), matching subdomains at any depth.
  • Confirm the device can resolve those names with the resolvers it will actually use on site.
  • Allow outbound TCP 443 to your container registry, if you deploy from a private one.
  • Allow outbound UDP 123 to your NTP sources.
  • Allow outbound UDP to your chosen STUN servers (or accept that external IP discovery is unavailable).
  • If traffic passes through a proxy, confirm it permits HTTP CONNECT to port 443 and does not terminate TLS — see Proxy configuration.
  • Decide whether local TCP 22 (SSH) should be reachable on your LAN.
  • Open any ports your workloads require, per workload.