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 |
|---|---|---|
| IP allowlist | The source IP of the visitor | Restrict to your office/VPN egress ranges |
| Basic auth | An HTTP Authorization: Basic username/password | A quick shared credential on an internal tool |
| OIDC | An OpenID Connect / OAuth2 login | SSO in front of a dashboard |
| mTLS client | A client certificate presented by the visitor | Machine-to-machine, high-assurance access |
You can stack rules — e.g. an IP allowlist and basic auth — to require all of them.
Where rules are enforced#
Enforcement depends on the route's exposure:
- Terminate mode — the relay terminates TLS at the edge, so it can inspect and enforce HTTP-layer rules (basic auth, OIDC) and IP/mTLS checks directly. This is the mode to use when you want Tollan to do the gatekeeping.
- Passthrough mode — the relay never decrypts the stream, so IP allowlist and mTLS client checks (which act on connection metadata) still apply, but HTTP-layer rules (basic auth, OIDC) must be enforced by your own service. The console flags this so you're not surprised.
If you need the relay to enforce app-layer auth on an HTTPS service, run the route in terminate mode.
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 gives you real SSO and per-user identity.
- Automation / devices — mTLS client certificates authenticate machines without shared secrets.
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.