Deploy Secure Twin with Source-Based Routing

When you need to bring a whole network under the Secure Twin, rather than one flow or one device, source-based routing is the least-effort way in. Instead of matching individual destinations, the router is told that everything sourced from an origin subnet, for example an OT VLAN, is routed via the Access Gate. One policy on the router pulls the entire network through the gate; not a single device is reconfigured.

The Goal

The most common driver is migration. A network, typically OT, must come under Zero-Trust enforcement, but the devices on it cannot be reconfigured: no new IP, no new gateway, no agent. Often you also want to move protection at the granularity of a whole VLAN or subnet at once, not device by device.

Source-based routing solves this at the router. You keep every OT device exactly as it is, and you change one thing in the network: the router's policy for traffic leaving that subnet. From then on, the Access Gate sees the network's East-West and North-South flows, applies enclave policy, identity, and encryption, and represents each device to the rest of the network by its overlay identity. Migrating a VLAN under the Secure Twin becomes a single routing change you can stage and roll back.

How It Works

Two pieces cooperate, and neither of them is on the devices:

• The overlay range gives the origin subnet a Secure Twin: a 1:1 mapping (a "binat") from each underlay address to an overlay address. In this lab it is last-octet-preserving, 192.168.1.X on the OT underlay maps to 100.64.1.X on the overlay.
• A source-based route on the router matches traffic by its source (the whole 192.168.1.0/24 OT subnet) and sends it to the Access Gate over the interconnect, regardless of destination. Access Gate applies enclave policy and encryption, presents the device to the far side by its overlay identity, and NATs the return path back to the real device.

Because the decision is made on the router by source address, the entire subnet is redirected with one rule, and the devices keep their own IP, gateway, and routing untouched.

Reference Lab

The example carries an OT network reaching an IT service, the classic case that source-based routing is built for.

The overlay is last-octet-preserving: 192.168.1.X on the OT subnet corresponds to 100.64.1.X on the overlay, so the PLC (192.168.1.10) is represented as 100.64.1.10.

Step by Step

1. Configure the origin subnet in Access Gate

Create a subnet in Access Gate for the OT network and give it an overlay, so each device gets a Secure Twin address. In this lab the OT underlay 192.168.1.0/24 maps to the overlay 100.64.1.0/24. For defining subnets, overlays, and the Secure Twin port in the UI, see Deploy Secure Twin with Twin IPs.

2. Source-route the origin network via Access Gate

On the router, add a source-based (policy) route: everything sourced from the OT subnet is sent to the Access Gate over the interconnect, whatever its destination.

# On the router: policy-route everything sourced from the OT subnet via Access Gate
ip rule add from 192.168.1.0/24 table 100
ip route add default via 100.65.0.4 table 100   # Access Gate interconnect

Only the origin subnet is matched, so traffic from other networks is untouched. On a vendor router this is the same idea expressed as a route-map / policy-based-routing rule keyed on the source prefix.

3. Verify the full path

From an OT device, reach the IT server exactly as before. The router now steers the flow through the Access Gate on the way out.

ping -c3 192.168.2.20   # from the OT device (192.168.1.10)

On the Access Gate, the flow appears under the OT enclave with the device's overlay identity (100.64.1.10); policy, identity, and encryption apply before the packet is forwarded to 192.168.2.20, and the reply is NATed back to the real device.

The Complete Path

OT device (192.168.1.10)  [reaches IT server 192.168.2.20 as usual]
  -> Router / L3 gateway  [source-based route: from 192.168.1.0/24 -> Access Gate interconnect]
  -> Access Gate (enclave policy, identity, encryption)  [presents OT device as overlay 100.64.1.10]
  -> IT server (192.168.2.20)  [sees the OT device by its overlay identity]
  -> and back through Access Gate, NATed to the OT device (192.168.1.10)

From the OT device's point of view, it reached the IT server on its usual address. In reality the router steered the whole subnet's traffic through the Access Gate, which enforced enclave policy and encryption and represented the device by its overlay identity, with no change to any device's address, gateway, or routing.

One Rule to Migrate a Whole Network

Source-based routing is the method to reach for when the unit of change is a network, not a device: a single router policy brings an entire subnet or VLAN under the Secure Twin, and it can be staged and rolled back like any routing change. It pairs naturally with device- or VLAN-level migrations where the endpoints must stay exactly as they are.

If you need per-flow control instead of a whole subnet, use gateway NAT (L3); if you can change the asset, modifying IPs is simpler; and where the two devices share a segment with no L3 hop between them, ARP proxying (L2) does it at Layer 2.