Central NAT vs Policy NAT

In the past, Fortigate used what was known as ‘Policy NAT’ where the outbound NAT was defined in the policy. Below you can see what that looked like. Note the NAT section.

The central NAT table enables you to define, and control with more granularity, the address translation performed by the FortiGate unit. With the NAT table, you can define the rules which dictate the source address or address group and which IP pool the destination address uses.

While similar in functionality to IP pools, where a single address is translated to an alternate address from a range of IP addresses, with IP pools there is no control over the translated port. When using the IP pool for source NAT, you can define a fixed port to guarantee the source port number is unchanged. If no fix port is defined, the port translation is randomly chosen by the FortiGate unit. With the central NAT table, you have full control over both the IP address and port translation.

The FortiGate unit reads the NAT rules in a top-down methodology, until it hits a matching rule for the incoming address. This enables you to create multiple NAT policies that dictate which IP pool is used based on the source address. The NAT policies can be rearranged within the policy list as well. NAT policies are applied to network traffic after a security policy.

Source

 

Fortinet introduced Central NAT. With Central NAT, you change the order of operation of the firewall. This method is more inline with the competitors such as Cisco (8.3+ NOT FTD), PaloAlto, Checkpoint, etc. With Central NAT you have a separate SNAT table and separate DNAT/VIP Table. IMHO, this method is much more granular than policy NAT.

Here is a sample scenario. You create a policy with multiple destination interfaces. You have different requirements for NAT’ng as the packets egress the different interfaces.

Incoming Interface: port1 (inside)
Outgoing Interface(s): wan1 (outside), DMZ, Test
# Note the 3 different interfaces                            
Source: 192.168.68.10 (example PC)
Destination: all

USE-CASE

So in my example above, you want to NAT outbound connection egressing WAN1 as the IP address assigned to the WAN1 interface, but when you egress the DMZ, you may want to disable NAT altogether and then when you are egressing the Test interface, you may use a specific ip-pool.

In the traditional ‘policy NAT’ mode, you would require three policies:

1. A policy that has the ‘User Outgoing Interface Address’  for the WAN1 traffic.
2. A NAT disabled policy for the DMZ interface traffic,
3. And finally, a ‘Use Dynamic IP Pool’ for the Test interface.

With Central NAT, you could create one policy with a separate NAT policy.

Above, shows an example in my lab.

We can see that from the POC-LAN going out the Gigapower (port1) interface, NAT is enabled. On the second line, we see from POC-LAN to TEST, we can see NAT is disabled, and finally, we see POC-LAN to TEST from a particular source subnet to the SERVER-LAN which we use an IP Pool for.

Lets break it down:

The screenshot above shows the details of the first line. In this line, we are saying that IF you are coming from the ‘POC-LAN’ and your destination is ‘gigapower (port1)’, and the source and destination is ‘all’, we are going to enable NAT and use the IP of the interface.

This next screenshot show the second line where we want to NOT use any NAT functionality (no-nat for you legacy Cisco folks). We can see that we have specified LAN objects in the source/destination fields. You could have done ‘all’ as in the first example and it would only match the incoming and outgoing interfaces.

Finally, we can see that we are using a ‘Fake-192.168.1’ pool.

As you may, or may not know, On the Fortigate, if you create a Block Country policy at the top but have VIPs in the destination, it will not apply to VIPs unless you force a change via the CLI. What happens is, because of order of operations, the policy gets looked at AFTER the VIP is done. The only way to combat this is my enabling ‘match-vip enable’ or add the VIPs to the ‘Deny’ policy. With Central NAT, that feature is no longer needed

From inside the GUI, you can ‘Right Click’ any policy and choose ‘edit in CLI. You can clearly see on the screenshot below that the ’set match-vip’ option is available.

However on the Central NAT screenshot, we see, the option is no longer available.

If you want to add the SNAT via the CLI, here are the commands:

config firewall central-snat-map

edit <policyID number>
set status enable
set orig-addr FortiGate>
set dst-addr FortiGate>
set nat-ippool ippool object preconfigured on the FortiGate>
set protocol <integer for protocol number>

# Then type either ‘end’ or ’next’ to save the config.

Packet Life Cycle

If you look at the ‘Life of a Packet’ page (where I grabbed the screenshot below), you can see the order of operation as the packet flows through the Fortigate. I normally will not just cut and paste from another website, and I DID link to it earlier, but it does have some good information you should have access to.

