Deploy Secure Twin via Gateway NAT (L3)

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.

The Goal

The asset (zt-a) targets its peer's real address (10.0.0.3), 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 10.0.0.3 to its overlay twin 100.64.100.3, and forwards them to the Access Gate. Nothing on the asset changes, the redirect is a single rule on the router.

How It Works

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 it is last-octet-preserving: 10.0.0.X on the underlay corresponds to 100.64.100.X on 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 reuses the same flat device subnet as the modifying IPs and ARP proxying (L2) guides: a host behind a Router, with the Access Gate reachable over the overlay in a lollipop architecture.

The mapping is last-octet-preserving: 10.0.0.X on the local subnet corresponds to 100.64.100.X on the overlay, so zt-b (10.0.0.3) has the overlay twin 100.64.100.3.

Step by Step

1. Define the overlay range

The overlay range is a range of addresses reserved for assets protected by Access Gate, each overlay address mapping 1:1 to one underlay address. The default is 100.64.0.0/16, part of the CGNAT reserved range. In this lab the overlay 100.64.100.0/24 maps to the underlay 10.0.0.0/24. See Deploy Secure Twin with Twin IPs for defining ranges and the Secure Twin port in the UI.

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 zt-a bound for zt-b onto its overlay twin
iptables -t nat -A PREROUTING -s 10.0.0.4 -d 10.0.0.3 -j DNAT --to-destination 100.64.100.3

The DNAT happens before the routing decision, so the packet is now addressed to 100.64.100.3 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 back onto the local subnet.

ip route add 100.64.100.0/24 via <access-gate-ip>

4. Verify the full path

zt-a pings its peer at its real address, unchanged, and the gateway silently redirects the flow through the Access Gate.

ping -c3 10.0.0.3

The Access Gate binats 100.64.100.3 back to the real zt-b (10.0.0.3), applies policy, and returns the reply through the gateway. A reduced TTL on the response confirms the flow traversed the gate rather than staying local.

The Complete Path

zt-a (10.0.0.4)  [targets the REAL peer 10.0.0.3, unchanged]
  -> Router / L3 gateway (10.0.0.1)  [DNAT 10.0.0.3 -> 100.64.100.3, route to Access Gate]
  -> Access Gate (Secure Twin 100.64.100.4/24, policy enforcement)  [binat 100.64.100.3 -> 10.0.0.3]
  -> zt-b (10.0.0.3)
  -> and back, un-NATed to zt-a

From zt-a's point of view, it reached its neighbor 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.

Redirection That Lives in the Gateway

Gateway NAT keeps the redirect off the endpoints entirely: the asset is never reconfigured and no DNS is involved, the router simply rewrites the destination of the flows you choose. Reach for it when you own the L3 gateway but not the assets, and traffic is reached by IP.

If you can change the asset, modifying IPs is simpler; if the asset is reached by name, use DNS; if there is no L3 hop between the two devices at all, ARP proxying (L2) does it on the switch.