FortiGate Firewall Policies and NAT

Firewall policies and NAT are the two core mechanisms that control all traffic moving through a FortiGate device. Think of the firewall policy as the rulebook that decides what is allowed to pass, and NAT as the disguise that hides the true identity of the traffic.

A firewall policy is a set of rules applied to traffic as it moves from one interface to another. A FortiGate has multiple physical or virtual ports, each connected to a different part of the network. For example, port1 might connect to your internal office network (the LAN), and port2 might connect to the internet (the WAN). A firewall policy defines which traffic is allowed to move from port1 to port2, and which traffic is allowed to move the other way. Each policy checks five key attributes: the source address (where the traffic came from), the destination address (where it is going), the service (what kind of traffic it is, like web browsing or email), the schedule (when this rule is active), and the action (allow or deny). If a packet matches all the conditions of a policy, the FortiGate takes the action specified. If no policy matches, the packet is dropped.

Network Address Translation (NAT) is the process of changing one IP address in a packet to another. The most common type is Source NAT (SNAT), also called Dynamic NAT or IP masquerading. This is used when devices on a private network (with addresses like 10.0.0.5 or 192.168.1.10) need to access the internet. Private IP addresses are not routable on the public internet. So the FortiGate replaces the private source address in every outgoing packet with its own public IP address. When the response comes back, the FortiGate remembers which private address made the request (using a NAT table) and translates the destination address back to the private address. This is how a whole office of 100 computers, each with a private IP, can all share a single public IP address.

There is also Destination NAT (DNAT), often called port forwarding. This is used when you want traffic from the internet to reach a specific server inside your private network. For example, you might have a web server at private IP 192.168.1.50, and you want the public to access it by going to your public IP on port 80. A DNAT policy tells the FortiGate to change the destination address from the public IP to the private IP (192.168.1.50) and forward the traffic through the firewall.

A central FortiGate feature is the Central NAT table. Instead of configuring NAT directly inside each firewall policy, you can create a separate NAT rule that is automatically applied when traffic matches certain conditions. This keeps your firewall policies simpler and allows for more granular NAT control, especially when you need to handle different types of traffic differently. For example, one policy might allow web traffic, and a separate Central NAT rule might specify that only web traffic from the marketing department should use a specific public IP address.

Another important concept is NAT64. This allows devices on an IPv6-only network to communicate with an IPv4-only server. The FortiGate translates the IPv6 packet to an IPv4 packet and vice versa. This is becoming more common as organisations start to adopt IPv6 but still need to reach legacy IPv4 services.

When configuring both policies and NAT on a FortiGate, there is a specific processing order. For inbound traffic (from the internet to your network), the FortiGate first checks Destination NAT rules. If there is a match, it changes the destination IP before it then checks the firewall policy. For outbound traffic (from your network to the internet), the firewall policy is checked first, and then Source NAT is applied after the policy decision is made. This order is critical to understand because it affects how you write your rules.

You can also perform NAT without a firewall policy by using Virtual IPs (VIPs). A Virtual IP is a public IP address that is mapped to a private IP address. When you create a VIP, the FortiGate automatically creates the necessary DNAT rules behind the scenes. You can then reference that VIP in your firewall policy as the destination, making the configuration cleaner and more manageable.

Sophie is the security administrator for a medium-sized company called GreenLeaf Ltd with 200 employees. The company has a single FortiGate firewall at the edge of its network. The internal network uses private IP addresses in the 10.10.0.0/16 range. The company has one public IP address assigned by its internet service provider (ISP). Sophie needs to ensure employees can browse the web and access public cloud services, but she must also let customers reach the company's public-facing web server, which sits on a private IP address inside the office.

Step-by-step, here is what Sophie does:

First, she creates a firewall policy to allow outbound internet access. She configures the policy to allow traffic from the internal network (source address 10.10.0.0/16) to the internet (destination address 'all'). She sets the service to 'web-access' (which covers HTTP and HTTPS). She enables Source NAT (Dynamic IP Pool) on this policy, which tells the FortiGate to replace the private source address with the company's single public IP. She does not create any additional NAT rule because the simple NAT option in the policy is sufficient. Now, every time an employee opens a browser, the FortiGate translates their private IP to the public IP before the packet leaves for the internet. When the response comes back, the FortiGate looks up the NAT table and delivers the packet back to the correct employee's computer.

Second, Sophie needs to allow customers to reach the company's web server at 10.10.10.10 on port 443 (HTTPS). She creates a Destination NAT rule using a Virtual IP. She configures the VIP with the public IP (the company's single public IP) and port 443, and maps it to the private IP 10.10.10.10 on port 443. Then she creates a firewall policy that allows traffic from the internet (source address 'all') to the VIP (the destination is now the VIP object). The action is 'allow'. Now, when a customer types the company's domain name in a browser, DNS resolves it to the public IP. The FortiGate sees the incoming packet, matches the VIP, changes the destination IP to 10.10.10.10, and then checks the firewall policy. Because the policy allows it, the packet is forwarded to the web server.

Sophie also needs to manage traffic for a second public IP she just bought. She wants traffic bound for that IP to reach a separate internal server. She creates a second VIP for that IP and a second firewall policy. She uses Central NAT to avoid cluttering her policies. She creates a Central NAT rule that says: if traffic is from the internal network, and the destination is the internet, then use a pool of two public IP addresses (the original one and the new one) to balance the load. This ensures that outbound traffic from employees uses either of the two public IPs, providing better performance and redundancy.

Finally, Sophie audits the NAT logs weekly. She looks for any traffic that is being translated unexpectedly, or any traffic that is being dropped because no NAT rule exists. She uses the FortiGate's built-in 'NAT session' diagnostic tool to view active translations and see which internal IP is currently using which translated public IP. This is how she troubleshoots connectivity problems. If a customer cannot reach the web server, she checks whether the VIP is matching, whether the firewall policy is allowing the traffic, and whether any other policy is blocking it.