Source NAT and destination NAT solve opposite address-translation problems on FortiGate. SNAT changes the source identity of traffic as it leaves a network; DNAT changes the destination so traffic sent to one address can reach another host or service. The basic definitions are simple, but real troubleshooting becomes harder because FortiGate can implement source translation through policy NAT, IP pools, or central SNAT, while destination translation commonly uses virtual IPs and can also be handled in central NAT mode.

The NSE 4 FortiOS 7.6 Administrator scope explicitly covers SNAT and DNAT. For administrators, the important skill is understanding the packet before and after translation, the order in which firewall and NAT rules participate, and how a rule that looks correct can still fail because interfaces, routing, policy matching, or object selection are wrong.

SNAT changes who the destination sees as the source

Outbound Internet access is the classic SNAT case. A client using a private address sends traffic toward an Internet destination. FortiGate permits the session and translates the source to an address that is routable on the external network. Replies return to the translated address, and the stateful session maps them back to the original client.

FortiGate can use the outgoing interface address for source translation or an IP pool. IP pools become important when different applications, tenants, partners, or compliance zones need predictable translated addresses. They also matter when an upstream service allowlists a specific public IP. If the wrong pool is selected, connectivity might work while the application is still rejected by the remote side because it sees an unexpected source.

The conceptual background in network address translation is useful here, but FortiGate troubleshooting must go further: identify which policy or central SNAT rule actually matched and verify the translated source in a packet capture or session record.

DNAT changes where inbound traffic is delivered

DNAT is commonly used to publish an internal service through an address reachable by external clients. FortiGate virtual IP objects map the external destination to the internal address and, where required, can also translate ports. An Internet client may connect to a public address on TCP 443 while the FortiGate forwards that session to a private server address.

Creating a VIP is not enough by itself. The translated flow must still be permitted by an appropriate firewall policy, the FortiGate must have a route toward the mapped server, and the server must have a valid return path. If the server sends replies through a different gateway, the firewall may see only one direction of the stateful session and the client experiences a timeout.

DNAT troubleshooting therefore requires two address perspectives. On the external side, capture the public destination that the client used. On the internal side, capture the mapped private destination. If the translation never appears, inspect VIP or central DNAT matching. If it appears but the server never replies, investigate the server, internal routing, host firewall, or return gateway.

Policy NAT and central NAT use different configuration models

In the traditional FortiGate model, source NAT is enabled in the IPv4 firewall policy, with the outgoing interface address or an IP pool used for translation. A destination VIP can be referenced by the policy destination. This keeps access control and translation closely associated in the same policy workflow.

Central NAT separates translation into dedicated tables. Fortinet documents a central SNAT table where rules are evaluated from top to bottom; central SNAT is applied after the security policy. Central DNAT uses VIP objects as separate translation objects rather than tying the VIP directly to the firewall policy in the same way as non-central NAT mode.

This difference matters during migration and troubleshooting. An engineer accustomed to policy NAT can look at an allow policy, see that NAT is not enabled there, and assume source translation is missing even though central SNAT is performing it elsewhere. Always establish whether central NAT is enabled before interpreting the policy GUI.

Rule order and object scope create subtle SNAT failures

Central SNAT rules are ordered. A broad rule above a specific rule can translate traffic with the wrong IP pool before the intended rule is reached. The same type of logic problem occurs in firewall policies: if traffic matches an earlier policy, a later policy with the “correct” settings is irrelevant.

Define the matching tuple clearly: source interface, destination interface, original source, destination, protocol or service characteristics, and the intended pool. Then confirm the actual matched rule using session or debug evidence. A visual review alone can miss object membership, interface zones, or address ranges that overlap.

IP pool exhaustion is another operational issue. If translation depends on a constrained range and all usable mappings are consumed, new sessions can fail even though policies and routes are correct. Capacity, port allocation behavior, and concurrent-session patterns therefore belong in NAT troubleshooting for high-volume environments.

DNAT errors often look like firewall-policy errors

A published service can fail because the VIP listens on the wrong external interface, maps the wrong address, translates the wrong port, or conflicts with another object. It can also fail because the allow policy references an incorrect source, service, or incoming interface. The fastest approach is to identify whether translation occurred before changing either configuration.

