Mastering Fortigate Firewall NAT Policies: A Complete Configuration Guide
.
Network Address Translation (NAT) serves as the cornerstone of modern network security, enabling organizations to connect private networks to the public internet while conserving valuable public IP addresses. In Fortigate firewalls, NAT transforms private IP addresses into public ones as traffic flows between networks, creating an essential security barrier that shields internal network structures.
Fortigate implements NAT through three primary methods: static NAT (one-to-one fixed mapping), dynamic NAT (using pools of addresses), and central NAT (granular rule-based control). Additionally, Fortigate supports specialized NAT46 and NAT64 policies for environments transitioning between IPv4 and IPv6 networks. Understanding these mechanisms is crucial for network administrators tasked with securing organizational assets while maintaining connectivity. The implementation approach varies based on whether you're configuring source NAT (SNAT) for outbound traffic or destination NAT (DNAT) for inbound access to internal resources.
Core NAT Configuration Methods
Policy-Based NAT Configuration
The most common approach to NAT configuration in Fortigate firewalls involves security policies that integrate NAT functionality. According to the FortiManager Admin Guide, policy-based NAT is enabled by default when creating standard firewall policies. When you set the action to "ACCEPT" in a policy, NAT is automatically enabled with "Use Destination Interface Address" selected as the default behavior.
The configuration process follows a structured path: navigate to Policy & Objects > Policy Packages, select the appropriate ADOM, and create a new policy with properly defined interfaces, addresses, and services. Key settings include Incoming Interface, Outgoing Interface, Source Address, Destination Address, and Service specifications. This integrated approach simplifies administration but offers less granularity than other methods for complex scenarios.
Central NAT Configuration
For organizations requiring advanced control over translation rules, Fortigate offers Central NAT functionality. This feature must be explicitly enabled via the CLI command config system settings followed by set central-nat enable. Once activated, administrators access Central SNAT through Policy & Objects > Central SNAT, where they can create specific translation rules that are processed top-down until a match is found.
Central NAT provides enhanced granularity compared to policy-based NAT, allowing precise control over both IP addresses and port translations. Administrators can define which source addresses or groups use specific IP pools based on destination addresses, creating a more flexible and scalable NAT architecture suitable for complex network environments with multiple translation requirements.
Practical NAT Implementation Guide
Configuring Source NAT (SNAT)
Source NAT modifies the originating IP address of outbound traffic, typically translating private addresses to public ones. Three primary SNAT modes: static, dynamic, and central.
Static SNAT represents the simplest form, where internal addresses consistently map to the same public IP address using port address translation (PAT). A single public IP can theoretically handle up to 60,416 internal addresses through different port assignments. Configuration involves creating a firewall policy with NAT enabled and selecting "Use Outgoing Interface Address."
For dynamic SNAT, administrators define IP pools that provide multiple translation addresses. Fortigate offers four IP pool types:
- Overload: Similar to static SNAT but with multiple IP addresses available
- One-to-One: Direct mapping without port translation (disables PAT)
- Fixed Port Range: Defines both internal and external IP ranges with calculated port allocations
- Port Block Allocation: Allows granular control over port distribution with block sizing
Demonstration shows practical SNAT implementation where LAN devices connect to external resources, with translations visible in Fortigate logs showing the transformed source addresses.
Configuring Destination NAT (DNAT)
Destination NAT, crucial for server publishing, translates incoming traffic's destination address to redirect it to internal resources. The configuration process differs significantly from SNAT, requiring initial creation of Virtual IP (VIP) objects that define the mapping between external and internal addresses.
DNAT setup involves two distinct steps: first creating a Virtual IP entry under Policy & Objects > Virtual IPs, then establishing a corresponding firewall policy with NAT disabled on the policy itself (since NAT in policies refers specifically to SNAT, not DNAT). This separation ensures clear translation rule definition before access control implementation.
A practical example demonstrates mapping an external IP (192.168.50.50) to an internal web server, with the Virtual IP handling the destination translation while security policies control access permissions. This approach safely exposes internal services without compromising network security architecture.
IPv4/IPv6 Translation Policies
NAT46 and NAT64 Implementation
For organizations operating in dual-stack environments or transitioning between IP versions, Fortigate provides specialized NAT46 and NAT64 policies. NAT46 policies enable IPv6 networks to access IPv4 internet resources, while NAT64 policies facilitate translation between internal IPv6 networks and external IPv4 networks.
These specialized policies appear as separate tabs in the management interface and require specific activation through Display Options in the Tools menu. Configuration follows similar patterns to standard policies but with protocol-specific considerations. Administrators must define appropriate addressing for both IP versions and ensure routing correctly handles the translated traffic between protocol domains.
Advanced NAT Considerations
Port Preservation and Protocol Handling
An important configuration decision involves port preservation, which determines whether source ports remain unchanged during translation. Enabling "Preserve Source Port" maintains the original port number, crucial for services expecting traffic from specific ports. Disabling this feature allows multiple simultaneous connections through different ports, increasing scalability but potentially breaking certain applications.
Protocol-specific handling becomes particularly relevant in Central NAT configurations, where administrators can specify translation rules for TCP (protocol 6), UDP (protocol 17), SCTP (protocol 132), or any protocol. This granular control ensures appropriate translation behavior for different application requirements, from standard web traffic to specialized VoIP or streaming applications.
Troubleshooting and Verification
Effective NAT implementation requires rigorous testing and verification. Administrators should examine Fortigate logs to confirm translations occur as expected, with source or destination addresses correctly modified according to policies. Connectivity testing from both internal and external perspectives validates proper functionality.
Common issues include policy order problems (where higher-priority rules override intended translations), incorrect interface assignments, and conflicting Virtual IP definitions. Regular auditing of NAT policies against network requirements helps maintain optimal performance and security as organizational needs evolve.
Frequently Asked Questions
What's the difference between policy-based NAT and Central NAT?
Policy-based NAT integrates translation rules directly within security policies, simplifying administration for standard scenarios. Central NAT separates translation rules from security policies, providing granular control over IP and port translations. Central NAT must be explicitly enabled and processes rules top-down, allowing multiple NAT policies based on source addresses. Organizations typically choose policy-based NAT for simpler environments and Central NAT for complex networks requiring detailed translation control.
When should I use Virtual IPs versus IP Pools?
Virtual IPs (VIPs) specifically handle destination NAT (DNAT) for inbound connections to internal servers, mapping external addresses to internal resources. IP Pools configure source NAT (SNAT) for outbound connections, providing ranges of addresses for outgoing traffic translation. VIPs are essential for server publishing, while IP Pools manage how internal devices appear to external networks. These mechanisms serve complementary purposes in comprehensive NAT architectures.
How do I troubleshoot NAT translation failures?
Start by verifying policy order in both security and NAT rule lists, ensuring no higher-priority rules block intended translations. Check that interfaces are correctly assigned and that address objects match actual network configurations. Examine Fortigate logs for specific traffic flows to identify where translations succeed or fail. For complex issues, temporarily enable detailed logging for specific policies and test with controlled traffic to isolate the problem source, checking both translation and security policy matches.
Can I use both IPv4 and IPv6 NAT simultaneously?
Yes, Fortigate firewalls support simultaneous IPv4 and IPv6 NAT through separate policy sets. NAT46 policies enable IPv6-to-IPv4 translation, while NAT64 policies handle IPv4-to-IPv6 translation. These can operate alongside standard IPv4 NAT policies in dual-stack environments. Configuration requires proper routing for both protocols and careful planning of address translations between protocol domains to prevent connectivity issues across IP versions.
What are the security implications of different NAT types?
Static SNAT provides consistent external identities but may simplify tracking of internal hosts. Dynamic NAT with IP pools offers increased anonymity through address variability but requires careful pool sizing. One-to-one NAT preserves individual host visibility externally, potentially increasing exposure. Destination NAT (via Virtual IPs) creates controlled entry points but must be paired with strict security policies to prevent unauthorized access. All NAT implementations should complement, not replace, comprehensive security policies and monitoring.