Network address translation (NAT) on FortiGate is not one general switch that makes all connectivity work. Source NAT changes the address information that a downstream network sees for an initiating client; destination NAT redirects traffic addressed to a published destination. Both operate as part of a larger session path involving interface selection, routing, security policy and return traffic. Fortinet’s active FortiOS 7.6 Administrator exam tests both SNAT and DNAT options in firewall policies, including virtual IPs (VIPs).
The decisive troubleshooting question is which address a given device sees at each hop. A firewall can appear to allow the right application while the upstream network sees a different source or the internal server is never reached at the expected translated destination. Draw the path before changing NAT values.
Trace traffic before and after translation
Consider a private client at 10.10.20.25 browsing a public site. The FortiGate may translate the client’s source address to an egress IP. The external site sends its response to that translated address, and the FortiGate uses session state to return the traffic to the original client. The relevant design includes source network, chosen outgoing interface, translation mode and how many concurrent flows must be supported.
A host’s TCP/IP stack and the external firewall log may show different addresses for the same connection. That difference is expected when NAT is applied. A diagnostic trace should label original source, translated source, destination, transport ports and selected egress. Without both views, an engineer can mistakenly troubleshoot an application allowlist that was written for the wrong address.
Fortinet’s FortiOS 7.6 dynamic SNAT documentation describes IP pools and how external address selection occurs. An IP pool can be useful when sessions should originate from defined addresses rather than the physical interface address, but it creates an address-management and capacity responsibility.
Choose the right source NAT strategy
Using the outgoing interface address is a common choice when clients share an internet uplink, but it is not ideal for every environment. A business may require one application to originate from a particular public IP because a partner allowlists that address. An IP pool can provide that consistency when supported and correctly configured. An administrator should understand how changes to egress route selection interact with the address that a third party expects.
For a pool serving many concurrent connections, resource use and port availability matter. FortiOS has different pool types and distribution behavior; it is unsafe to assume that any address range supplies unlimited sessions or that a pool used for one traffic pattern suits another. Diagnose exhaustion or mismatches with observed session and NAT evidence rather than simply adding more broad policies.
If a branch has two WAN links, a particular connection may need a consistent source identity for upstream services. Failover can change the public path and source address, causing existing sessions or external allowlists to stop matching. The problem may be a necessary side effect of the topology rather than a defect in the firewall’s permit policy.
Understand destination NAT through virtual IPs
A virtual IP maps a reachable external address, and optionally a service or port, to an internal address or service. This is central to publishing an internal resource through a FortiGate. The FortiOS 7.6 destination NAT reference explains the role of VIPs, including static and service-specific mappings. Mapping an address is not a security authorization by itself; a matching firewall rule still governs the relevant traffic.
Suppose a public address on TCP 443 should forward to an internal HTTPS server. The design must account for the original external destination, VIP mapping, intended internal server and return path. The virtual IP object, route to the internal host and policy matching behavior need to agree. A configuration that maps to the wrong service port can produce a timeout even if the packet reaches the correct appliance.
Publishing a service should always minimize exposure. A VIP for a management application should not become a reason to permit every internet source unless that access is genuinely required. Source restrictions, appropriate security profiles and logging help control who can reach the translated resource.
Know why firewall policy behavior changes with VIPs
FortiGate policies must be understood alongside DNAT behavior. Fortinet describes special VIP matching in its firewall policy documentation. A standard deny policy and an accept policy with a VIP can match differently from two policies that use only ordinary nontranslated address objects. When implementing exceptions to a published service, verify the documented VIP policy evaluation and the setting needed for the deny rule to match the translated traffic.
For instance, an organization publishes an application to all external clients but must block a specified source range. If the engineer merely creates a broad deny without considering VIP match processing, that rule may not behave as expected. Review actual traffic logs and the FortiOS 7.6 policy match reference before selecting a fix. Do not rely solely on a rule’s visual position in the GUI.
A port-forwarding design can also be complicated by multiple VIPs and overlapping external address or service definitions. Avoid ambiguous overlaps unless the supported behavior has been documented and tested. Clear mapping tables are easier for another administrator to audit and restore.
Distinguish published destination, server and client paths
When an internal server is reachable locally but not from outside, begin with external reachability to the published address, then examine whether traffic reaches the FortiGate, which VIP applies and what happens after translation. A policy may allow the translated session but the internal server’s host firewall, route or listener can still reject it. A successful firewall log is not proof that the application process accepted the connection.
Return traffic is essential. A server replying through a second gateway may send responses that do not traverse the FortiGate that maintains the NAT session. Such asymmetry can resemble a broken VIP even though the initial DNAT mapping was correct. Inspect the server’s default gateway and actual response path before changing translation settings.
In a test, use a client outside the network or another approved segment that follows the real publishing path. Testing the published public address from inside may involve different routing or hairpin NAT behavior and should not be assumed to represent the internet client’s experience.
Use diagnostic evidence without obscuring addresses
FortiOS session tables, policy logs and packet diagnostics can expose original and translated address information, subject to the chosen tool and logging setup. Label each address explicitly. Some tools present the pre-NAT value, some show the translated value or both. Search filters based on the wrong representation can produce a false conclusion that the session was never seen.
A bounded packet capture on the external side can test whether the request reaches the expected IP. A capture on the internal path can test whether it leaves for the actual server. A flow trace can show which route, policy and NAT decisions were applied, subject to hardware offload and trace limitations. Those observations distinguish translation mistakes from a server that is simply offline.
Do not change a production NAT rule while leaving active sessions unexamined. Stateful connections may retain earlier session decisions. Document the expected behavior for new and existing sessions and use a controlled maintenance window when a published business service is involved.
Combine NAT with routing and security policy carefully
NAT cannot compensate for a nonexistent route, and a route cannot grant permission absent the required firewall policy. The correct order of investigation follows the packet: arrival, route selection, match, translation, forwarding, response and reverse mapping. In a multi-WAN environment, SD-WAN behavior can alter the route and source NAT outcome at the same time.
The operational goal is a predictable session, not translation for its own sake. Some internal traffic does not need NAT at all, and unnecessary translation can obscure client identity for security monitoring or application controls. The ability to justify when translation is required is more useful than blindly applying it to every policy.
Relate these decisions to IPsec site-to-site VPN traffic where applicable: a route-based tunnel can have its own addressing and policy expectations, and translation should be enabled only when the network design calls for it, such as overlapping source networks. This is a contextual relationship, not a claim that every VPN needs NAT.
Practice two failure cases with competing explanations
Case A: outbound client traffic reaches a partner only when using the primary ISP. Possible causes include a partner allowlist tied to the old translated source, an incorrect pool on the backup path, or return routing. Compare the original client, pool address, selected egress and partner-observed source to distinguish them.
Case B: an external client reaches a published VIP but HTTPS fails. Possible causes include an incorrect port mapping, missing or nonmatching accept rule, an unreachable internal host, or a reply returning through another gateway. Capture the packet at the public and private sides and correlate policy/NAT evidence. Do not expand access globally just to test one cause.
If you can articulate the original and translated address at each step and identify the evidence that would eliminate the wrong hypothesis, you have learned what the FortiOS 7.6 NAT task is really testing: controlled connectivity with precise forwarding and authorization, not a memorized sequence of translation-screen fields.