Deploy Access Gate with MikroTik

Wire an Access Gate to a MikroTik RouterOS router end to end: two ports on two subnets, the overlay route, DNS, and source-based (mangle + routing table) or destination-based routing, so OT traffic flows through the gate.

This guide takes a MikroTik RouterOS router from "Access Gate in the rack" to "OT traffic flowing through the gate," end to end. You connect two ports, give the gate a place on the network, and choose how traffic reaches it. Nothing on the OT devices changes. Commands are RouterOS 7.

What you will build

Access Gate cabled to an existing router by two ports: an admin port on the admin VLAN and a protection port on a dedicated /29 subnet

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`	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`, router `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 subnets

Put the admin port and the protection port on different subnets so management traffic and steered traffic never share a broadcast domain. Address one interface for admin, one for protection.

# ether5 -> Access Gate admin port (5)   |  ether2 -> Access Gate protection port (1)
/ip address add address=192.168.254.1/24 interface=ether5 comment="AG admin"
/ip address add address=100.65.0.1/29    interface=ether2 comment="AG protection"

Cable ether5 to the Access Gate admin port (5) and ether2 to the 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 route so that any traffic destined for that range is forwarded via 100.65.0.6, the Access Gate's protection port:

/ip route add dst-address=100.64.0.0/16 gateway=100.65.0.6 comment="Secure Twin overlay"

Read it as: for the destination network 100.64.0.0/16, the gateway (next hop) is 100.65.0.6. From here on, anything addressed to a twin (overlay) address leaves the router, arrives at 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: hand the resolver to clients over DHCP:

/ip dhcp-server network set [find where address=192.168.1.0/24] dns-server=100.65.0.6

Subdomain only: RouterOS forwards a single zone with a FWD static entry, so only secure.acme.corp goes to the gate and everything else keeps your existing resolver:
```
/ip dns static add type=FWD name=secure.acme.corp match-subdomain=yes forward-to=100.65.0.6
```
See Configuring Access Gate DNS for the split-DNS pattern.

4. Steer traffic through the gate

Choose based on whether you want to pull a whole subnet or reach specific assets.

Source-based (whole OT subnet): mark everything sourced from the OT subnet and route the marked traffic to the gate. One rule brings the subnet under the Secure Twin without touching a device:
```
/ip firewall mangle add chain=prerouting src-address=192.168.1.0/24 \
    action=mark-routing new-routing-mark=via-ag passthrough=yes comment="steer OT to AG"
/ip route add dst-address=0.0.0.0/0 gateway=100.65.0.6 routing-table=via-ag
```
What this does: the mangle rule tags every packet from the OT subnet with the via-ag routing mark, and the route in that routing table sends all marked traffic to 100.65.0.6, so one rule pulls the whole subnet through the gate. This is the RouterOS form of source-based routing.
Destination-based (specific assets): reach assets by their twin addresses through the overlay route from step 2, or add a route for a specific destination via 100.65.0.6. Use this for per-flow control; see gateway NAT (L3).

5. Verify the full path

From an OT device, reach a destination exactly as before. The router now steers the flow through the gate on the way out.

# from the OT device (192.168.1.10)
ping 192.168.2.20

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.

Recap

You addressed two RouterOS interfaces on two subnets (admin VLAN + protection /29), placed the gate at 100.65.0.6, routed the overlay to it, pointed DNS at its resolver, and steered traffic with a mangle-marked routing table or a destination route. OT traffic now flows through the Access Gate with no change to any asset.