To deploy a Secure Twin via IP NAT, add a destination-NAT rule on the L3 gateway that rewrites the chosen flows from the peer's real address to its overlay twin, then route the overlay range to the Access Gate. The asset keeps talking to the real address and never learns it was redirected. The NAT rules live on your router, so this method is best-effort.
When you cannot change the asset and it is reached by IP rather than name, the redirection can live entirely in the network. The router or L3 gateway the traffic already passes through rewrites the destination of the flows you choose onto the Secure Twin overlay, pushing them through the Access Gate. The asset keeps talking to its peer's real address; the gateway does the rest.
What problem does IP NAT solve?
The asset (an HMI on the OT VLAN) targets its peer's real address (192.168.2.20), exactly as it always has. You cannot, or do not want to, reconfigure it, and it is reached by IP, not by name. The one place you do control is the L3 gateway its traffic already crosses.
So you make the gateway do the work: it destination-NATs the flows you choose, rewriting 192.168.2.20 to its overlay twin 100.64.2.20, and forwards them to the Access Gate. Nothing on the asset changes, the redirect is a single rule on the router.
This method only works where the two ends sit in different subnets, so their traffic actually crosses the gateway. Two devices on the same segment ARP for each other and switch frames directly; the router never sees those packets and a DNAT rule on it can never match them. For that case use ARP NAT (L2), which intercepts at Layer 2 instead.
Because the redirect sits on the L3 boundary between an OT zone and an IT zone, it is also the natural place to draw an IEC 62443 conduit between the two, and to produce the access-control evidence NIS2 Article 21 and NERC CIP-005 ask for.
How does IP NAT work?
Three pieces work together, all on the gateway and the Access Gate, none on the asset:
- The overlay range defines a 1:1 mapping (a "binat") between each underlay address and its Secure Twin overlay address. In this lab the server subnet
192.168.2.Xcorresponds to100.64.2.Xon the overlay. - A destination-NAT rule on the L3 gateway rewrites the destination of the selected flows from the underlay address to its overlay twin, so the packet is now addressed to the overlay.
- A route to the Access Gate carries the overlay range to the gate, which binats the overlay address back to the real device, enforces enclave policy, and returns the reply through the gateway.
Because the rewrite happens on the gateway, the asset's own address, gateway, and routing are left exactly as they were, it never learns its traffic was redirected.
Reference Lab
The example carries an OT device reaching a server on another subnet, which is the case this method is built for: the two ends are separated by a routed hop, and that hop is the one thing you control.
| Element | Address | Role |
|---|---|---|
| HMI | 192.168.1.10 | OT device (source), unchanged |
| Historian | 192.168.2.20 underlay, 100.64.2.20 overlay | Server the HMI talks to, on another subnet |
| Router / L3 gateway | 192.168.1.1 (OT), 192.168.2.1 (server) | Destination-NATs selected flows onto the overlay |
| Access Gate | interconnect 100.65.0.4/29, server overlay 100.64.2.0/24 | Overlay identities, policy enforcement |
The mapping preserves the last two octets: 192.168.2.X on the server subnet corresponds to 100.64.2.X on the overlay, so the historian (192.168.2.20) has the overlay twin 100.64.2.20.
How to deploy a Secure Twin via IP NAT (L3), step by step
1. Define the overlay range
Create a subnet in Access Gate for the server network and give it an overlay, so each server gets a Secure Twin address. In this lab the underlay 192.168.2.0/24 maps to the overlay 100.64.2.0/24. For defining ranges and the Secure Twin port in the UI, see Twin IPs.
2. Destination-NAT the flow on the L3 gateway
On the router, add a DNAT rule that rewrites the destination of the flows you want gated from the underlay address to its overlay twin. Scope it to the specific flow so unrelated traffic is untouched.
# On the L3 gateway: DNAT traffic from the HMI bound for the historian onto its overlay twin
iptables -t nat -A PREROUTING -s 192.168.1.10 -d 192.168.2.20 -j DNAT --to-destination 100.64.2.20
The DNAT happens before the routing decision, so the packet is now addressed to 100.64.2.20 when the gateway picks its next hop.
3. Route the overlay range to the Access Gate
Send the overlay range to the Access Gate, so the freshly-NATed packet is forwarded to the gate rather than on to the server subnet.
ip route add 100.64.2.0/24 via 100.65.0.4 # Access Gate interconnect
4. Verify the full path
The HMI reaches the historian at its real address, unchanged, and the gateway silently redirects the flow through the Access Gate.
ping -c3 192.168.2.20 # from the HMI (192.168.1.10)
The Access Gate binats 100.64.2.20 back to the real historian (192.168.2.20), applies policy, and returns the reply through the gateway. A reduced TTL on the response confirms the flow traversed the gate rather than being routed straight through.
What the full traffic path looks like
HMI (192.168.1.10) [targets the REAL server 192.168.2.20, unchanged]
-> Router / L3 gateway (192.168.1.1) [DNAT 192.168.2.20 -> 100.64.2.20, route to Access Gate]
-> Access Gate (interconnect 100.65.0.4/29, policy enforcement) [binat 100.64.2.20 -> 192.168.2.20]
-> Historian (192.168.2.20)
-> and back, un-NATed to the HMI
From the HMI's point of view, it reached the historian at the usual address. In reality the L3 gateway rewrote the destination onto the overlay and the session passed through the Access Gate, with no change to either device's address, gateway, or routing.
When to use this, and when not to
The redirect lives entirely in the L3 gateway. The asset is never reconfigured and no name resolution is involved: the router simply rewrites the destination of the flows you choose.
This fits when you own the L3 gateway but not the assets, the peer is reached by IP, and there is a routed hop in the path. Bear in mind that the NAT rules are yours to build, maintain, and document, and that support for them is best-effort or premium rather than standard.
Use another way when you can touch the assets at all. Twin DNS and Twin IPs migrate one asset at a time and are fully supported; Source-Based Routing moves a whole subnet with a routing policy rather than a NAT rule, and is also fully supported. Where there is no L3 hop between the two devices, this method cannot work at all and ARP NAT (L2) does it on the switch instead. See Choosing your Secure Twin deployment.