Network address translation on FortiGate is part of packet handling, but it should not be confused with the decision to permit traffic. A firewall policy establishes whether a flow is allowed; NAT changes the address or port representation used as that flow crosses a boundary. FortiOS supports source and destination translation in several forms, and current 7.6 releases provide both policy-based source NAT and a separate Central SNAT table. Understanding which model is active is essential for administrators working with the FortiGate 7.6 administration<\/a> scope.<\/p>\n The most reliable NAT designs begin with a routing and addressing requirement. Ask what address must be visible on the far side, whether return traffic can find that address, whether multiple internal systems may share it, and whether a published server needs destination translation. Only then choose the FortiGate mechanism. This keeps translation from becoming a collection of trial-and-error toggles.<\/p>\n Source NAT changes the source address of traffic as it leaves a boundary. It is commonly used when private addresses reach the internet or when a downstream network expects connections from a defined pool. Destination NAT changes the destination, commonly to publish an internal service behind a public or otherwise translated address. The underlying NAT concepts<\/a> remain useful regardless of vendor.<\/p>\n Routing still determines where FortiGate intends to send the packet, and firewall policy still determines whether that flow is permitted. Translation can affect the values used at different processing stages, but it does not replace either function. Troubleshooting becomes much easier when the operator asks four separate questions: did the packet arrive, where will it route, which policy permits it, and what translation is applied?<\/p>\n This separation also improves change review. A request to \u201cNAT this server\u201d is incomplete unless it states which traffic may reach the server and from where. Publishing a destination without an appropriately scoped firewall policy can expose more than intended, while creating an allow rule without the required translation can leave the service unreachable.<\/p>\n In the common profile-based policy model, an IPv4 firewall policy can enable NAT for accepted traffic. The outgoing interface address may be used, or an IP pool can provide one or more translated source addresses. This model keeps the access rule and its outbound source translation close together and is easy to understand for many branch and internet-access designs.<\/p>\n Interface-address SNAT is appropriate when the external interface address is the desired source and scale permits port translation to multiplex clients. IP pools are useful when traffic must originate from a dedicated public range, when upstream systems allowlist specific addresses, or when different internal populations need distinct translated identities.<\/p>\n The choice should be visible in documentation. If one application is expected to appear from a particular public address, record that dependency with the policy and upstream design. Otherwise, a later administrator may simplify the NAT setting and unknowingly break a partner allowlist or audit assumption.<\/p>\n Central SNAT moves source-translation logic into a separate ordered table. Fortinet\u2019s FortiOS 7.6 documentation describes Central SNAT as a way to control translation with greater granularity by matching attributes such as source, destination, interfaces, and ports and then selecting the appropriate IP pool. The entries are evaluated top down.<\/p>\n When Central SNAT is enabled, the NAT option in IPv4 policies is not the mechanism used for source translation; administrators work with the central SNAT map instead. In policy-based NGFW mode, central NAT behavior is assumed. That distinction is critical when a policy appears to allow traffic but an operator cannot find the expected NAT configuration in the policy itself.<\/p>\n A separate table also creates a separate ordering problem. A broad Central SNAT entry placed above a narrow application-specific entry can capture traffic first and use the wrong pool. Review the translation table with the same discipline as the firewall policy: specific requirements, understandable names, documented ownership, and deliberate ordering.<\/p>\n An IP pool is more than a list of public addresses. It can represent a business identity to external systems, distribute translations across a range, or support one-to-one requirements depending on mode. Decide whether external parties need to distinguish applications or tenants and whether port capacity is sufficient for the number of simultaneous translated sessions.<\/p>\n Port exhaustion is a practical risk when many internal sessions share a limited translated address space. Modern web applications can create many concurrent connections per client, so \u201cone public IP for many users\u201d should be evaluated against real session volume rather than user count alone. Monitoring session and NAT behavior helps reveal pressure before users experience intermittent failures.<\/p>\n Where multiple pools exist, keep the selection logic easy to explain. If finance traffic, server egress, and ordinary user browsing require different public identities, create conditions that map clearly to those populations. Hidden dependencies on source ports or incidental routing details make later troubleshooting fragile.<\/p>\n FortiGate commonly uses virtual IP objects to map an external destination to an internal server or service. A VIP can translate an address and, where needed, specific ports. The corresponding firewall policy should then permit only the source populations and services that are actually required.<\/p>\n Publishing a service changes the security boundary. The internal application now receives traffic addressed to a reachable external identity, so the design should include patching, segmentation, authentication, logging, and relevant security profiles rather than treating DNAT as the entire solution. Destination translation makes a path possible; it does not make the application safe.<\/p>\n Administrators should also consider DNS and return routing. External users may resolve a public name while internal users resolve a private address, or both populations may use the same name with different network paths. The server\u2019s replies must return through a path that preserves the stateful session. NAT issues often expose routing assumptions that were invisible before the service was published.<\/p>\n Traffic can enter and leave through less obvious paths than a simple inside-to-WAN diagram. Internal clients may access a service through its external address, remote networks may overlap with local ranges, or traffic may cross multiple translation domains. These cases require careful reasoning about the address at each stage and the interface path selected by routing.<\/p>\n Hairpin access should be designed rather than discovered accidentally. Determine whether internal clients should use internal DNS, whether the FortiGate must translate the destination back toward the internal server, and whether source translation is also needed to keep the return path through the firewall. Test the full TCP or application session, not merely reachability to the translated address.<\/p>\n Overlapping networks are harder because the same address can represent different endpoints in different contexts. NAT can sometimes create a usable translated namespace, but documentation becomes critical. Record the original and translated prefixes and make policy objects unambiguous so later administrators do not assume an address means the same thing on both sides.<\/p>\n Multiple WAN links complicate source translation because the correct public source may depend on the selected egress member. If a session moves to a different underlay, the address expected by remote services can change. That matters for partner allowlists, IP-based reputation, and applications that dislike source changes.<\/p>\n Policy SNAT using an outgoing interface address can naturally follow the selected interface, while explicit pools and Central SNAT require deliberate mapping. Administrators should verify how their rules behave for every eligible SD-WAN member and whether a failover can present a different source identity.<\/p>\n This is one reason routing, SD-WAN rules, and NAT should be reviewed together. A translation rule that is correct on the preferred path can become wrong after a health-check failure steers traffic elsewhere. Failover testing should include the translated source observed by the destination, not just whether packets continue to pass.<\/p>\n Do not troubleshoot NAT from configuration screens alone. Capture the original client address, the route and matching policy, the selected NAT rule or pool, and the address observed after translation. Session information and traffic logs can show the values FortiGate actually used, while packet captures on appropriate interfaces can confirm what entered and left the device.<\/p>\n When outbound traffic fails, distinguish \u201cno policy match\u201d from \u201cwrong translated address\u201d from \u201cno return route.\u201d If the far side sees the packet but replies to an address that is not routed back to FortiGate, changing the firewall allow rule will not help. If the session is translated from an unexpected pool, inspect Central SNAT ordering or policy NAT settings.<\/p>\nSeparate SNAT, DNAT, routing, and security policy<\/h3>\n
Use policy SNAT for straightforward outbound translation<\/h3>\n
Understand when Central SNAT changes the workflow<\/h3>\n
Design IP pools around identity and capacity<\/h3>\n
Use VIPs and DNAT to publish services deliberately<\/h3>\n
Account for hairpin and overlapping-path scenarios<\/h3>\n
Recognize the interaction between NAT and SD-WAN<\/h3>\n
Use logs and packet evidence to verify translation<\/h3>\n