Restricted networks and blocked connections

Hotel Wi-Fi, a conference network, a hardened corporate egress filter, a captive portal. These break different things, and the symptoms look similar from the outside - so the useful skill is telling them apart quickly rather than guessing.

The agent depends on four things: the management service, which hands out keys, access rules and the network map; Discovery, through which two devices agree on a path; a relay; and a direct path to each device. The management service is at mgmt.sxaccess.com on TCP 443. It hands each agent its Discovery and relay endpoints, which use TLS on TCP 443 as well. The four fail independently, and the consequences are very different.

When the management service is unreachable, the agent does not give up and does not hammer the network. Every wait below is randomized, so a single one can be anywhere up to twice the figure given.

• Connecting. A device that is starting, or connecting again from scratch, retries after about a second and waits 1.7 times longer each time, up to 15 seconds between attempts.
• Losing a running connection. When an established connection drops, for example because a laptop was closed on one network and opened on another, the agent retries after 0.8 seconds, growing by the same factor up to 10 seconds. Tunnels stay up meanwhile.
• The long tail. Both keep that up for three months. After that, the agent service starts the connection again at intervals of 30 to 60 minutes for up to 14 more days.

In practice a laptop closed on a blocked network and opened on a working one reconnects within seconds, with no action from the person using it.

Two refusals are handled differently. When the management service refuses the device itself, retrying could never succeed: its session expired, it was deleted, or the member it belongs to was blocked. The agent stops, and sxaccess info says This device is not signed in until sxaccess start signs it in again. When the whole organization is suspended, the agent keeps trying about every 5 minutes and reconnects on its own once the organization is active again.

Start with sxaccess info -d. The headline and the Service, Discovery and Relays rows say which dependency is missing, and each device's Path: line says whether it is direct (P2P) or Relayed. The filters exist for exactly this, because you want the count, not the wall of text. Each of them switches the detail view on by itself.

Three commands narrow it down. First, is anything direct at all? List the connected devices that have a direct path, then the ones on a relay:

All relayed and none direct means that outbound UDP is blocked, or that both ends sit behind strict NAT. Next, check whether this host reaches the management service:

The command prints an HTTP status code. Any three-digit code, usually 404, means this host reaches the management service over TLS on TCP 443: the service answered, and its root path has nothing to return. 000 means no answer arrived. The error curl prints above it says why, for example a timeout when a firewall drops the traffic, or a certificate error when something inspects TLS on the way.

Last, see which devices are in the map, and in what state:

Before you tell a network team that relaying is the problem, confirm that relaying actually is the problem. With SX_RELAY_ONLY=true in its environment, the agent service sends every tunnel through a relay and skips direct paths, so you can measure the restricted network's behaviour on a network that is not restricted.

The agent service reads the variable, not the sxaccess command, so set it with sudo sxaccess agent reconfigure --service-env. That command restarts a running agent by itself; once the agent has reconnected, sxaccess info -d shows every connected device as Path: Relayed. The command also replaces the service's whole environment each time: if you set other variables this way, list them in the same command, separated by commas. To undo it, reconfigure again without SX_RELAY_ONLY.

If the application is fine on a forced relay, the firewall is costing you latency, not function, and the fix is a conversation about priorities rather than an outage.

In order of how much it buys you. The first row alone makes the product work.

A capture taken over the failure is worth more than a description of it. sxaccess diagnose capture 5m switches the agent to trace logging, reconnects the device, runs for the time you give and bundles that window, so the log covers the moment the connection failed rather than the whole day. Because it reconnects, sessions running over SXAccess drop.

Add -A to replace public addresses and outside domains before the archive leaves your machine. Private ranges, overlay addresses and device names stay visible, so open the archive and check it before attaching it anywhere.