This guide takes a Meraki MX security appliance (with an MS switch) from "Access Gate in the rack" to "OT traffic flowing through the gate," end to end, all from the Dashboard. 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 VLAN, and a protection port on a small dedicated subnet that carries the traffic you steer through the gate.
Reference lab
| Element | Address | Role |
|---|---|---|
| Admin VLAN | 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 subnet | 100.65.0.0/29 (VLAN 65), MX 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 VLANs
Put the admin port and the protection port on different VLANs so management traffic and steered traffic never share a broadcast domain.
- Create the VLANs in Security & SD-WAN → Configure → Addressing & VLANs:
- VLAN 254:
192.168.254.0/24, MX IP192.168.254.1(admin). - VLAN 65:
100.65.0.0/29, MX IP100.65.0.1(protection).
- VLAN 254:
- Assign the switch ports in Switch → Ports on the MS:
- Access port in VLAN 254 → cable to the Access Gate admin port (5).
- Access port in VLAN 65 → cable to the Access Gate protection port (1).
The admin interface takes a DHCP lease from the admin VLAN, 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 one static route in Security & SD-WAN → Configure → Routing (Static routes) so that any traffic destined for that range is forwarded to 100.65.0.6, the Access Gate's protection port:
- Subnet:
100.64.0.0/16 - Next hop IP:
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: in Addressing & VLANs, edit the OT VLAN's DHCP and set Custom nameservers to
100.65.0.6. Every device on that VLAN then resolves through the gate. - Subdomain only: the MX does not do 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. Destination-based secures what goes to an asset. Either way the Access Gate translates between the asset's real address and its twin.
On Meraki, use destination-based. It is one static route, it behaves the same on MX and MS, and it steers every client on every VLAN. The MX also has a source-based option, but it only catches traffic the MX has no route for, so it will not pull OT traffic to your other local VLANs through the gate.
Destination-based: securing what goes to an asset (use this)
The overlay route from step 2 already covers every twin. To scope one asset, add a Static Route in Security & SD-WAN → Configure → Routing:
- Subnet:
100.64.1.10/32 - Next hop IP:
100.65.0.6 - Active: Always active
Reach an asset by its twin address or DNS name and the flow goes through the gate, whoever sent it. This is the gateway NAT (L3) pattern.
Two things to get right. The twin range must not overlap any VLAN the MX owns or any existing static route, since connected and more specific routes win and the traffic would quietly skip the gate. And leave Active on Always active: with ping tracking, a gate that stops answering withdraws the route, traffic falls through to the default path, and you get a silent bypass instead of a clean outage.
Where you can change how an asset is addressed, modifying IPs migrates one device at a time with no routing change at all.
Source-based: securing what comes from the OT subnet
The MX has no policy-based routing on the LAN, but it does have source-based default routing (MX 15.4+, VLANs enabled). In Security & SD-WAN → Configure → Addressing & VLANs, choose Add source-based route, pick the OT VLAN, set the next-hop type to LAN and the address to 100.65.0.6.
Read the limit before you rely on it: a source-based default route only applies to destinations the MX has no route for, and it applies to the whole VLAN, not per host. It covers traffic leaving the site. It does not cover OT to IT inside it, because the IT VLAN is already in the routing table.
For east-west OT to IT, reach the IT service by its twin, or terminate the OT subnet on an upstream L3 device, a Catalyst switch or a FortiGate, and apply source-based routing there.
Gateway relocation: the gate becomes the subnet's gateway
The strongest option, and the most invasive. Remove the OT VLAN from the MX addressing table and terminate that subnet on the Access Gate instead. The gate becomes the gateway for the enclave hosts and runs DHCP for them. On the MX, add a static route for the enclave subnet pointing at the gate's transit address. If your MS stack owns the VLAN interface, remove it there instead and route the subnet to the gate over a transit VLAN.
This enforces everything leaving the enclave, inter-VLAN included, with no reliance on twin addressing. It needs a maintenance window and it makes the Access Gate a hard dependency for that subnet, so keep it for enclaves that are small and clearly bounded.
5. Verify the full path
From an OT device, reach an asset by its DNS name or twin address:
ping plc-line-1.secure.acme.corp # from a client that resolves via 100.65.0.6
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.
Then run traceroute to the asset's real address. It should not pass through the gate. That is expected, and it tells you exactly how much bypass you still have: anything that keeps using the real address is unenforced. Test from a client inside the VLAN, not from the Meraki dashboard.
What lives where
The MX holds one thing: a static route that says, in effect, "traffic for the overlay range, hand it 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 MX, and none of it goes there.
That separation is worth saying out loud to the network team, because "we need to change your security appliance" 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 VLANs on the MX, cabled the gate to two MS ports on two subnets (admin VLAN + protection /29), addressed the gate at 100.65.0.6, routed the overlay to it, pointed DNS at its resolver, and steered traffic by destination. OT traffic now flows through the Access Gate with no change to any asset.