TunnelCrib vs. a general VPN
A conventional VPN connects a user to a gateway, private subnet, or site. Routing and firewall rules then determine what the user can reach. TunnelCrib starts from a different boundary: the Central Server authorizes a requested Device and Service, the Agent exposes only approved Services, and the Client receives a temporary local Tunnel.
| Area | TunnelCrib | General VPN |
|---|---|---|
| Access unit | One approved Service | Usually a network, subnet, or gateway route |
| Client network | No broad private-network membership | Client receives a virtual interface or routed access |
| Path | Direct Client-to-Agent first; Relay fallback | Client-to-VPN gateway, often through a centralized concentrator |
| Authorization boundary | Device and Service policy before signaling | VPN identity plus routes, groups, and firewall policy |
| Persistence | Temporary per-Tunnel session | Often persistent or manually connected |
| Best fit | Support, customer, and just-in-time Service access | Broad operations, site-to-site links, and intentional network access |
Choose TunnelCrib when…
- the user needs one internal Service and nothing else
- you do not want to distribute private routes or VPN credentials
- temporary access and per-Tunnel activity events matter
- the remote Device should remain outside the user's network view
Choose General VPN when…
- the user needs broad access to several subnets or Services
- site-to-site routing is an intentional requirement
- existing firewall, route, and VPN operations are already mature
TunnelCrib is not a replacement for every VPN deployment. It is a narrower option when network-level access would violate least exposure. A VPN can remain the network transport underneath an organization while TunnelCrib handles temporary access to selected Services.
Reviewed 2026-11-03. See OpenVPN Access Server routing and the TunnelCrib security documentation.