Remote Access · By · 4 min read

How VPN-free remote access works

What the outbound-agent model actually does, versus what a VPN does. Written because enough people have asked variations of 'so how is this different from Tailscale?'

The question comes up on basically every demo call: if you’re not using a VPN, what are you using? The short answer is a long-lived outbound TLS connection from the machine you want to reach, to a relay we run. The browser connects through the relay. No inbound ports, no tunneled subnets, no “your laptop is now on the corporate network” illusion.

The longer answer is worth writing out, because the mental model is genuinely different from a VPN.

Both sides dial out. The firewall never opens a port, and the target never listens for connections.

What a VPN is doing

A VPN is network-layer. It creates a tunnel between your client and a concentrator, and anything sent through the tunnel looks (to the routing layer) like it’s on the remote side’s network. That’s powerful, because suddenly your browser can hit wiki.internal and your ssh client can connect to 10.0.2.14:22 as if they were local.

The cost of that power is a lot of implicit trust. The concentrator terminates all that traffic, and “on the VPN” becomes a security boundary in itself. If you’re inside, you’re inside.

What LynxTrac is doing

The agent runs on each target host and establishes a mutually-authenticated TLS connection outbound, to a regional relay. The agent never listens for incoming connections; its only network activity is the keep-alive it initiated.

When an operator wants shell access, their browser authenticates to the control plane (via your IdP, with MFA), receives a short-lived session token, and connects through to the relay. The relay knows which agent is paired with which token, and brokers a specific protocol session through the pre-existing tunnel.

That’s it. There’s no concept of “being on the network.” Each session is a narrow, per-endpoint, per-user, per-TTL bridge.

What you lose

The “it feels local” convenience. Your kubectl pointed at prod-cluster.internal doesn’t just work because you’re “on the VPN.” You have to provision a specific port-forward session, or we have to add prod-cluster as a managed endpoint in LynxTrac. For broad development work where you want to poke at a lot of things, a VPN is still convenient.

The ability to reach arbitrary TCP services. Our model is good at “give me this specific thing.” It’s not good at “give me everything on this subnet.” That’s a feature, not a bug, but it’s a real trade-off.

What you gain

A shorter list, but heavier:

No inbound ports on any target. Per-session scope. A clean audit record tied to an SSO identity. Immediate revocation. Works across NAT. Works behind HTTP-only corporate proxies (the TLS connection upgrades through them). Works from a Chromebook.

And, critically for operations: the whole thing fails gracefully. Relay down in one region? Agent reconnects to a sibling. Control plane slow? Existing sessions continue, new ones queue. We built a system where “VPN is down, incident is stuck” isn’t a thing that can happen to us, which turned out to also be a nice property for customers.

When each one wins

Default to VPNs for: local dev against internal DNS, one-off access to legacy services, anywhere you want the network to feel flat.

Default to outbound-agent access for: production, shared services with many reviewers, contractor access, anything that needs auditable per-session bounds, and anywhere the cost of a VPN outage would be larger than the cost of the VPN itself.

Most ops teams we’ve talked to end up running both for a while and retiring the VPN when they realize they haven’t used it in a month.

LynxTrac is free forever for up to 2 servers, no card required. If you want to try it on real infrastructure instead of reading about it: app.lynxtrac.com.

Related posts