Routes

TIP

In some sections you will see references to eth0, which is no longer the default network interface name. Below are the interchangeable network interface names you may see:

• Linux: Most modern distributions (since ~2015) use "predictable network interface names" via systemd/udev. You'll typically see names like enp0s3, ens33, or wlp2s0 instead of eth0. The exact name depends on the hardware location and type.
• macOS: Uses en0, en1, etc. for ethernet/WiFi interfaces.
• Windows: Generally uses eth0.

SealedTunnel connections are established between two STLinks. Typically, for each connection, one STLink serves as a client (Binding), and another as a server (Mapping). Any individual STLink can simultaneously be a server for and a client of many resources simultaneously.

These connections between Bindings and Mappings must be pre-defined within the Commander.

We call these definitions Routes.

There are two types of Routes that must be defined to establish a SealedTunnel connection: Mapping Routes and Binding Routes.

Creating a Route does not actually establish a SealedTunnel connection. Routes must be assigned to Templates or Profiles and then deployed to individual STLinks to be used.

Mapping Routes

WARNING

When routing traffic to a separate machine, we strongly recommend that both machines are in the same subnet, and that the subnet itself not have any open inbound ports. STLink Mapping Addresses should never contain a public IP address.

A Mapping Route defines where the STLink running on a machine (typically a server) routes traffic that it receives.

If the resource is on the same machine as the STLink, then the Mapping Address, the IP address where the STLink will route the traffic, is typically a loopback address (e.g. 127.0.0.1).

In some situations, the STLink may not be deployed on the same machine as the resource that needs access (e.g., an IoT device).

In these cases, you can provide a private IP address for the Mapping Address and the STLink will route the traffic to that address. The service listening on the separate machine must allow external connections to receive the connection from the STLink (either by binding to the eth0 interface or to 0.0.0.0/all network interfaces).

Binding Routes

A Binding Route defines what IP address and port an STLink will listen on for incoming connection requests, ultimately routing that traffic to a paired Mapping.

The connections received on the specified Binding Address will be encrypted with Xiid's three layers of encryption and forwarded to the Xiid Connector. From there, the STLinks with the corresponding Mapping will pull in the connection data and forward it to its final destination.

Bindings are typically bound to a loopback address (e.g. 127.0.0.1). This only exposes the STLink's listening port to connections originating from the same machine, which is the most secure paradigm and the ideal binding state.

There may be situations where you may not want to bind to the loopback interface. In these cases, you can set the Binding Address to the private IP address of the device (either by binding to the eth0 interface or to 0.0.0.0/all network interfaces).

In those cases, the listening STLink is available for other devices within the same subnet to reach and use the SealedTunnel. For instance, if a CCTV camera cannot have the STLink directly embedded on the device, a lightweight device such as a Raspberry Pi can be put in the same subnet, and the specified Binding will bind to the eth0 ip address. The CCTV camera routes its traffic to the Raspberry Pi's Binding, which then routes the video data to a central command center.

End-to-End Example

In the above diagram, the Mapping Route (on the right) tells the STLink to route traffic that it receives to a separate machine with a private IP address of 192.168.0.1.

The web service on that separate machine is bound to port 543, so the STLink routes the traffic to that port.

The STLink on the left side has a Binding Route that binds to the client machine's loopback address of 127.0.0.1.

The STLink binds to port 443, so that when the user visits https://127.0.0.1, the browser automatically infers port 443.

The connection then goes to the STLink listening on the Bind Address, is wrapped in Xiid's triple-layer encryption, and is then forwarded to the Xiid Connector fleet, where the connection data is put into a queue.

The STLink on the right side then reaches out to the Xiid Connector, pulls in the connection data, decrypts the traffic, and forwards it to the second machine's (192.168.0.1) listening web service, establishing a full, end-to-end SealedTunnel connection between the client and the server resources.

Managing Routes

The Routes view in the Commander Portal provides a comprehensive list of all Routes you have created for your STLinks. Routes can be filtered by Binding Route and Mapping Route types and by their associated tags to assist with organizing and finding Routes as your SealedTunnel deployments scale. The key piece of information is the Route Type.

Field	Description
ID	The auto-generated ID used by the Commander Service to uniquely identify the Route
Name	The name used to identify the Route to the end-user
Description	The Route's purpose
Route Type	Indicates whether the Route is a Mapping Route or Binding Route
Tags	The Tags associated with the Route