FortiOS blocks central NAT while a single policy still references a VIP

The inbound failure is an ordering problem. With central NAT enabled, the DNAT and Virtual IPs table applies to every policy on the box, whether or not the policy mentions a VIP ^[15]. Destination translation has already happened by the time the policy is evaluated, so the policy has to match the VIP's mapped address, the internal one ^[16]. Under per-policy NAT the same rule names the VIP object as its destination ^[14]. Engineers arriving from PAN-OS carry the harder habit, because that rulebase wants the pre-NAT address and the post-NAT zone in the same rule, and on a central-NAT FortiGate, according to the dev.to write-up from Hexward Labs, that habit silently denies every inbound session ^[17].

Duplication drives converted configurations into central NAT in the first place. ASA keeps NAT in its own ordered table, object NAT and twice NAT evaluated in sections, separate from the ACLs ^[3]. PAN-OS keeps NAT in its own rulebase, separate from security rules ^[4]. In both, one NAT rule serves many policy rules ^[5]. Per-policy NAT has no way to write that down. The post's example is a single ASA twice-NAT statement covering traffic matched by fourteen ACEs ^[6]. Per-policy NAT turns that into fourteen translations, one on each converted policy ^[6]. Thirteen of them are copies of the first, and each is an edit the next time the pool changes ^[7]. Central NAT gives back one ordered SNAT table, one DNAT table, and firewall policies that only decide allow or deny ^[8]. For a greenfield FortiGate the post still recommends per-policy NAT, which is the FortiOS default and puts a `nat enable` and an optional IP pool on each policy ^[2][1].

FortiOS blocks the toggle by counting references. `set central-nat enable` answers "Cannot enable central-nat with firewall policy using vip", and the equivalent IP pool error names the policy ID ^[9][10]. The objects have to reach zero references; the post notes they do not strictly have to be deleted, though on a freshly built policy set it usually amounts to the same thing ^[11]. Its failure scenario is two days of interfaces, zones, address objects, service objects and four hundred policies, followed by editing all four hundred to strip VIP references before the mode will take ^[12]. On a new appliance the order it gives is: enable central NAT, log out and back in so the GUI redraws, then build ^[13]. Needing a fresh login before the menus change is a fair indicator of how far down the setting sits.

Getting the mode right does not make a converted SNAT table a line-for-line port. It reads top down and first match wins, the same as an ACL or an ASA NAT section ^[19]. A central SNAT entry matches on source interface, destination interface, source address, destination address, protocol, destination port and original source port ^[20]. An ASA NAT rule has no destination interface as a match key in the same way, and ASA's section order, manual NAT before auto NAT before after-auto NAT, does not map onto one flat list ^[21].

The two central tables run independently. Every VIP and DNAT rule is in effect once central NAT is on, whatever the central SNAT table contains, including one created earlier and forgotten ^[18].