Automatic placement

With Work it out for me, a requester describes only the traffic. FireSight finds the firewalls the traffic crosses, the interfaces or zones each policy must name, and the position in each policy set (Fortinet: policy package) where the policy takes effect. Every step is recorded as text, so requesters and approvers can see why each firewall was chosen. Nothing is pushed until a person has confirmed the list.

Snapshots are never used for planning; only live connections are.

1. Find where each address lives

FireSight locates each source and destination by the longest match over:

the subnets configured on firewall interfaces (discovered on every sync);
manual IP allocations (see Regions and IP addressing);
internal routes for networks behind a site's core switch: routes whose next hop is on one of the firewall's own connected subnets and isn't another managed firewall.

An address no managed firewall owns is treated as external, such as the internet or a partner. A network that spans several locations is split, and each part is routed separately.

any is treated as the internet: only firewalls on the path to and from the default route are included.

2. Walk the path firewall by firewall

Starting on the firewall that owns the source (or where traffic from outside arrives), FireSight looks up how that firewall would forward the traffic:

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.
When the outgoing interface is an SD-WAN zone, the first matching SD-WAN rule picks the member.

When the next hop is an interface address of another managed firewall, the walk continues there, entering on that interface. That covers VPN tunnels, transit links and paths from a FortiManager-managed firewall to a standalone one. When the next hop isn't managed but the destination is behind another managed firewall, the walk resumes at that firewall, for example across an unmanaged MPLS core.

The path is shown as source → each firewall (incoming → outgoing interface) → destination. Point at a hop for the full note, such as which route or policy route was used.

3. Translate interfaces into what the policy needs

An interface in a zone becomes the zone.
An SD-WAN member becomes the SD-WAN zone.
On FortiManager, the result is matched to the management domain's (ADOM's) normalised interface for that firewall. When the mapping is missing, the deployment adds it (Adds a mapping to normalised interface …), or creates the normalised interface (Creates normalised interface …). Back-out removes exactly that mapping again. An existing mapping is never changed, because policies already using it would change meaning.

When the policy's interface differs from the firewall's own, the target shows both: Interfaces (as the policy names them) and On the firewall.

4. One target per policy set and interface pair

Each hop becomes a target: one policy set, one incoming and one outgoing interface. Each target holds only the sources and destinations that really cross it. Hops on several firewalls that share a policy set and interfaces become one target.

On FortiManager, with Install new policies only on the firewalls in the traffic path (Install On) on, the policy is installed only on the firewalls on the path. See Install On.

5. Place each target where it takes effect

FireSight walks the policy set top-down:

If an enabled policy already does the same thing for all of the traffic, the target is Already allowed and nothing is added.
Otherwise the new policy goes directly above the first enabled policy that would treat the traffic (or part of it) differently. Policies using objects FireSight can't fully resolve count as a possible overlap.
If nothing would, it goes at the bottom.

The Placement line of each target says why, for example placed above #12 "Block guest", which would otherwise block it.

Warnings

Warnings appear above the targets. The most common:

Warning	Meaning
Neither end is behind a managed FortiGate, so no firewall here sees this traffic.	Nothing to change. Check the addresses.
Both ends are behind the … interface of …, so this traffic most likely never passes through the firewall.	No policy is needed there.
… has no route to …; the outgoing interface there is unknown.	That firewall's routing table has no route. The policy would match any outgoing interface.
… has no route back to …, so the incoming interface is unknown.	The same for the incoming side.
The incoming (or outgoing) interface on … couldn't be worked out; it will match any.	The target uses `any` for that side. Consider manual placement.
Routing loops back to …; stopped tracing.	The synced routes form a loop.
… is in several policy packages; using ….	The firewall is in the scope of more than one policy set.
Policy route … uses objects or protocols FireSight can't evaluate	The policy route was considered on a best-effort basis.
'any' source (or destination) is treated as the internet	See step 1.

Leaving firewalls out

Each firewall in Firewalls and policies has a tick. Clear it to leave that firewall out; its target becomes Left out and isn't deployed. The choice is kept when you edit the request.

Limits

Placement uses routing as it was last synced. Dynamic routing (BGP, OSPF) is used as far as it appears in the routing table; SD-WAN performance SLAs, ECMP load balancing and policy routes that match on ToS aren't evaluated. A path is followed for at most 12 firewalls. When the result isn't what you need, use Choose manually.