Home

Mastering NAT on FortiGate: A Comprehensive Guide to Static and Dynamic Configuration

.

Network Address Translation (NAT) remains one of the most critical functions in modern firewall management, and FortiGate's implementation offers both powerful flexibility and occasional configuration challenges. This guide synthesizes practical knowledge from Fortinet documentation, community forums to provide a complete picture of static and dynamic NAT configuration on FortiGate firewalls.

Understanding NAT Fundamentals on FortiGate

Before diving into configuration, it's essential to understand how FortiGate approaches NAT. Unlike some vendors that treat NAT as a simple checkbox, FortiGate implements NAT through distinct but interconnected components: Virtual IPs (VIPs) for destination NAT (DNAT) and IP Pools for source NAT (SNAT). This separation provides granular control but requires understanding how these elements work together.

The Two-Way NAT Challenge

A common point of confusion, highlighted in community discussions, is that creating an inbound static NAT rule (VIP) does not automatically ensure that outbound traffic from that same internal host uses the corresponding public IP address. By default, FortiGate performs outbound NAT to the external IP address only for replies sent by the internal server in response to requests that originated from outside the firewall. This behavior, while logical, often surprises administrators expecting symmetric NAT.

Static NAT (One-to-One) Configuration

Static NAT, also known as one-to-one NAT, creates a permanent mapping between an internal private IP address and an external public IP address. This is essential for servers that need to be accessible from the internet with consistent addressing.

Inbound Static NAT Configuration

The inbound component allows external hosts to initiate connections to an internal server. This is configured using Virtual IPs:

Step 1: Create the Virtual IP Object Navigate to Policy & Objects > Virtual IPs > Create New > Virtual IP. Configure the following:

  • Name: Provide a descriptive name (e.g., "WebServer_Public")
  • Interface: Select the external WAN interface
  • Type: Static NAT
  • External IP Address: Enter the single public IP address (despite the "range" terminology)
  • Mapped IP Address/Internal IP: Enter the private IP of your internal server

Step 2: Create the Firewall Policy Navigate to Policy & Objects > Firewall Policy > Create New:

  • Name: Descriptive name for the rule
  • Incoming Interface: Your WAN interface
  • Outgoing Interface: Your internal LAN or DMZ interface
  • Source: "all" or restrict to specific source networks
  • Destination: Select the Virtual IP you created
  • Schedule: Always
  • Service: Restrict to necessary services (HTTP/HTTPS for a web server)
  • Action: ACCEPT
  • NAT: Disable NAT on this policy (counterintuitively, the VIP handles the translation)

Outbound Static NAT Configuration

To ensure traffic originating from your internal server always uses the same public IP address, you must configure outbound source NAT:

Step 1: Create an IP Pool Navigate to Policy & Objects > IP Pools > Create New:

  • Name: Descriptive name (e.g., "WebServer_Outbound_Pool")
  • Type: Overload (for PAT) or One-to-One (if you have multiple IPs)
  • External IP Range: Specify your public IP address or range
  • ARP Reply: Enable if the IP is on the same subnet as the interface

Step 2: Create Outbound Firewall Policy Navigate to Policy & Objects > Firewall Policy > Create New:

  • Incoming Interface: Internal LAN/DMZ interface
  • Outgoing Interface: WAN interface
  • Source: The specific internal server IP address
  • Destination: "all" (or restrict as needed)
  • Schedule: Always
  • Service: any (or restrict as needed)
  • Action: ACCEPT
  • NAT: Enable
  • IP Pool Configuration: Select "Use Outgoing Interface Address" or "Use Dynamic IP Pool" and select your created pool

The CLI Shortcut: nat-source-vip

For simpler scenarios where you want symmetric NAT (same public IP for both directions), Fortinet provides a CLI command that simplifies configuration. As noted in forum discussions, you can enable this on an existing VIP:

config firewall vip edit <your_vip_name> set nat-source-vip enable end

This command automatically handles outbound NAT for traffic originating from the VIP's mapped IP, using the VIP's external IP as the source address.

Dynamic NAT (Source NAT) Configuration

Dynamic NAT, often implemented as Port Address Translation (PAT) or "Overload" NAT, allows multiple internal hosts to share a single public IP address or a pool of public addresses. This is the typical configuration for general internet access from internal networks.

Basic Dynamic SNAT (Default Behavior)

Out-of-the-box, FortiGate performs dynamic NAT for all outbound traffic using the egress interface's IP address. This default behavior works for most scenarios but lacks granular control.

Configuring Dynamic SNAT with IP Pools

For scenarios requiring more control—such as distributing traffic across multiple public IPs or preserving a specific source IP range for particular destinations—IP Pools provide the solution:

Step 1: Create an IP Pool for Dynamic NAT Navigate to Policy & Objects > IP Pools > Create New:

  • Name: Descriptive name (e.g., "Outbound_Pool")
  • Type: Overload (for PAT)
  • External IP Range: Specify a range of public IP addresses (e.g., 203.0.113.10-203.0.113.20)
  • ARP Reply: Enable to allow the FortiGate to respond to ARP requests for these IPs

