How it works
The requester describes the traffic. FireSight does the tracing.
Sources, destinations and a service are all a requester enters. FireSight works out where the rule has to go by forwarding the traffic the way your FortiGates would, one firewall at a time.
The placement walk
Illustration based on the demo network's Rome to Singapore SSH request, which crosses two ADOMs over IPsec hub-and-spoke. In the same demo, Bari sends traffic out of wan2 because of a policy route, and Sydney picks a member of the virtual-wan-link SD-WAN zone through an SD-WAN rule.
Automatic placement
Five steps from addresses to positioned policies
-
Find where each address lives
FireSight uses FortiGate interface subnets, IP allocations, and internal routes that point at a site's core switch. Addresses that no managed FortiGate owns are treated as external, such as the internet or partners. Host names are resolved through DNS first.
-
Walk the path firewall by firewall
At each FortiGate it follows the same order the firewall does:
- Policy routes first, matched on source, destination, protocol, port and incoming interface;
- then the routing table of the incoming interface's VRF, longest prefix first;
- and when the egress is an SD-WAN zone, the first matching SD-WAN rule picks the member.
When the next hop is another managed FortiGate, the walk continues there, including from a FortiManager-managed firewall to a standalone one. That covers IPsec hub-and-spoke designs and transit firewalls.
-
Translate interfaces into what the policy needs
An interface in a zone becomes the zone, and an SD-WAN member becomes the SD-WAN zone. In FortiManager the result is matched to the ADOM's normalised interface for that device. When a mapping is missing, the deployment adds it, or creates the normalised interface, and back-out removes exactly that mapping again. An existing mapping is never changed, because policies already using it would change meaning.
-
Create one target per policy package and interface pair
Each target holds only the sources and destinations that really cross it, and FortiManager's Install On is limited to the firewalls on the path, even when the package installs to more.
-
Place each target where it takes effect
Usually that's above the first policy that would treat the traffic differently. Firewalls where an existing policy already allows the traffic are marked as needing no change.
What the requester sees
A traced path to check, and firewalls to confirm
The requester sees the path, the firewalls and the interface translations, and can leave any firewall out.
- They must confirm the firewalls before submitting. The confirmation is recorded and shown to approvers.
- The new rule is checked live against each package at its exact position, including whether it would shadow rules below.
- If the rule base changes after confirmation or approval, FireSight refuses to submit or deploy until the request is re-planned.
- Placement can also be chosen manually: ADOM, package, interfaces and position.
After placement
Approval, deployment and back-out
Approval
The request goes to every chain that applies at once: the ADOM's chain, plus any chains added by conditions. All must approve. Approval chains
Separation of duties
Requesters can't approve their own rules, nobody approves two stages of one chain, and approvers can't deploy. Details
Deployment
Through FortiManager with an ADOM revision and workspace locking, or to a standalone FortiGate with a backup and a disabled-first push. Deployment
Back-out
Every write is stored with its previous value. Back out restores it; rules with a remove after date expire on their own. Back-out
See FireSight on your own rule base
We'll walk you through placement, the audit, approval chains and back-out using the built-in demo estate, and talk through what connecting your FortiManager or FortiGates would involve.
