Access Gate needs a network path so that remote users, remote sites, or central management can reach it. That path is not tied to any single technology. Access Gate is transport-agnostic: it rides on whatever WAN or VPN the site already runs, and enforces access locally, at the gate, on top of it.
How you reach it
Access Gate sits behind whatever already carries traffic to the site. It does not provide or require a specific WAN or VPN, and it enforces access locally on whatever arrives. It helps to keep two layers separate here, because they are different things, not competing choices.
1. The transport: how traffic reaches the site
This is about reachability, not encryption. Access Gate is reached across your existing network like any other internal host, whether that is a routed LAN, a private WAN or MPLS backbone between sites, or the public internet. A private WAN or MPLS link is already private, so it often needs nothing else on top.
2. Encryption in transit: a VPN overlay, only if the path is not already private
If the path crosses untrusted networks, run the encrypted VPN you already use. IPSec site-to-site tunnels, OpenVPN, or WireGuard terminate on your existing firewall or router, and Access Gate lives behind them, enforcing per-enclave access on the decrypted traffic. A VPN is an overlay you run over a transport; it is not itself a transport, and MPLS is a transport, not a VPN.
The built-in Tailscale client: the one overlay Access Gate ships
For teams that want an identity-based mesh without standing up their own concentrator, Access Gate includes a built-in Tailscale client, so it can join a tailnet directly with no firewall change or recabling. This is the turnkey option and the only connectivity component Access Gate provides itself; everything above is just your existing network. See Configure Tailscale VPN on Access Gate.
Choosing an approach
There is no single right answer. Pick based on what you already run and what you need to preserve:
- Already have a firewall doing IPSec, or an OpenVPN concentrator? Keep it. Reach Access Gate behind it. Nothing to rip out.
- Multi-site with roaming engineers and no appetite for concentrators? The built-in Tailscale client is usually the fastest path, since the gate joins the mesh itself.
- Strict sovereignty or air-gapped posture? A private WAN or MPLS backbone keeps traffic off the public internet entirely, with no encrypted overlay required. Access Gate is fully on-premise and has no cloud dependency of its own, so the connectivity layer is the only place a third party could enter, and you control it.
What does not change
Regardless of how traffic reaches the gate:
- Access control is enforced per enclave, tied to a named identity, with MFA where required. See Remote Zero Trust Access.
- The session is brokered through the gate's proxy and recorded for audit.
- Nothing is installed on the PLCs, HMIs, or SCADA servers behind the gate.
The transport is a delivery detail. The security is the same in every case, and it lives at the Access Gate.