Tollan vs a VPN for remote device access
A VPN puts you on the network. Tollan puts you on one service. That single difference decides most of what follows: what a stolen laptop reaches, what the customer's IT team has to approve, and what you can hand an auditor.
Network access versus service access
| What you are deciding | Tollan | A VPN |
|---|---|---|
| What a connection reaches | The one service on the one device you published. | Whatever the routing and firewall rules allow on that subnet. |
| Inbound firewall changes | None. The agent dials out. | A concentrator or gateway usually has to accept inbound traffic somewhere. |
| Client software | A browser or an ordinary client, pointed at a hostname. | A VPN client, profile, and credentials on every machine that needs in. |
| Works behind CGNAT | Yes, because nothing needs to connect inbound to the device. | Only if the device can reach a concentrator you host somewhere else. |
| Per-device identity | Every device holds its own CA-issued certificate. The private key is generated on the device and never leaves it. | Often a shared profile or key per site rather than per device. |
| Removing one engineer or unit | Revoke a device and its live tunnels drop in seconds — the relay re-checks certificate status continuously. | Rotate the profile and redistribute it to everyone who still needs access. |
| Customer approval | "Our device makes one outbound connection" is an easy sentence. | Site-to-site links and vendor boxes tend to need a security review. |
When a VPN is still the right tool
Tollan publishes services. It is not a general network layer, and pretending otherwise would waste your time.
- You genuinely need a whole subnet, not a handful of named services.
- You depend on broadcast or discovery protocols that assume one flat network.
- Your traffic is not TCP, so a per-service TCP route cannot carry it.
- An existing corporate VPN already covers the sites, and adding a service is free.
Plenty of teams run both: the VPN for their own offices, Tollan for equipment sitting in customer networks.
The controls that usually justify the VPN
- Attach IP allowlists, basic auth, or mutual-TLS to a route as edge access rules.
- Every resource belongs to an organization, and the boundary is enforced and adversarially tested in CI.
- Passthrough traffic is never decrypted at the relay. We route by TLS SNI without reading a single byte of your payload.
- Console accounts get role-based access, optional TOTP two-factor, and an append-only audit trail.
Working through a specific setup? The PLC page walks through a machine network, and the no-port-forwarding page covers the home and small-site case.
Where a VPN still makes sense
Is a VPN not the safer, more established choice?
A VPN is well understood, and for giving staff broad access to an internal network it remains the right tool. The trade is scope: a VPN puts a whole subnet in reach of whoever holds the profile, where a route exposes exactly one service. Attach IP allowlists, basic auth, or mutual-TLS to a route as edge access rules.
Do I still need to open a port for this?
No. Like a client VPN, the connection is made outbound — but the thing that dials is the device itself, so no client software is needed on the laptop of whoever needs access.
How is access removed?
Revoke a device and its live tunnels drop in seconds — the relay re-checks certificate status continuously. There is no profile left on a laptop to worry about afterwards.
Can I limit who reaches a route?
Attach IP allowlists, basic auth, or mutual-TLS to a route as edge access rules. Console accounts are governed separately: Console accounts get role-based access, optional TOTP two-factor, and an append-only audit trail.
What about a device on a network I do not control?
That is the common case for field equipment, and it needs no cooperation from the site: the agent dials out. Remote access without port forwarding covers it.
Replace one VPN route this week
Free tier, no card required. Start with the device that causes the most support calls.