FortiGate Segmentation Without Any-to-Any Policy Sprawl

Treat segmentation as a policy model, not a VLAN count

A network can have many VLANs and still behave like one large trust zone if the firewall allows broad east-west access between them. The purpose of segmentation is not to create more subnets; it is to create understandable boundaries where each class of device has a defined reason to communicate with another class. FortiGate can enforce those boundaries well, but only when the policy model is clearer than the accumulated exceptions.

The design should start with service classes such as user endpoints, servers, infrastructure management, voice, cameras, access control, guest access and other service devices. For each class, document the expected destinations and the business reason for those flows. This gives the firewall policy a stable vocabulary. Without that vocabulary, rules tend to be written around individual incidents and slowly become impossible to explain.

• Define trust zones by function and operational risk.
• Describe allowed communication in business terms before translating it into firewall rules.
• Use VLANs as enforcement boundaries, not as evidence that segmentation is complete.

Observe dependencies before tightening them

The safest migration path begins with evidence. Existing flat or loosely segmented networks often contain dependencies that were never documented: name resolution, time synchronization, print services, application servers, monitoring, backup, device management, authentication or vendor support paths. Blocking those flows on day one creates pressure to add emergency any-to-any access, which can become permanent after the incident is resolved.

Before enforcement, capture representative traffic and compare it with the service inventory. FortiGate logs and reporting tools can help distinguish repeatable application flows from background noise. The goal is not to authorize everything that has ever appeared in a log. It is to identify which flows are expected, who owns them, and whether they belong in the target design.

• Capture enough normal business activity to reveal recurring dependencies.
• Record source zone, destination zone, service, owner and purpose.
• Treat unexplained traffic as an investigation item, not an automatic allow rule.

Build reusable objects before building many rules

Policy sprawl often starts when administrators create rules directly from one incident at a time. A more maintainable approach uses consistent address objects, groups and service definitions that reflect the architecture. Instead of encoding individual devices into many policies, group systems by role where the risk allows it and keep names understandable to someone who was not present during the original migration.

Object discipline matters because the firewall becomes part of the operating documentation. A clear object or group can show that a policy serves DNS, monitoring, a line-of-business application or management access. Ambiguous names and duplicated objects increase the chance that a later change will extend access more broadly than intended.

• Use stable naming that communicates zone, role or service purpose.
• Prefer reusable groups when systems share the same access requirement.
• Review duplicate or stale objects before each major policy expansion.

Separate infrastructure access from user access

One of the strongest simplifications is to treat management traffic as a different trust path from ordinary user traffic. Switches, access points, firewalls, controllers, NVRs and other infrastructure should not normally be administered from every endpoint network. A defined administration path makes segmentation easier to reason about and reduces the blast radius of a compromised workstation.

The same principle applies to service devices such as cameras, access control and attendance systems. These devices may need DNS, time, a controller or a specific server, but they rarely need unrestricted access to every user or server segment. When their required flows are explicit, the policy set becomes smaller and troubleshooting becomes more predictable.

• Create an intentional path for administration and monitoring.
• Keep device-to-controller traffic separate from general user access.
• Avoid using broad internal rules as a substitute for a missing management design.

Use temporary broad access as a controlled migration tool

During a migration, a temporary broader rule can be safer than guessing every dependency in advance, but only if it is treated as temporary engineering scaffolding. The rule should have an owner, a narrow source and destination scope, logging enabled, a review date and a defined condition for removal or tightening. A broad rule without an expiry path is usually the beginning of permanent policy debt.

The practical workflow is to move a pilot group, observe the broad rule, convert confirmed flows into explicit policies, then reduce or remove the temporary access. Repeating that cycle in migration rings is slower than a single large cutover, but it keeps the network usable while steadily moving toward the target policy model.

• Limit temporary rules by zone and migration group rather than opening the whole network.
• Log and review every temporary broad rule.
• Convert observed valid flows into explicit permanent policies before the next migration ring.

Keep policy order and exceptions understandable

A firewall policy set is evaluated as an ordered decision system. As it grows, hidden overlaps can make a technically correct rule behave differently from what the administrator expects. Specific business flows should be easy to locate, while broad migration or fallback rules should be visibly exceptional and placed where they cannot silently override the intended model.

Exceptions deserve their own lifecycle. If a legacy application requires unusual access, document the owner, the reason, the affected systems and the next review date. That turns an exception into a managed risk instead of an undocumented permanent feature. Repeated exceptions can also reveal that the target architecture or standard needs revision.

• Keep narrowly defined business policies easy to identify and review.
• Document exception ownership and review dates.
• Remove shadowed, duplicated or obsolete rules as the migration matures.

Validate DNS, NAT, VPN and security-profile dependencies separately

Not every failure after segmentation is caused by the inter-VLAN policy itself. DNS, NAT behavior, remote-access or site-to-site VPN selectors, upstream allowlists and security inspection can all affect an application path. Troubleshooting becomes faster when these layers are checked separately instead of responding to every symptom by widening the firewall rule.

The same discipline applies to security profiles. Web filtering, application control, inspection and endpoint controls can expose application assumptions that were hidden in a flat environment. When a business service fails, identify whether the problem is reachability, name resolution, translation, inspection or application behavior before changing the trust boundary.

• Test name resolution and routing before changing policy scope.
• Confirm NAT and VPN behavior for flows that cross site or internet boundaries.
• Use logs to distinguish policy denial from inspection or application failure.

Measure segmentation by policy quality, not rule count

A smaller firewall policy set is not automatically safer, and a larger set is not automatically worse. The useful measures are whether rules have clear owners and purposes, whether temporary broad rules are shrinking, whether stale objects and unused policies are removed, and whether incidents can be investigated without reconstructing the architecture from memory.

Over time, reporting should answer practical questions: which zones communicate most, which policies are unused, where denies are recurring, which exceptions are aging, and whether a new service is creating unexpected east-west traffic. Those signals turn FortiGate from a packet enforcement point into part of the network governance model.

The end state is not a frozen configuration. It is a change process where new systems enter the correct zone, required flows are documented before deployment, exceptions are visible, and policy reviews keep the segmentation model aligned with the real environment.

• Track temporary-rule age and exception age.
• Review unused and unexpectedly busy policies.
• Make every new service define its network dependencies as part of go-live.