{
  "id": 9039965,
  "title": "Central NAT on FortiGate: what changes, what breaks, and the order you have to do it in",
  "url": "https://urgent.news/2026/09/21/central-nat-on-fortigate-what-changes-what-breaks-and-the-order-you",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-21T23:45:08.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/hexwardlabs/central-nat-on-fortigate-what-changes-what-breaks-and-the-order-you-have-to-do-it-in-42nf"
  },
  "original_language": "en",
  "account": "Central NAT on FortiGate presents several challenges when migrating policies from platforms like ASA or Palo Alto. The primary issue is that FortiGate defaults to per-policy NAT, while the sources lack this configuration. Per-policy NAT requires each translated policy to explicitly include the NAT mapping, which becomes cumbersome when the same NAT statement applies to multiple ACEs. To resolve this, central NAT is implemented, which brings back the consistent matching model of a single SNAT and DNAT table. However, enabling central NAT requires careful planning as it cannot be toggled on if policies already reference VIPs or IP pools. Moreover, when moving from per-policy to central NAT, the destination address in policies must be updated to the mapped address instead of the external VIP. This change can cause issues during cut-over, particularly with per-policy NAT referencing VIP objects, as the FortiGate will interpret the destination address based on the internal mapped address instead of the external one. This discrepancy may lead to failed session connections and necessitates a thorough review of the entire policy set to identify and correct any misconfigurations.",
  "summary": "First note in a series on cross-vendor firewall migration: where two platforms disagree, verified against vendor docs and real migrations. If you are moving a policy set onto FortiGate from an ASA or a Palo Alto, there is a decision you have to make before you write a single rule, and FortiOS will not let you unmake it afterwards without tearing the policies down. This is about central NAT. Not…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}