FortiGate Architecture Planning

Security

FortiGate Architecture Planning

Introduction

FortiGate projects work best when firewall policy, NAT, VPN, routing, SD-WAN, security profiles and logging are treated as one architecture instead of independent configuration tasks.

Assessment and planning

Start with traffic flows. Map Internet-to-service exposure, branch-to-headquarters traffic, user-to-cloud access, VPN-to-application flows and management paths. The flow map makes it easier to identify unnecessary exposure, duplicate policy and unexpected trust relationships.

Architecture decisions

Keep policy intent clear. Use naming conventions, comments, objects and zones that explain why a rule exists. Separate management, user, server and guest flows where appropriate. Remove or consolidate obsolete rules rather than letting the configuration become an archive of historical exceptions.

Implementation considerations

NAT and VIP design should be documented with the service they expose, the security policy that permits it and the expected logging. Outbound NAT is equally important because address translation affects troubleshooting and sometimes security decisions.

Operations and evidence

VPN and SD-WAN need operational tests. Tunnel state alone does not prove application success. Validate routing, MTU/MSS, throughput, health checks, path failover and the behavior of real applications. Record the expected outcome of each WAN failure condition.

Practical scenario

A two-WAN deployment may use health checks and controlled path selection while site-to-site VPNs provide remote connectivity. The design should state exactly which traffic moves when one link degrades and which metrics the operations team watches.

Common mistakes

Common mistakes include treating policy cleanup as cosmetic, ignoring unused objects, changing routing without checking NAT dependencies and testing VPNs only with ping. A production firewall should be understandable before the next urgent incident arrives.

Implementation checklist

Review policy order, objects, NAT/VIP, routing, VPN, SD-WAN, security profiles, logging and administrative access. Test failover with application traffic. Capture the approved configuration and document ownership of future changes.

Document the current state before change.
Assign ownership for important controls and alerts.
Test the failure, restore or access path that matters.
Update runbooks after meaningful changes.
Review evidence and improve the operating model.

XOOPIE perspective: use this guidance as a starting point and adapt the final design to the organization’s actual environment, security requirements, budget and operating model.

Implementation approach

Start with an approved flow map and current configuration snapshot. Review policies, objects, routes, NAT, VPN and SD-WAN health checks before making changes. Test one change at a time and define rollback. For larger redesigns, build a staging or secondary-path validation plan where practical.

Evidence to collect

Collect policy hits, VPN state, interface statistics, routing neighbors, health-check results and relevant security events. Configuration backups should be available before changes. When troubleshooting performance, capture the traffic path, MTU/MSS behavior and endpoint evidence instead of assuming the firewall is the only factor.

Operational handover

Document the policy naming model, important objects, VPN peers, NAT/VIP dependencies, administrative roles and monitoring alerts. Include a quick troubleshooting path for common issues so the next engineer does not need to rediscover the architecture.

Change management

High-risk firewall changes should have a peer review and maintenance window. Record the expected policy effect and test traffic after the change. Review unused or shadowed rules periodically so the security boundary stays understandable.

When to reassess

Reassess before major firmware upgrades, firewall replacement, WAN redesign, new Internet-facing services or repeated VPN/SD-WAN incidents.

Conclusion

Firewall architecture is strongest when policy, routing and operations are readable by the people who maintain it. A clean, documented configuration supports faster troubleshooting and safer changes.

Questions to ask before implementation

Before implementing this capability, ask whether the organization has clear ownership, measurable success criteria, documented dependencies and a safe rollback or recovery path. For this topic, useful evidence includes policy intent, routing behavior, VPN health and SD-WAN failover. These questions keep the project focused on operational value rather than configuration volume.

How to measure the outcome

For every important firewall change, define the expected flow before touching configuration. After implementation, validate both the intended path and the failure path. Measure whether sessions establish correctly, whether routes converge, whether health checks behave as expected and whether relevant security events reach the logging platform. This approach avoids declaring success based on a single ping test or a configuration screenshot.

Closing perspective

The most sustainable technology changes are the ones that can be explained, monitored, tested and handed over. A design should remain useful after the original project team leaves because the operating model, ownership and evidence are clear. Use the article as a starting point, then adapt the final implementation to the organization’s actual environment and requirements.

Operational review

An operational review should compare the implemented environment with the documented design. Review ownership, monitoring coverage, failure handling, change history and recovery assumptions. Look for workarounds that have become permanent. Where an engineer repeatedly fixes the same problem manually, treat that as evidence of an architecture or process improvement opportunity. A useful review also checks whether a second engineer can understand the system without relying on undocumented tribal knowledge. Capture a short list of actions, assign owners and define the evidence that will show the action is complete. This creates a feedback loop between delivery and operations and helps the environment improve rather than simply accumulate configuration.

What good looks like

The capability should be understandable to the people who operate it, observable when it changes state, documented well enough to support a second engineer, and recoverable when a dependency fails. Those qualities are more durable than any single product choice and should remain part of the acceptance criteria.

FortiGate Architecture Planning