FortiGate Source NAT Configuration for Internet Access

Internal network endpoints use private IPv4 addresses defined by RFC 1918. Public internet routers drop private IP addresses. Therefore, outbound client traffic must undergo Source Network Address Translation (SNAT) before exiting your boundary firewall. Performing a FortiGate source NAT configuration ensures that internal clients can access web resources while masking their private network structure behind routed public addresses.

This technical tutorial walks you through configuring policy-based Source NAT on a FortiGate firewall running FortiOS. You will learn how to configure NAT using both the outgoing interface address and dedicated dynamic IP pools, inspect the session table, and troubleshoot translation issues using CLI diagnostic tools.

Real-Life Scenario

An enterprise organization requires internet access for two distinct internal networks connected to a FortiGate firewall:

• General LAN Workstations (10.0.10.0/24): Standard user devices requiring web browsing access. Their outbound connections should translate directly to the IP address assigned to the WAN interface.
• Application Servers (10.0.20.0/24): Internal servers requiring outbound internet access for updates and API connectivity. To avoid reputation issues and keep client browsing traffic isolated, these servers must translate to a dedicated block of public IP addresses (IP Pool).

The FortiGate connects to the Internet Service Provider (ISP) on interface port1 using a static public address range in 198.51.100.0/24.

Lab Topology

The network topology below illustrates the traffic path from internal subnets through the FortiGate firewall to the ISP gateway.

[ General Workstations ] 
    (10.0.10.0/24)
          |
          +------> [ port2: 10.0.10.1 ]
                                      |
[ App Servers ]                       |----> [ FortiGate Firewall ] ----> [ port1: 198.51.100.2/24 ] ----> [ ISP Router: 198.51.100.1 ] ----> Internet
    (10.0.20.0/24)                    |
          +------> [ port3: 10.0.20.1 ]

Example Addressing and Objects

The following table lists the lab values and firewall objects used throughout this tutorial. Adapt these values to match your production environment.

Prerequisites

Verify that your firewall meets these baseline requirements before configuring Source NAT:

• The WAN interface is configured with an active IPv4 address and link state is up.
• A default static route exists pointing outbound traffic to the ISP next-hop gateway (for example, 0.0.0.0/0 via 198.51.100.1 on port1).
• Internal client devices are configured with default gateways pointing to their respective FortiGate interface IPs.
• Administrative access to the GUI or CLI is available.

Step-by-Step GUI Configuration

In FortiOS, policy NAT allows you to enable translation directly inside the firewall policy. This section details how to build address objects, IP pools, and firewall policies in the FortiGate GUI.

Step 1: Create Firewall Address Objects

1. Navigate to Policy & Objects > Addresses.
2. Click Create New > Address.
3. Configure the LAN address object:
   • Name: net-LAN-10.0.10.0_24
   • Type: Subnet
   • IP/Netmask: 10.0.10.0/24
   • Interface: Any (or select port2)
4. Click OK.
5. Repeat the process for the server subnet:
   • Name: net-Servers-10.0.20.0_24
   • Type: Subnet
   • IP/Netmask: 10.0.20.0/24
   • Interface: Any (or select port3)
6. Click OK.

Step 2: Create an Outbound IP Pool

When you need traffic to translate to a designated public IP rather than the primary interface address, create an IP Pool object.

1. Navigate to Policy & Objects > IP Pools.
2. Click Create New > IP Pool.
3. Configure the pool parameters:
   • Name: ippool-WAN-Outbound
   • Type: Overload (Port Address Translation / PAT)
   • External IP Range: 198.51.100.10 - 198.51.100.12
4. Click OK.

Note: The Overload type uses Port Address Translation, allowing thousands of internal connections to share a small range of public IPs. The One-to-One type maps single internal IPs to single public IPs without port translation.

Step 3: Configure Firewall Policy Using Outgoing Interface Address

This policy allows workstation traffic to reach the internet, translating the source IP to the port1 IP address (198.51.100.2).

1. Navigate to Policy & Objects > Firewall Policy.
2. Click Create New.
3. Enter the policy details:
   • Name: LAN-to-WAN-SNAT
   • Incoming Interface: port2
   • Outgoing Interface: port1
   • Source: net-LAN-10.0.10.0_24
   • Destination: all
   • Schedule: always
   • Service: ALL
   • Action: ACCEPT
