On a Cisco Meraki MX, you connect Access Gate with two ports, add one static route for the twin addresses, and add one source-based route that sends your machine VLAN's traffic to the gate. Nothing changes on the machines, and removing the source-based route undoes it.
What you will build
The examples use these addresses. Replace them with yours.
| What | Example |
|---|---|
| Admin VLAN | VLAN 254, 192.168.254.0/24, MX 192.168.254.1 |
| Dedicated VLAN for the gate | VLAN 65, 100.65.0.0/29: MX 100.65.0.1, gate 100.65.0.6 |
| Twin addresses | 100.64.0.0/16 |
| Your machine subnet | 192.168.1.0/24, PLC 192.168.1.10 (twin address 100.64.1.10) |
| Machine names | secure.acme.corp, answered by the gate at 100.65.0.6 |
1. Connect two ports
- In Security & SD-WAN → Configure → Addressing & VLANs, create two 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(the gate's own VLAN).
- VLAN 254:
- In Switch → Ports on the MS, set one access port in VLAN 254 and one in VLAN 65.
- Cable the VLAN 254 port to the Access Gate admin port (5) and the VLAN 65 port to its protection port (1).
The admin port takes an address from your admin VLAN over DHCP, or uses 10.0.0.1 after about a minute if there is none. You can set it to a fixed address, such as 192.168.254.50, from the console.
2. Add the route for twin addresses
Access Gate gives each machine a twin address in 100.64.0.0/16. In Security & SD-WAN → Configure → Routing (Static routes), add one static route:
- Subnet:
100.64.0.0/16 - Next hop IP:
100.65.0.6 - Active: Always active
Anything sent to a twin address now goes to the gate, which passes it on to the real machine. Nothing uses these addresses yet, so this changes nothing on its own.
3. Switch with one rule
In Security & SD-WAN → Configure → Addressing & VLANs, click Add source-based route:
- Source: your machine VLAN (
192.168.1.0/24) - Next hop type: LAN
- Next hop IP:
100.65.0.6
Your machines keep their address, gateway and settings. To undo: delete the source-based route.
4. Check it works
From a machine on that VLAN (not from the Meraki Dashboard, whose own pings ignore the rule), reach something outside the site, exactly as before:
ping 8.8.8.8
In the Access Gate console, the flow now appears under its enclave. Access Gate starts in a dry run, so it shows what it would block without blocking anything until you approve the rules.
If nothing shows up, check that the MX has an ARP entry for 100.65.0.6 (the gate answers on its VLAN), and take a packet capture on the gate's VLAN in the Dashboard.
Other options
Cover traffic between your local VLANs: reach machines by name
The source-based route does not catch traffic between VLANs on the same MX. To bring that traffic through the gate, have people and systems connect to the machine's twin address or name instead of its real address. The route from step 2 then carries every such connection to the gate, whoever sent it.
The simplest way is names. Access Gate answers DNS at 100.65.0.6 and gives each machine a name that points to its twin address. In Addressing & VLANs, edit the DHCP settings of the VLAN your users and systems are on, and set Custom nameservers to 100.65.0.6. Devices on that VLAN then resolve plc-line-1.secure.acme.corp to 100.64.1.10.
To keep your own DNS instead, see the next option.
For one rule that also covers traffic between local VLANs, route the machine subnet on an upstream device that supports policy routing, a Catalyst switch or a FortiGate, and apply the rule there.
Keep your own DNS and forward one subdomain
The MX does not forward a single DNS zone to another server. 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 Give your machines easy names.
Protect one machine only
The route in step 2 already covers every twin address. To cover a single machine instead, add a static route in Security & SD-WAN → Configure → Routing for its twin address only:
- Subnet:
100.64.1.10/32 - Next hop IP:
100.65.0.6 - Active: Always active
People and systems then reach that machine by 100.64.1.10 or its name. Where you can change how a machine is addressed, see Protect a machine you reach by its address. For how this pattern works in general, see Redirect traffic with your router's NAT.
Make the gate the machine subnet's gateway
The strongest option, and the most invasive. Remove the machine VLAN from the MX addressing table and terminate that subnet on the Access Gate instead. The gate becomes the gateway for those machines and runs DHCP for them. On the MX, add a static route for the machine 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 covers everything leaving the subnet, traffic to other VLANs included, without twin addresses. It needs a maintenance window and makes the Access Gate a hard dependency for that subnet, so keep it for small, clearly bounded groups of machines.
Which traffic this covers
Access Gate handles any packet that reaches it, in either direction. Coverage is only a matter of getting traffic to the gate:
- IT to machines, and machines on other VLANs: covered when they connect by twin address or name.
- Machines to the internet, the WAN and other sites: covered by the source-based route in step 3.
- Machines to IT on the same MX: covered when the machine reaches the IT service by its twin address. The source-based route does not cover it.
- Machines on the same VLAN, with no router in between: routing never sees this traffic. See Redirect traffic on your switches.
What stays on the MX
The MX holds one static route and one source-based route, written once. Who may reach which machine, sign-in, session recording, encryption and logs all live on Access Gate. When the network team asks what changes on the security appliance, the answer is: two routes, once.