Ingress packet flow

When a packet is received by an interface and enters a FortiGate the following steps occur:

Interface TCP/IP stack

Ingress packets are received by a FortiGate interface.The packet enters the system, and the interface network device driver passes the packet to the Denial of Service (DoS) sensors, if enabled, to determine whether this is a valid information request or not.

DoS sensor

DoS scans are handled very early in the life of the packet to determine whether the traffic is valid or is part of a DoS attack.The DoS module inspects all traffic flows but only tracks packets that can be used for DoS attacks (for example, TCP SYN packets), to ensure they are within the permitted parameters. Suspected DoS attacks are blocked, other packets are allowed.

IP integrity header checking

The FortiGate unit reads the packet headers to verify if the packet is a valid TCP, UDP, ICMP, SCTP or GRE packet. The only verification that is done at this step to ensure that the protocol header is the correct length. If it is, the packet is allowed to carry on to the next step. If not, the packet is dropped.

IPsec VPN

If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. If the IPsec engine can apply the correct encryption keys and decrypt the packet, the unencrypted packet is sent to the next step. Non-IPsec traffic and IPsec traffic that cannot be decrypted passes on to the next step without being affected.

Interface policy

Interface policies apply flow-based inspection to packets received at an interface before the packets are accepted by a firewall policy. Interface policies can also be applied decrypted IPsec VPN traffic. Using interface policies you can apply IPS sensors, application control and flow-based web filtering and virus scanning to traffic before it is accepted by a firewall policy. Packets can be dropped or allowed depending on the sensor or profile settings.

Destination NAT (DNAT)

The FortiGate unit checks the NAT table and determines if the destination IP address for incoming traffic must be changed using DNAT. DNAT is typically applied to traffic from the Internet that is going to be directed to a server on a network behind the FortiGate. DNAT means the actual address of the internal network is hidden from the Internet. This step determines whether a route to the destination address actually exists.

DNAT must take place before routing so that the FortiGate unit can route packets to the correct destination.

Routing

The routing step uses the routing table to determine the interface to be used by the packet as it leaves the FortiGate unit. Routing also distinguishes between local traffic and forwarded traffic. Firewall policies are matched with packets depending on the source and destination interface used by the packet. The source interface is known when the packet is received and the destination interface is determined by routing.

Stateful inspection

Stateful inspection looks at the first packet of a session and looks in the policy table to make a security decision about the entire session. Stateful inspection looks at packet TCP SYN and FIN flags to identity the start and end of a session, the source/destination IP, source/destination port and protocol. Other checks are also performed on the packet payload and sequence numbers to verify it as a valid session and that the data is not corrupted or poorly formed.

When the first packet is a session is matched in the policy table, stateful inspection adds information about the session to its session table. So when subsequent packets are received for the same session, stateful inspection can determine how to handle them by looking them up in the session table (which is more efficient than looking them up in the policy table).

Stateful inspection makes the decision to drop or allow a session and apply security features to it based on what is found in the first packet of the session. Then all subsequent packets in the same session are processed in the same way.

When the final packet in the session is processed, the session is removed from the session table. Stateful inspection also has a session idle timeout that removes sessions from the session table that have been idle for the length of the timeout.