4. Scroll to the Firewall / Network Options section.
5. Toggle NAT to the enabled position.
6. Select Use Outgoing Interface Address.
7. Click OK to save the policy.

Step 4: Configure Firewall Policy Using an IP Pool

This policy allows server traffic to reach the internet using the pool of public IP addresses created in Step 2.

1. Navigate to Policy & Objects > Firewall Policy.
2. Click Create New.
3. Enter the policy details:
   • Name: Servers-to-WAN-PoolNAT
   • Incoming Interface: port3
   • Outgoing Interface: port1
   • Source: net-Servers-10.0.20.0_24
   • Destination: all
   • Schedule: always
   • Service: ALL
   • Action: ACCEPT
4. Toggle NAT to the enabled position.
5. Select Use Dynamic IP Pool.
6. Add ippool-WAN-Outbound under Custom IP Pool.
7. Click OK to save the policy.

Step-by-Step CLI Configuration

Network engineers who prefer command-line deployment can configure the exact same components using the FortiOS CLI.

1. Create Address Objects

config firewall address
    edit "net-LAN-10.0.10.0_24"
        set subnet 10.0.10.0 255.255.255.0
    next
    edit "net-Servers-10.0.20.0_24"
        set subnet 10.0.20.0 255.255.255.0
    next
end

2. Create the IP Pool Object

config firewall ippool
    edit "ippool-WAN-Outbound"
        set type overload
        set startip 198.51.100.10
        set endip 198.51.100.12
    next
end

3. Create Policy 1 (Outgoing Interface NAT)

config firewall policy
    edit 1
        set name "LAN-to-WAN-SNAT"
        set srcintf "port2"
        set dstintf "port1"
        set action accept
        set srcaddr "net-LAN-10.0.10.0_24"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end

4. Create Policy 2 (Dynamic IP Pool NAT)

config firewall policy
    edit 2
        set name "Servers-to-WAN-PoolNAT"
        set srcintf "port3"
        set dstintf "port1"
        set action accept
        set srcaddr "net-Servers-10.0.20.0_24"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set nat enable
        set ippool enable
        set poolname "ippool-WAN-Outbound"
    next
end

How the Traffic Flows

Understanding the order of packet processing in FortiOS helps prevent misconfigurations. FortiGate processes outbound traffic using a strict state-machine flow:

1. Ingress Lookup & FIB Check: The packet arrives on the ingress interface (e.g., port2). The FortiGate inspects the destination IP address and queries the Routing Information Base (RIB/FIB) to determine the egress interface. Routing always happens before firewall policy matching.
2. Firewall Policy Matching: FortiGate evaluates the active policy list top-down. It looks for a match on incoming interface, outgoing interface, source address, destination address, service, and schedule.
3. Source NAT Evaluation: Once policy match occurs, FortiGate evaluates the policy NAT settings:
   • If NAT is set to Use Outgoing Interface Address, FortiGate replaces the packet’s source IP address with the IP assigned to egress interface port1. It allocates a dynamic source port from its ephemeral range.
   • If NAT is set to an IP Pool, FortiGate selects an available IP from the assigned pool range and overwrites the source IP and port accordingly.
4. Session Table Entry Creation: FortiGate records the translation details in its stateful kernel session table.
5. Egress Processing: The packet exits port1 into the ISP network with rewritten source headers.
6. Inbound Return Traffic: When the external server responds, the destination address matches the session table entry created in step 4. FortiGate un-NATs the packet (rewriting the public destination back to the original client IP) and routes it back to the internal host.

Note on Central NAT: By default, FortiGate uses policy-based NAT where translation rules sit inside the firewall policy. If your organization enables Central NAT (`config system settings -> set central-nat enable`), translation rules are managed separately under `config firewall central-snat-map`.

Verification

After completing your FortiGate source NAT configuration, verify operational state from both the client and the firewall CLI.

1. Client-Side Test

From an internal workstation (10.0.10.50), initiate an outbound web request or ICMP ping:

curl https://ifconfig.me

The response must display the firewall WAN interface IP address (198.51.100.2). If performed from a host in the server subnet (10.0.20.50), the response will display one of the pool addresses (e.g., 198.51.100.10).

2. Session Table Check via CLI

Filter and view the active firewall sessions on the FortiGate CLI to confirm stateful tracking and translation entries.

