This guide takes a Ubiquiti UniFi gateway (UDM / UXG with a UniFi switch) from "Access Gate in the rack" to "OT traffic flowing through the gate," end to end, from the UniFi Network application. You connect two ports, give the gate a place on the network, and choose how traffic reaches it. Nothing on the OT devices changes.
What you will build
The Access Gate is a physical appliance you cable to two ports on two different subnets: an admin port on your admin network, and a protection port on a small dedicated network that carries the traffic you steer through the gate.
Reference lab
| Element | Address | Role |
|---|---|---|
| Admin network | 192.168.254.0/24 (VLAN 254) | Where the Access Gate web console is reached |
| Access Gate admin port (5) | DHCP, or 192.168.254.50 | Management interface |
| Protection network | 100.65.0.0/29 (VLAN 65), gateway 100.65.0.1 | Point-to-point link to the gate |
| Access Gate protection port (1) | 100.65.0.6 | Traffic in/out, overlay, and DNS resolver |
| Secure Twin overlay | 100.64.0.0/16 | Parallel space; each asset gets a 1:1 twin |
| OT subnet | 192.168.1.0/24, PLC 192.168.1.10 (twin 100.64.1.10) | Assets, unchanged |
| DNS zone | secure.acme.corp, resolver 100.65.0.6 | Names for assets |
1. Physical connectivity: two ports, two networks
Put the admin port and the protection port on different networks so management traffic and steered traffic never share a broadcast domain.
- Create the networks in Settings → Networks:
Admin: VLAN 254,192.168.254.0/24, gateway192.168.254.1.AG-Protect: VLAN 65,100.65.0.0/29, gateway100.65.0.1.
- Assign the switch ports in Ports → [port] → Port Manager:
- A port with Native VLAN = Admin → cable to the Access Gate admin port (5).
- A port with Native VLAN = AG-Protect → cable to the Access Gate protection port (1).
The admin interface takes a DHCP lease from the admin network, or defaults to 10.0.0.1 after about a minute if there is none; set it static to 192.168.254.50 from the console if you prefer a fixed address.
2. Give the overlay a route
The Secure Twin lives in the 100.64.0.0/16 overlay, the parallel address space where every asset gets a twin. Add a static route in Settings → Routing → Static Routes so that any traffic destined for that range is forwarded to 100.65.0.6, the Access Gate's protection port:
- Destination:
100.64.0.0/16 - Next hop:
100.65.0.6
From here on, anything addressed to a twin (overlay) address is sent to the Access Gate on its protection port, and the gate proxies it to the real device, so reaching a twin address is what pulls the flow through the gate.
3. Point DNS at the Access Gate
The gate hosts a resolver at 100.65.0.6 that turns asset names into overlay addresses. You can use it for everything or only for a subdomain.
- Everything: edit the OT network in Settings → Networks, and under DHCP → DNS Server set a manual value of
100.65.0.6. Every device on that network then resolves through the gate. - Subdomain only: the UniFi gateway does not do reliable per-zone conditional forwarding, so keep your existing DNS and add a conditional forwarder for
secure.acme.corp → 100.65.0.6on your site DNS server (Windows DNS, BIND, or Infoblox). See Configuring Access Gate DNS.
4. Steer traffic through the gate
Two ways to get traffic to the gate. Source-based secures what comes from a network: you match on where the packet started. Destination-based secures what goes to an asset: you match on where it is headed. Use one, the other, or both, depending on what you want to protect. Either way the Access Gate translates between the asset's real address and its twin.
Source-based: securing what comes from the OT subnet
Add a Policy-Based Route in Settings → Routing → Policy-Based Routes:
- Source: OT network (
192.168.1.0/24) - Destination: any
- Next hop / interface:
AG-Protect(100.65.0.6)
Every packet leaving the OT network goes to the gate, whatever its destination. One rule brings the whole subnet under the Secure Twin without touching a device. This is the UniFi form of source-based routing.
Destination-based: securing what goes to an asset
Add a Static Route in Settings → Routing → Static Routes:
- Destination:
100.64.1.10/32 - Next hop:
100.65.0.6
The overlay route from step 2 already covers every twin; this scopes it to one asset. Anything addressed to a twin goes to the gate, whoever sent it. See gateway NAT (L3).
5. Verify the full path
From an OT device, reach a destination exactly as before. The gateway now steers the flow through the Access Gate on the way out.
ping 192.168.2.20 # from the OT device (192.168.1.10)
On the Access Gate, the flow appears under its enclave with the device's overlay identity (100.64.1.10); identity, policy, and encryption apply before the packet is forwarded, and the reply is NATed back to the real device.
You can also test the IT to OT direction: from an IT client, reach an OT asset by its twin address or DNS name (ping 100.64.1.10). The overlay route carries that packet to the gate, which proxies it to the real device.
What lives where
The UniFi gateway holds one thing: a rule that says, in effect, "these packets, hand them to this next hop." It is static. You write it once and never touch it again, even as enclave policy changes from week to week.
Everything else lives on the Access Gate: authentication, the enclave ACLs, proxying, credential injection, session recording, TLS termination, and logging. None of that is expressible on the UniFi gateway, and none of it goes there.
That separation is worth saying out loud to the network team, because "we need to configure your gateway" sounds alarming until they see it is a handoff rule, not a policy engine. Their change control sees one route, once.
Recap
You created two networks in UniFi, cabled the gate to two switch ports on two subnets (admin network + protection /29), addressed the gate at 100.65.0.6, routed the overlay to it, pointed DNS at its resolver, and steered traffic by source, by destination, or both. OT traffic now flows through the Access Gate with no change to any asset.