Deploy Access Gate with Cisco Meraki

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

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.

1. Create the VLANs in Security & SD-WAN → Configure → Addressing & VLANs:
   • VLAN 254: 192.168.254.0/24, MX IP 192.168.254.1 (admin).
   • VLAN 65: 100.65.0.0/29, MX IP 100.65.0.1 (protection).
2. 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.6 on your site DNS server (Windows DNS, BIND, or Infoblox). See Configuring Access Gate DNS.

4. Steer traffic through the gate

The MX does not offer general source-based policy routing, so on Meraki you steer by destination, which is exactly what the Secure Twin is designed for.

• Destination-based (recommended on Meraki): the overlay static route from step 2 pulls all 100.64.0.0/16 traffic through the gate. Reach each asset by its twin address or its DNS name, and the flow goes through the Access Gate. This is the gateway NAT (L3) pattern.
• Per-asset via Twin IPs: where you can change how an asset is addressed, modifying IPs migrates one device at a time with no routing change at all.

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.

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.

Related

• Deploy Secure Twin via Gateway NAT (L3)
• Configuring Access Gate DNS
• Deploy Secure Twin with Twin IPs
• Choosing a Secure Twin deployment