See the Stateful Firewall Wikipedia article (https://en.wikipedia.org/wiki/Stateful_firewall) for an excellent description of stateful inspection.

Local management traffic

Local management traffic terminates at a FortiGate interface. This can be any FortiGate interface included dedicated management interfaces. In multiple VDOM mode local management traffic terminates at the management interface. In Transparent mode, local management traffic terminates at the management IP address.

Local management traffic includes administrative access, some routing protocol communication, central management from FortiManager, communication with the FortiGuard network and so on. Management traffic is allowed or blocked according to the Local In Policy list which lists all management protocols and their access control settings. You configure local management access indirectly by configuring administrative access and so on.

Management traffic is processed by applications such as the web server which displays the FortiOS web‑based manager, the SSH server for the CLI or the FortiGuard server to handle local FortiGuard database updates or FortiGuard Web Filtering URL lookups.

Local management traffic is not involved in subsequent stateful inspection steps.

SSL VPN traffic terminates at a FortiGate interface similar to local management traffic. However, SSL VPN traffic uses a different destination port number that administrative traffic and can thus be detected and handled differently.

Policy lookup

The first stateful inspection step is a policy lookup that matches the packet with a firewall policy based on standard firewall matching criteria (source and destination interfaces, source and destination IP addresses, and port numbers). If the policy denies the packet it is discarded. An accepted packet continues to the next step.

Many FortiOS features are applied to traffic depending on the settings in the policy that matches the traffic as determined by the policy lookup. This includes authentication, security features and so on.

Session tracking

As described above for stateful inspection. Sessions are tracked in a session table after policy lookup has identified a new session.

Session helpers

Some protocols include information in the packet body (or payload) that must be analyzed to successfully process sessions for this protocol. For example, the SIP VoIP protocol uses TCP control packets with a standard destination port to set up SIP calls. To successfully process SIP VoIP calls, FortiOS must be able to extract information from the body of the SIP packet and use this information to allow the voice-carrying packets through the firewall.

FortiOS uses session helpers to analyze the data in the packet bodies of some protocols and adjust the firewall to allow those protocols to send packets through the firewall. FortiOS includes the following session helpers:

• PPTP
• H323
• RAS
• TNS
• TFTP
• RTSP
• FTP

• MMS
• PMAP
• SIP
• DNS-UDP
• RSH
• DCERPC
• MGCP

SSL VPN

Local SSL VPN traffic is treated like special management traffic as determined by the SSL VPN destination port. Packets are decrypted and are routed to an SSL VPN interface. Policy lookup is then used to control how packets are forwarded to their destination outside the FortiGate.

User Authentication

User authentication added to security policies is handled by the stateful inspection, which is why Firewall authentication is based on IP address. Authentication takes place after policy lookup selects a policy that includes authentication.

Traffic Shaping

If the policy that matches the packet includes traffic shaping it is applied as the last stateful inspection step.

Flow-based inspection

Flow-based inspection identifies and blocks security threats in real time as they are identified.

Flow-based inspection samples packets in a session and uses single-pass Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats. Depending on the options selected in the firewall policy that accepted the session, flow-based inspection can apply IPS, Application Control, Web Filtering, DLP and Antivirus.

All of the applicable flow-based security modules are applied simultaneously in one pass. IPS, Application Control, Web Filtering and DLP filtering happen together. Flow-based antivirus caches files during protocol decoding and submits cached files for virus scanning while the other matching is carried out.

Flow inspection typically requires less processing resources than proxy inspection and since its not a proxy, flow-based inspection does not change packets (unless a threat is found and packets are blocked). Flow-based inspection cannot apply as many features as proxy inspection (for example, flow-based inspection does not support client comforting and some aspects of replacement messages).

IPS and Application Control are only applied using flow-based inspection. Web Filtering, DLP and Antivirus can also be applied using proxy-based inspection.

Proxy‑based inspection

Proxy-based inspection uses a proxy to inspect content traffic (VoIP, HTTP, HTTPS, FTP, email, and others) for threats. The proxy extracts and caches content, such as files and web pages, from a content session and inspects the cached content for threats. Content inspection happens in the following order: VoIP inspection, DLP, Email Filtering, Web Filtering, Antivirus, and ICAP. If no threat is found the proxy relays the content to its destination. If a threat is found the proxy can block the content and replace it with a replacement message.

The proxy can also block VoIP traffic that contains threats. VoIP inspection can also look inside VoIP packets and extract port and address information and open pinholes in the firewall to allow VoIP traffic through.

ICAP intercepts HTTP and HTTPS traffic and forwards it to an ICAP server. The FortiGate unit is the surrogate, or “middle-man”, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and the FortiGate unit determines the action that should be taken with these ICAP responses and requests.

Egress packet flow

After stateful inspection and flow or proxy-based inspection the packet goes through the following steps before exiting.

IPsec VPN

If the packet is to be sent out an IPsec tunnel, it is at this stage the encryption and required encapsulation is performed.

Source NAT (SNAT)

The FortiGate unit checks the NAT table and determines if the source IP address for outgoing traffic must be changed using SNAT. SNAT is typically applied to traffic from an internal network heading out to the Internet. SNAT means the actual address of the internal network is hidden from the Internet.

DNAT must take place before routing so that the FortiGate unit can route the packet to the correct destination.

Routing

The final routing step determines the next hop router to send the packet to after it exits the FortiGate unit.

Interface TCP/IP Stack

Egress packets are received by the interface network device driver which forwards the packet out the interface an onto the network.