Deploy Access Gate with Cisco Catalyst

Wire an Access Gate to a Cisco Catalyst switch end to end: two ports on two subnets, the overlay route, DNS, and source-based (PBR) or destination-based routing, so OT traffic flows through the gate.

This guide takes a Cisco Catalyst L3 switch 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.

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 switch 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`, switch `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. The admin VLAN is your existing management network; the protection subnet is a dedicated /29.

! Admin VLAN (management) and a dedicated protection subnet
vlan 254
 name ADMIN
vlan 65
 name AG-PROTECT
!
interface Vlan254
 ip address 192.168.254.1 255.255.255.0
interface Vlan65
 ip address 100.65.0.1 255.255.255.248
!
! Access Gate admin port  -> switchport in the admin VLAN
interface GigabitEthernet1/0/5
 description Access-Gate-ADMIN (port 5)
 switchport mode access
 switchport access vlan 254
!
! Access Gate protection port -> switchport in the protection VLAN
interface GigabitEthernet1/0/1
 description Access-Gate-PROTECT (port 1)
 switchport mode access
 switchport access vlan 65

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

ip route 100.64.0.0 255.255.0.0 100.65.0.6

Read it as: for the destination network 100.64.0.0/16, send the packet to 100.65.0.6. From here on, anything addressed to a twin (overlay) address leaves the switch, 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 pool OT
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.1
 dns-server 100.65.0.6

Subdomain only: keep your existing DNS and forward just secure.acme.corp to the gate with a conditional forwarder on your site DNS server (Windows DNS, BIND, or Infoblox). 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): policy-route everything sourced from the OT subnet to the gate with PBR. One rule brings the subnet under the Secure Twin without touching a device:
```
ip access-list extended OT-TRAFFIC
 permit ip 192.168.1.0 0.0.0.255 any
!
route-map STEER-OT permit 10
 match ip address OT-TRAFFIC
 set ip next-hop 100.65.0.6
!
interface Vlan1
 description OT SVI
 ip policy route-map STEER-OT
```
What this does: the OT-TRAFFIC ACL matches every packet whose source is the OT subnet; the route-map sets the next hop of those packets to 100.65.0.6, the gate's protection port; and applying the route-map to the OT SVI means every packet arriving from OT is policy-routed to the gate whatever its destination. This is the Catalyst 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 switch now steers the flow through the 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.

Recap

You cabled two Catalyst 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 with PBR or a destination route. OT traffic now flows through the Access Gate with no change to any asset.