Brownfield Insertion Without Changing PLC Addresses
A food and beverage plant has a flat Layer 2 network between packaging lines and the SCADA room. A FortiGate 100F sits at the IT/OT boundary, but all OT traffic currently bypasses it through an unmanaged switch. You are asked to insert a FortiGate Rugged 70F between the SCADA VLAN and line PLCs. There are 38 PLCs with fixed IPs, a dual-homed historian that polls both sides, and a vendor support tunnel that terminates on an engineering laptop. Production runs 24/6, with a 2-hour window on Sunday. The plant cannot change PLC IPs or default gateways; the SCADA server is the default gateway for some PLCs and the historian for others. Modbus TCP uses port 502, and some PLCs use Ethernet/IP. The project sponsor wants HA and inline IPS in the first phase.
1. Choose transparent versus NAT/routed deployment and HA mode. Explain the address and gateway implications and any fail-safe requirement.
Read the worked answer
Choose transparent mode first. The PLCs cannot change IPs or default gateways, and the historian dual-homing makes routed insertion risky. A transparent interface pair between the SCADA VLAN and the line switches preserves addressing and L2 adjacency while enforcing policy at the choke point.
Use an active-passive HA pair with heartbeat on a dedicated link, session sync, and a physical bypass or maintenance bypass switch so a double failure does not stop the line. Validate that the chosen FortiGate model and firmware support transparent-mode HA before committing.
Routed mode would require gateway changes or NAT, which breaks PLC-to-SCADA expectations and historian polling. If a routed VDOM is unavoidable for the IT-side historian leg, confine it to that leg and keep the OT side transparent. Do not enable NAT for Modbus; it hides the true source and complicates PLC access control.
2. How do you introduce IPS and application control without dropping Modbus or Ethernet/IP traffic? Include a commissioning sequence and rollback trigger.
Read the worked answer
Commission in stages. Week 1: inline but permit-any with logging, OT IPS and application control in monitor mode; capture Modbus and Ethernet/IP flows. Week 2: create tight policies for known master/slave pairs, keep IPS monitor-only, and review protocol anomalies. Week 3: enable IPS block only for high-confidence signatures and malformed-protocol events, not for normal Modbus function codes or Ethernet/IP CIP services.
Use FortiGuard OT signatures and per-signature actions; do not apply a generic IT IPS profile. Test PLC scan time and HMI refresh before and after. Rollback trigger: any unexplained PLC comm loss over 30 seconds, scan-time increase beyond the plant threshold, or historian data gap. On trigger, revert to the prior policy and monitor mode.
Keep the Sunday window for policy changes, not for first-time discovery. This gives protection without a blanket block that could stop production.
3. The dual-homed historian creates asymmetric routing. What design change or FortiGate features do you use?
Read the worked answer
The dual-homed historian is the main design flaw: it gives two paths between zones and can make the FortiGate see only one direction of a session, causing asymmetric routing and drops.
First, map which interface initiates each poll. If the historian polls PLCs on the OT side and is polled from IT on the other, put each leg in a separate VDOM or separate transparent pair with an explicit inter-VDOM policy, so each zone has one enforcement point. If that is not feasible, remove the unused NIC or move the IT consumer to a data replica or broker in the OT DMZ; this avoids routing changes on the PLC side.
Do not solve it with broad asymmetric-routing exceptions or by disabling RPF globally. Validate with diagnose debug flow and session tables from both directions. The goal is a single deterministic path per flow, not just a working ping.