Architecture Overview

Access Gate is a VNF (virtualized network function): the security stack is decoupled from proprietary hardware, so it runs as a VM on the x86 host you already own. That has two consequences worth planning around.

• You choose the footprint. The same function runs on an appliance, a mini-PC at a remote site, or a VM on an existing hypervisor. Security no longer depends on a specific box.
• The host becomes a services platform. Because the gate already sits in the traffic path (or beside it), the same host can run the secure services that need to pull OT in: remote access, protocol gateways, DNS and time, file sharing, a historian or dashboards, and an update server, each mediated by the same identity and access policies.

This is why deployment choices below are about coverage and impact, not about buying more hardware. See Deploy a PKI with Access Gate for one service modeled this way.

In-Line is the simplest way to deploy an Access Gate. The appliance is placed in the traffic path and carries the network's VLANs, routes, and core switch itself.

• The Access Gate connects to access switch (for example Cisco Catalyst, Fortinet or Netgear switches) on a trunk port (tagged VLANs) and carries those VLANs through the gate.
• Machines on the network use the Access Gate as their gateway.

Because the gate is inline and carries the VLANs, you can deploy the secure twin: a routed Layer 3 twin of an asset's address that lets Access Gate intercept and control its traffic. As for any in-line network device, so plan for availability (for example a high-availability pair) and redundancy.

Machines reach the twin in one of two ways:

• Direct configuration on the machine, using the twin's IP address.
• NAT between VLANs.

By design, this configuration can still allows traffic between machines over their underlay addresses if the traffic happens "below" the control point. Hence the point 👇

Active (L3) intra-VLAN interception

Traffic between two machines in the same VLAN is switched at Layer 2 and never reaches the gateway, so intercepting it needs one of these patterns:

• A twin IP on the flows to secure, for example a gateway system talking to a collector.
• Passive listening only, the recommended case for isochronous or broadcast systems, where an inline L3 hop would break timing or multicast.
• Migrating a system to another VLAN, for example a SCADA control station, and replacing it with an ARP proxy on the Access Gate in its original VLAN.

Lollipop is the low-impact option. Access Gate connects beside the network instead of carrying its VLANs and trunks, and traffic is steered to it logically rather than physically. It fits when you already have a managed switch and can introduce a few routes, and you want the least possible disruption to a live site.

When Lollipop fits

Choose Lollipop when full carry is more than you need right now:

• You have a managed switch and can add routes: enforcement is redirected via DNS and routing, so no re-cabling onto a trunk port is required.
• You want minimal disruption: the existing routes, VLANs, and IP addressing stay intact, which keeps the change small on a brownfield site.
• You are protecting specific access paths: Lollipop enforces the flows you point at it, rather than carrying every VLAN through the gate.

How it behaves once deployed:

• Adjacent placement: the appliance sits beside the network rather than in the core path.
• Software-defined interception: traffic is redirected via DNS and routing.
• Graceful degradation: the network keeps functioning if the appliance is offline.
• No physical network changes: nothing on the switch fabric has to be re-wired to start.

When you need the fullest coverage and control instead, deploy In-Line so the gate carries the VLANs and trunks itself. Lollipop and In-Line are two points on the same dial: adjacent for lower impact, in-line for fuller carry.

How Traffic Flows

Without Access Gate (underlay network): Client → Asset

With Access Gate (overlay network active): Client → Access Gate (proxy) → Asset

The client never reaches the asset directly; it always goes through the proxy. Access Gate terminates the client session and opens a separate, second session to the asset (shown in the diagram below).

Because every session is brokered this way, Access Gate can enforce identity-based authentication, access control, and session logging in front of assets that have none of their own.

How it works

• Visibility: Access Gate observes traffic through a NetFlow feed from the router (NetFlow is for discovery and monitoring only, not enforcement). See Traffic monitoring and NetFlow export.
• Overlay: it builds an overlay IP space (commonly 100.64.0.0/16) that maps protected services to proxy-enforced paths.
• Enforcement: DNS resolves protected hostnames to overlay IPs, and routing directs that overlay traffic through Access Gate.
• Assets remain on their original underlay network, unchanged.

Benefits

• Nothing added to the core traffic path
• No physical network changes required
• Simple to deploy and remove
• The network continues to operate normally if Access Gate is offline

What it is: Access Gate becomes the single controlled entry point for users coming from outside the site. Remote users connect via VPN (Tailscale/WireGuard) to Access Gate, and Access Gate brokers access to protected assets through its proxy. See Remote Zero Trust Access and Privileged Access Management for the per-user models.

Why this mode exists (the problem it solves): Remote access to OT / sensitive IT usually ends up as one of these patterns:

• Flat VPN into the LAN
• Jump box / RDP server
• Vendor remote tools

What Bastion Mode improves

• Least-privilege remote access
• Stronger boundary
• Auditability
• Operational safety
• Vendor access without permanent exposure

When to choose it

• You need remote access for operators, IT, vendors, or incident response.
• You want to avoid “VPN = inside the LAN.”
• You need consistent logs and evidence for NIS2/CMMC/NIST-style controls.

Access Gate acts as a VPN gateway, enabling remote users to securely reach on-site assets. The network flow looks like:

Remote Users → VPN (Tailscale / WireGuard) → Access Gate → Protected Assets

What it is: Multiple Access Gates form an encrypted mesh between sites. Each site keeps its local underlay unchanged, but selected assets/services become reachable across sites through controlled, identity-based policies.

Why this mode exists (the problem it solves) Organizations with multiple sites often end up with:

• Site-to-site VPNs that are flat
• Complex network engineering
• Inconsistent controls per site

What the mesh improves

• Zero trust across sites: Alice on site A is granted access to one specific CNC on site B, verified by identity, with no lateral reach to anything else. See Cross-site entity sharing.
• Standardized security posture
• Faster rollout
• Unified logging and documentation for auditors

Typical use cases

• Central engineering team needs controlled access to machines across plants.
• Shared services (historians, patch repositories, backup, monitoring) must be reachable securely.
• M&A / multi-entity environments where networks must remain separate but collaboration is required.
• You want “connectivity as policy” instead of “connectivity as routing.”

Multiple Access Gates interconnect over VPN to provide secure, site-to-site connectivity:

Site A Assets ← Access Gate A ←→ Access Gate B → Site B Assets

Requires: Site Mesh feature configuration, see Cross-site entity sharing.