Step 2: Create or Modify Outbound Policy In your outbound firewall policy:

  • Enable NAT
  • Under IP Pool Configuration, select "Use Dynamic IP Pool"
  • Choose your newly created pool

Advanced Dynamic NAT Scenarios

Fixed Port Range Allocation For environments requiring predictable source port ranges (common with certain applications or compliance requirements), you can configure fixed port ranges within IP pools using the CLI:

config firewall ippool edit "Outbound_Pool" set type overload set port-range enable set source-start 1024 set source-end 65535 set block-size 512 end

Destination-Based Dynamic NAT For scenarios where you need different source NAT behavior based on destination, create multiple IP pools and reference them in different firewall policies with specific destination addresses.

Troubleshooting and Best Practices

Common Configuration Pitfalls

ARP Table Caching When testing outbound NAT changes, FortiGate's ARP tables can persist for several minutes. As noted in community posts, if you're testing by visiting "whatismyip" websites, you may need to clear browser sessions, restart test computers, or simply wait for ARP tables to expire.

Policy Order Matters FortiGate processes firewall policies sequentially from top to bottom. Ensure your more specific NAT policies appear above general internet access policies.

VIP and Policy Matching A frequent issue reported in forums is that Virtual IPs don't appear as selectable destinations in firewall policies. This typically occurs when:

  • The interface selected in the VIP doesn't match the policy's incoming interface
  • The VIP is configured but not yet committed
  • The administrator is looking in the wrong section (source vs destination)

Verification Commands

Use these diagnostic commands to verify NAT operations:

# Check active NAT sessions diagnose firewall iprope list 100001  # Verify VIP statistics diagnose firewall vip list  # Monitor IP pool usage diagnose firewall ippool list  # Check NAT session details diagnose sys session list | grep <ip_address>

Real-World Configuration Examples

Example 1: Public Web Server with Symmetric NAT

Requirement: A web server at 192.168.1.100 must be accessible via public IP 203.0.113.50, and all outbound traffic from this server must appear to originate from 203.0.113.50.

Solution:

  1. Create VIP "WebServer_VIP": External 203.0.113.50 → Internal 192.168.1.100
  2. Enable set nat-source-vip enable on the VIP via CLI
  3. Create inbound WAN→LAN policy using the VIP as destination (NAT disabled)
  4. Create outbound LAN→WAN policy for source 192.168.1.100 (NAT enabled, using outgoing interface address—the VIP handles source NAT due to nat-source-vip)

Example 2: Multiple Internal Servers Using Different Public IPs

Requirement: Three internal servers need distinct public IPs for different services.

Solution:

  1. Create three separate VIPs, each mapping a unique public IP to each server
  2. Create three inbound policies, each using the respective VIP as destination
  3. Optionally enable nat-source-vip on each VIP if outbound traffic should match

Example 3: Large User Base with Limited Public IPs

Requirement: 500 internal users need internet access, but only 10 public IPs are available.

Solution:

  1. Create an IP Pool "User_Pool" with type "Overload" and the 10 public IPs
  2. Create a LAN→WAN policy for all internal users
  3. Enable NAT and select "Use Dynamic IP Pool" with User_Pool
  4. FortiGate will distribute sessions across all 10 IPs using PAT

Frequently Asked Questions

Why does my inbound NAT work, but outbound traffic from the same server uses a different IP?

By default, FortiGate treats inbound and outbound NAT separately. To make them match, either create an explicit outbound policy with an IP pool or enable set nat-source-vip enable on your VIP configuration.

Can I use the same public IP for both inbound and outbound NAT without configuration?

Yes, but only for reply traffic. For initiated outbound traffic to use the same IP, you need either an outbound IP pool or the nat-source-vip CLI setting.

What's the difference between "Overload" and "One-to-One" IP pool types?

Overload (PAT) allows many internal IPs to share one or more external IPs by using unique source ports. One-to-One creates a static mapping where each internal IP in a range maps to a specific external IP in a corresponding range.

My Virtual IP doesn't appear in the destination dropdown. Why?

Ensure the interface selected in the VIP matches the incoming interface of your policy. VIPs are interface-specific and only appear for policies using that interface.

How do I preserve source port numbers during NAT?

For most scenarios, port preservation isn't guaranteed with PAT. For specific applications requiring fixed ports, consider using fixed port range allocation in IP pools or one-to-one NAT.

Can I do NAT based on destination domain names?

FortiGate NAT operates at the network layer and cannot use domain names directly. However, you can use FQDN objects in policy destinations, which resolve to IP addresses.

Conclusion

FortiGate's NAT implementation offers tremendous flexibility but requires understanding its component-based architecture. The key distinction between Virtual IPs (for destination NAT) and IP Pools (for source NAT) forms the foundation of all configurations. Whether implementing simple internet access for hundreds of users or complex bidirectional NAT for critical servers, the patterns described in this guide provide a reliable framework for success.

Remember that NAT configuration is rarely "set and forget." Regular monitoring of NAT sessions, careful attention to policy ordering, and thorough testing after changes will ensure your FortiGate continues to provide secure, reliable network address translation for all your organization's needs.

Always test configuration changes in a non-production environment when possible and consult current Fortinet documentation for your specific firmware version.