diagnose sys session filter src 10.0.10.50
diagnose sys session list

Expected output snippet:

session info: proto=6 proto_state=01 duration=12 expire=3588 timeout=3600 flags=00000000 dev=3/4 gwy=198.51.100.1/4
...
orgin to sub: org: 10.0.10.50:49210 reply: 198.51.100.1:443 dev=3->4
reply to sub: org: 198.51.100.1:443 reply: 198.51.100.2:49210 dev=4->3
...
hook=post act=snat algo=nat

This session entry proves that outbound traffic from source 10.0.10.50 is translated to 198.51.100.2 on egress.

Troubleshooting

If traffic fails to translate or outbound access fails, use the following structured troubleshooting workflow.

Troubleshooting Workflow

Link/Interface Status ---> Routing Table Check ---> Policy Match Check ---> Session Creation ---> Flow Trace Debug

Step 1: Check Routing

Verify that FortiGate has a valid route to the destination network. Without a valid egress route, policy matching never occurs.

get router info routing-table all
get router info routing-table details 0.0.0.0

Step 2: Trace Packet Execution with Debug Flow

The packet trace tool identifies if traffic is dropped due to routing failures, implicit deny policies, or misconfigured NAT pools.

CAUTION: Running debug commands on high-throughput production firewalls can generate large volumes of console log output. Always restrict debug traces using restrictive filters.

Execute the trace syntax:

diagnose debug reset
diagnose debug flow filter saddr 10.0.10.50
diagnose debug flow filter daddr 1.1.1.1
diagnose debug flow show console enable
diagnose debug flow trace start 10
diagnose debug enable

Look for lines indicating successful policy matching and NAT handling in the output trace:

id=65250 trace_id=1 msg="allocate a new session-0001abcd"
id=65250 trace_id=1 msg="find a route: flag=00000001 gw-198.51.100.1 via port1"
id=65250 trace_id=1 msg="Allowed by Policy-1: SNAT"
id=65250 trace_id=1 msg="snat change connection source 10.0.10.50:52100 to 198.51.100.2:52100"

Disable debug logging immediately after testing:

diagnose debug disable
diagnose debug reset

Troubleshooting Matrix

Common Mistakes

• Incorrect Policy Ordering: FortiGate reads firewall policies top-down. If a broad rule matching source all with interface NAT sits above your specific IP pool policy, traffic matches the broader rule first. Always place specific pool policies higher in the list.
• Forgetting IP Pool Type (Overload vs One-to-One): Setting an IP pool type to “One-to-One” when you have fewer public IPs than internal hosts causes translation failure once all public IPs are assigned. Use “Overload” for multi-client translation.
• Missing Upstream ARP Response for Pool IPs: When using an IP Pool that is on the same subnet as the WAN interface, the ISP gateway sends ARP requests for the pool IPs. Ensure the FortiGate responds to ARP requests for pool IPs (enabled by default when using Overload pools).
• Assuming NAT Routing: NAT does not replace routing. FortiGate must know the outbound interface via a routing lookup *before* it can apply policy NAT rules.

Production Considerations

Keep these critical best practices in mind when deploying Source NAT in high-availability or enterprise environments:

• Port Exhaustion Prevention: A single public IP address using Overload PAT can support roughly 60,000 simultaneous TCP/UDP source port allocations. For networks with thousands of active internal endpoints, expand the IP Pool range to include multiple IP addresses to prevent port exhaustion.
• High Availability (HA) Clusters: Session tables and IP pool states synchronize across active/passive FortiGate clusters automatically. When a failover occurs, connections translated via interface address or IP pool resume instantly without manually shifting IP pool properties.
• Logging NAT Allocations: In regulated networks, compliance guidelines require mapping outbound connections back to internal client source IPs. Enable session logging on all outbound policies by setting set logtraffic all in the CLI policy configuration.
• Fixed Port Block Allocation: For strict compliance frameworks where port range tracking is required per user subnet, use the fixed-port-range IP pool type rather than standard overload.

Summary

Configuring Source NAT on a FortiGate firewall is an essential requirement for secure, outbound internet access. By configuring policy-based NAT using the outgoing interface IP or dynamic IP pools, administrators can safely route internal user traffic across public networks. Always sequence your policy table correctly, ensure routing entries precede NAT rules, and use session diagnostics to verify state translations in your network.