A utility is redesigning its NAT strategy across dozens of firewall policies that each need slightly different source-NAT behavior for field, substation, and back-office traffic. The network architect wants NAT rules managed as their own centralized rule set, separate from and independently ordered from the firewall policies that permit the traffic. Which FortiOS 7.6 NAT model matches this requirement, as opposed to configuring NAT directly on each firewall policy?
Select an answer to reveal the explanation.
Short Explanation
Picture two ways to manage NAT: baked into each individual policy, or pulled out into its own separate rulebook. That second approach — a standalone, independently ordered NAT rule set — is exactly what central NAT gives you.
Full Explanation
FortiOS supports two NAT architectures: firewall-policy NAT, where each policy carries its own NAT settings inline and NAT behavior is tied one-to-one to that specific policy's match conditions, and central NAT, where SNAT and DNAT rules live in their own dedicated, independently ordered rule tables, separate from the firewall policy list that handles permit/deny decisions. Central NAT is the model built for exactly the scenario described, an architect who wants NAT logic managed, audited, and reordered as its own coherent structure rather than duplicated piecemeal across dozens of individual policies. The claim that firewall-policy NAT settings already live in a shared central table is incorrect; that per-policy model is precisely the opposite of centralization, since each policy's NAT configuration is scoped to that policy alone. IP pool overload is a specific SNAT translation behavior (many-to-one address sharing) that can be used under either NAT model, it answers 'how are addresses shared,' not 'where do NAT rules live,' so it doesn't address the architectural question being asked. Virtual IP grouping is a way to organize DNAT objects, but source NAT under central NAT is handled through central SNAT policies, not through VIP groups, so describing it as having no SNAT equivalent misstates how central NAT is actually structured. To validate which model is in effect, an engineer checks whether central NAT is enabled system-wide and whether SNAT/DNAT rules appear in their own dedicated central NAT policy lists rather than inside individual firewall policies.