Packet sniffer evidence is powerful: if the public request reaches the FortiGate but no corresponding private request leaves toward the server, focus on VIP/DNAT and policy matching. If the translated request reaches the server and the server replies, verify that the return enters the FortiGate and is mapped back to the original session. If the return bypasses the FortiGate, fix routing rather than adding more firewall policies.

Hairpin or internal-to-published-service access can add another path to consider. Internal users may resolve a public name to the public VIP while physically sitting behind the same FortiGate. That design can work, but it requires a policy and routing/NAT model that supports the internal path. Split DNS is sometimes operationally simpler, depending on the application and network design.

NAT is stateful, so sessions matter during changes

Once a session is established, FortiGate tracks the original and translated tuple. Changing a NAT rule does not necessarily rewrite an existing session. An administrator can correct an IP pool or VIP and then mistakenly conclude the fix failed because the test connection is still using old state.

Retest with a new connection and inspect the session table when necessary. If clearing state is required, target the affected session rather than disrupting unrelated traffic. Change windows should account for applications that maintain long-lived connections because those sessions can preserve the old translation longer than a simple browser test.

NAT logging also matters for incident response and application support. If many private clients share a translated public address, logs need enough source-port and time information to map an external observation back to the correct internal session. Translation design affects not only connectivity but also traceability.

Security and architecture decisions should drive translation

Do not use NAT as a substitute for access control. Changing an address can hide internal addressing details, but security still comes from firewall policy, segmentation, identity, and inspection. Similarly, a DNAT object that makes a server reachable does not imply that every source should be allowed to use it.

Firewall fundamentals clarify why translation and filtering solve different problems. On FortiGate they interact in one stateful flow, but the policy must still express who can communicate and which services are permitted.

For design clarity, document the original tuple, translated tuple, owning firewall policy, IP pool or VIP, and expected return path for important services. This is especially valuable during migrations because a NAT rule can be technically valid while pointing to an old server, old public address, or wrong upstream circuit.

A practical SNAT/DNAT troubleshooting method

First determine whether the failure is outbound or inbound and write the expected pre-NAT and post-NAT addresses. Verify the route. Confirm whether central NAT is enabled. Identify the firewall policy that matches. Then identify the SNAT rule/IP pool or DNAT VIP that should apply and use a packet capture or debug flow to prove whether the translation occurs.

For SNAT, ask whether the remote destination sees the expected source and whether replies return. For DNAT, ask whether the published request becomes the intended private destination and whether the internal server’s reply returns through the same stateful path. If those facts are known, most FortiGate NAT incidents stop being mysterious configuration puzzles and become ordinary packet-path problems.

Keep the configuration model consistent across a team. Mixing central NAT and policy NAT assumptions in runbooks is a common source of mistakes. Before troubleshooting or reviewing a change, state which model the FortiGate uses and where engineers should expect to find the authoritative translation rules.

Design translations so they remain understandable at scale

Large environments need more than working NAT; they need predictable NAT. Group translation rules by purpose, use names that describe the owner and function of each pool or VIP, and avoid overlapping objects that make rule matching difficult to reason about. An administrator should be able to explain why a session received a particular translated address without searching through dozens of nearly identical objects.

Capacity planning matters for shared egress. Many private hosts can share a public address because transport ports distinguish sessions, but high connection rates and long-lived flows can consume available translation resources. Applications that open many short sessions, proxies, large NAT gateways, or service-provider designs deserve explicit monitoring of session and port utilization rather than waiting for intermittent connection failures.

For published services, document ownership of the public address and lifecycle of the internal server. DNAT rules often outlive the application that originally needed them. Periodically verify that each VIP still points to an active, supported service and that the firewall policy limits exposure to the intended sources and ports. Removing an abandoned mapping is both a security improvement and a troubleshooting simplification.

When several public addresses or cloud interfaces are involved, include upstream routing and address ownership in the NAT diagram. A perfect VIP cannot work if the public prefix is routed somewhere else, and a correct SNAT pool cannot receive replies if the upstream network does not route that address back to the FortiGate.