Guide
From enabling WorksLink Access in the console to reaching your first remote service with your own tools, follow the steps below in order.
Before you begin
| Role | Where it runs | What it does |
|---|---|---|
| Access Gateway | On the on-site server, industrial PC, edge box or office PC you want to reach | Exposes allowlisted services on that machine or on the same LAN |
| Access Client | On an engineer's computer or an ops jump host | Maps an authorized remote service to a local port, or opens an SSH, SFTP or remote desktop session |
Both ends only need outbound access to the WorksLink service. No public IP and no router port forwarding are required. If your egress is restricted, the Windows gateway installer has a Test connection button; on other platforms, run workslink doctor.
System time must be roughly correct (within 2 minutes), or connection requests are rejected by replay protection.
Your first connection
- 1
Enable
An organization admin signs in to the WorksLink console, opens Secure Remote Access and enables it. Your existing organization account and member permissions apply.
- 2
Add an Access Gateway
Create a gateway enrollment token. On Linux, run the one-line install command the console shows; on Windows, run the installer and enter the address and token from the console. The device then appears under Gateways.
- 3
Expose services
Add services to the gateway's allowlist, such as SSH, remote desktop or a database port. A target can be the gateway itself or another device on the same LAN. Ports outside the allowlist are unreachable.
- 4
Add Access Clients
Create connector tokens for your staff. Each person installs the Access Client and enters the address and token; the computer appears under Connectors.
- 5
Write access rules
Define, by tag, which connectors may reach which gateways and services. The editor previews what the rule allows before you save it.
- 6
Connect and review
People connect with workslink ssh, a local port mapping or their own tools. Admins see current sessions and the event log under Activity.
Install the Access Gateway
Windows
- Run workslink-access-gateway-setup.exe and enter the address and token from the console; use Test connection first to confirm egress is allowed.
- The installer includes an offline OpenSSH Server, configures it and closes the inbound rule for port 22. Use /NOSSH to skip it.
- Runs as a system service, online before anyone signs in. The tray icon shows status: green connected, yellow not registered or disconnected, grey service not running.
- For bulk deployment, install silently:
Linux
- After creating a token, run the one-line command the console shows. The script detects the CPU architecture, verifies the package, creates an unprivileged workslink user and registers a systemd service.
- x86_64 and ARM64, statically compiled, independent of system library versions.
To serve other devices on the same LAN, set the target to their LAN address (for example 192.168.1.100:3306); nothing needs to be installed on them. The device must be reachable from the gateway and on the allowlist.
A gateway installed without a token can be activated later at http://127.0.0.1:8586/ui/setup on that machine, without restarting the service.
Install the Access Client
Windows
- Run workslink-access-client-setup.exe. By default it runs in the tray; open 127.0.0.1:8585 in a local browser to manage port forwards.
- To keep tunnels up with nobody signed in, choose Windows service mode in the installer, or add /SERVICE to a silent install.
- The workslink command line shortcut in the Start menu opens a ready-to-use shell for workslink commands.
macOS
- Pick the Apple Silicon or Intel .pkg. After installation it lives in the menu bar; click the icon to open the console.
- The command-line tool is at /Applications/workslink.app/Contents/MacOS/workslink.
Linux
- Provides the workslink-conn command, which opens tunnels on demand and exits when done; for persistent mappings, use the systemd service template the installer creates.
- Team sharing mode (workslink ui --mode=cloud) listens on HTTPS and forwarding ports on that machine and is meant for a team jump host; plan allowed sources and certificates before enabling it.
Ways to connect
The graphical console is at 127.0.0.1:8585 in a local browser. Common command-line usage:
| workslink list | List the gateways you may reach, their status and services |
| workslink connect <device-id> <service> | Map a remote service to a local port, reused on the next connection |
| workslink ssh <device-id> | Open an SSH session directly; sftp and rdp work the same way |
| workslink rdp <device-id> | Open the system's remote desktop client to a remote Windows machine |
| workslink proxy <device-id> ssh | Use as an SSH ProxyCommand, with no local port opened |
| workslink exec <device-id> --timeout 2m -- <command> | Run a command remotely; output streams back and the exit code is passed through |
For VS Code Remote-SSH and other SSH-based tools:
FAQ
Do I need to install it on every device?
No. An Access Gateway can expose services on its own machine or on other devices on the same LAN, as long as they are reachable from the gateway and on its allowlist.
Does it open up the whole network?
No. WorksLink Access authorizes per service: a client reaches only allowlisted services that an access rule permits. Everything else is denied, and no subnet is opened up.
Do I need a public IP or port forwarding?
No. Both the gateway and the client connect outward only, so the services you reach need no public IP and no port forwarding.
How is it different from WorksLink Remote Desktop?
Use Remote Desktop to see a screen and operate software; use WorksLink Access to reach servers, databases and internal systems, or let programs run commands. Both are managed from the same WorksLink console.
How fast is it, and what if a direct connection fails?
When a direct path exists, traffic goes peer to peer; otherwise it is relayed automatically, still encrypted. Actual speed depends on both networks and the path, and corporate egress policies still apply. Run workslink doctor to see which step fails.
How quickly does revocation take effect?
New requests follow the new policy at once. Online devices usually receive the change within seconds and existing connections are closed; devices that miss the push or are offline sync at the next poll, within about two minutes.
Are access and commands recorded?
The console records enrollment, authorization and denials, token and rule changes, and disconnections. Remote command execution details are kept in the gateway's local console; this is not a full session recording.
Does WorksLink Access open ports on my computer?
Port forwards listen on loopback (127.0.0.1) only, and SSH ProxyCommand opens no local port. The exception is team sharing mode on the Linux client, which listens on HTTPS and forwarding ports and needs separate planning.
Troubleshooting
Every platform includes workslink doctor, which checks these nine items in order and suggests a concrete fix for any that fail:
- Configuration directory permissions
- Local key pair integrity
- Console configuration and role
- HTTPS reachability of the console
- Clock skew within 2 minutes
- Signature authentication
- Gateway allowlist syntax
- Direct connection dial test
- Client can fetch its authorized device list
Still stuck?