Access control#
A route makes a service reachable. Access rules decide who may reach it. They're an optional edge-authorization layer you attach to a device or route, enforced before traffic ever reaches your service.
Note
Access rules are separate from the mutual-TLS that authenticates devices to the relay. mTLS proves your device is who it says it is; access rules govern the public visitors on the other side of the tunnel.
Rule types#
| Type | What it checks | Typical use | Status |
|---|---|---|---|
| IP allowlist | The source IP of the visitor | Restrict to your office/VPN egress ranges | Enforced |
| Basic auth | An HTTP Authorization: Basic username/password | A quick shared credential on an internal tool | Enforced (terminate mode) |
| OIDC | An OpenID Connect / OAuth2 login | SSO in front of a dashboard | Configurable, not yet enforced |
| mTLS client | A client certificate presented by the visitor | Machine-to-machine, high-assurance access | Configurable, not yet enforced |
You can stack rules — e.g. an IP allowlist and basic auth — to require all of them. Passwords for basic auth are bcrypt-hashed before they're stored; the platform never keeps them in plaintext.
Warning
OIDC and mTLS client rules can be created and stored today, but the edge does not enforce them yet — don't rely on them as your only gate. IP allowlists and basic auth are fully enforced as described below.
Where rules are enforced#
Enforcement depends on what the relay can see, which follows from the route's TLS mode:
- Terminate mode — the edge sees the decrypted request, so both rule types apply there: the IP allowlist rejects with
403, and basic auth challenges with401 WWW-Authenticate(the browser's native login prompt) and verifies credentials against the stored hashes. Nothing reaches your device until the rules pass. This is the mode to use when you want Tollan to do the gatekeeping. - Passthrough & port routes — the relay never decrypts the stream, so it cannot read an
Authorizationheader or inject a401challenge. The IP allowlist still applies (it acts on connection metadata — a denied visitor's connection is simply closed), but HTTP-layer auth must be enforced by your own service. For SSH and other self-authenticating protocols this is exactly what you want — see the SSH guide.
If you need the relay to enforce app-layer auth on an HTTP(S) service, run the route in terminate mode.
Rule changes take effect at the relay immediately — no restart, same propagation path as route edits.
Managing rules#
From a device or route in the console you can list, add, edit, and delete access rules. Changes propagate to the relay the same way route changes do — via the internal event channel — so they take effect without a restart.
Choosing a rule#
- Personal / small — an IP allowlist is the simplest strong control if your clients have stable IPs.
- Shared internal tool — basic auth is fast to set up; pair it with an IP allowlist.
- Team dashboard — OIDC will give you real SSO and per-user identity (once edge enforcement lands; today, put SSO in the app itself).
- Automation / devices — mTLS client certificates authenticate machines without shared secrets (same caveat — not yet enforced at the edge).
Defense in depth#
Access rules complement, rather than replace, the platform's other guarantees:
- Devices authenticate to the relay with mutual TLS — the tunnel itself is authenticated and encrypted.
- Forwarding agents enforce a target allowlist — the relay can't reach LAN hosts you didn't authorize.
- Access rules gate the public side — who on the internet may use a route at all.
Layer as many as your risk model calls for.