Deploy Access Gate with Fortinet FortiGate

This guide takes a Fortinet FortiGate 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. The CLI is shown; every step has an equivalent under Network and Policy & Objects in the GUI.

What you will build

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

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. Use two physical ports (or two VLAN subinterfaces on a trunk).

config system interface
    edit "admin"
        set ip 192.168.254.1 255.255.255.0
        set allowaccess ping https ssh
        set interface "port5"
        set vlanid 254
    next
    edit "ag-protect"
        set ip 100.65.0.1 255.255.255.248
        set allowaccess ping
        set interface "port1"
        set vlanid 65
    next
end

Cable the FortiGate port carrying admin to the Access Gate admin port (5) and the port carrying ag-protect 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 (out the ag-protect interface):

config router static
    edit 0
        set dst 100.64.0.0 255.255.0.0
        set gateway 100.65.0.6
        set device "ag-protect"
    next
end

Read it as: for the destination network 100.64.0.0/16, send the packet to 100.65.0.6 out ag-protect. From here on, anything addressed to a twin (overlay) address leaves the FortiGate on its protection link, arrives at the Access Gate, and the gate proxies it to the real device, so reaching a twin address is what pulls the flow through the gate.

Add a firewall policy permitting the OT subnet to ag-protect (and return) so the FortiGate forwards, rather than drops, the steered traffic.

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: set the resolver on the OT DHCP scope:

  config system dhcp server
      edit 1
          set interface "ot"
          set dns-service specify
          set dns-server1 100.65.0.6
          config ip-range
              edit 1
                  set start-ip 192.168.1.100
                  set end-ip 192.168.1.200
              next
          end
      next
  end
  

• Subdomain only: forward just secure.acme.corp to the gate with a FortiGate DNS database zone in forward mode, or add a conditional forwarder on your site DNS server. See Configuring Access Gate DNS.

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): a FortiGate policy route matches by source and sends the subnet to the gate, whatever the destination. One rule brings the subnet under the Secure Twin without touching a device:

  config router policy
      edit 1
          set input-device "ot"
          set src "192.168.1.0/255.255.255.0"
          set gateway 100.65.0.6
          set output-device "ag-protect"
      next
  end
  

  What this does: the policy route matches traffic whose source is the OT subnet and forwards it to 100.65.0.6 out ag-protect, regardless of destination, so one rule pulls the whole subnet through the gate. This is the FortiGate form of source-based routing.

• Destination-based (specific assets): reach assets by their twin addresses through the overlay route from step 2. 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 FortiGate 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 addressed two FortiGate 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 policy route or a destination route. OT traffic now flows through the Access Gate with no change to any asset.

Related

• Deploy Secure Twin with Source-Based Routing
• Configuring Access Gate DNS
• Deploy Secure Twin via Gateway NAT (L3)
• Choosing a Secure Twin deployment