FortiGate Firewall Basics: Policies, NAT and Logging

FortiGate firewalls control traffic by matching packets against ordered security policies. A working configuration normally requires correctly addressed interfaces, routes, policies, NAT rules where needed, and logging that provides enough evidence for troubleshooting.

This practical guide uses FortiOS CLI examples and a small office topology. Menu names and available logging destinations can vary between FortiOS versions and FortiGate models, but the core workflow remains consistent.

What are the main FortiGate firewall basics?

The main FortiGate firewall basics are interfaces, routes, address objects, services, firewall policies, NAT and logs. These components work together: the route identifies a possible path, while the policy decides whether traffic may use that path.

A firewall policy does not replace routing. FortiGate must have a usable route and a matching policy before it can forward a new session.

Engineers working with firewalls also need solid subnetting, VLAN and routing knowledge. These foundations are covered in the CCNA course, while hands-on firewall monitoring and incident analysis are part of the Cybersecurity & SOC course.

What lab topology will we use?

The lab has a LAN on port2, an internet connection on port1, and a DMZ web server on port3. Documentation addresses are used for the public network so that the examples do not reference a real organisation.

Diagram in words:

LAN client 10.10.10.50 → port2 10.10.10.1 → FortiGate → port1 203.0.113.10 → ISP gateway 203.0.113.1

A second path publishes a server:

Internet client → 203.0.113.20 TCP/443 → FortiGate VIP → DMZ server 10.10.20.10 TCP/443

The following interface configuration is suitable for an isolated lab:

config system interface
    edit "port1"
        set alias "WAN"
        set ip 203.0.113.10 255.255.255.0
        set allowaccess ping https ssh
    next
    edit "port2"
        set alias "LAN"
        set ip 10.10.10.1 255.255.255.0
        set allowaccess ping https ssh
    next
    edit "port3"
        set alias "DMZ"
        set ip 10.10.20.1 255.255.255.0
        set allowaccess ping
    next
end

Do not enable HTTPS or SSH administration on an internet-facing interface unless it is required and restricted with trusted hosts or a local-in policy. Management exposure should be minimised in production.

Add the default route through the ISP:

config router static
    edit 1
        set dst 0.0.0.0 0.0.0.0
        set gateway 203.0.113.1
        set device "port1"
    next
end

Verify the routing table with:

get router info routing-table all

How do FortiGate firewall policies work?

FortiGate checks policies from top to bottom and uses the first matching policy. A policy commonly matches source interface, destination interface, source address, destination address, schedule and service; unmatched traffic reaches the implicit deny rule.

For the lab, first create a reusable LAN address object:

config firewall address
    edit "LAN_SUBNET"
        set subnet 10.10.10.0 255.255.255.0
    next
end

Then permit LAN clients to use DNS, HTTP and HTTPS on the internet:

config firewall policy
    edit 0
        set name "LAN_to_Internet_Web"
        set srcintf "port2"
        set dstintf "port1"
        set action accept
        set srcaddr "LAN_SUBNET"
        set dstaddr "all"
        set schedule "always"
        set service "DNS" "HTTP" "HTTPS"
        set nat enable
        set logtraffic all
    next
end

edit 0 asks FortiGate to allocate a policy ID. The rule permits only the listed services and enables source NAT using the outgoing interface address.

Policy order matters. For example, a broad LAN-to-WAN allow rule placed above a restricted rule could match first and make the restricted rule ineffective. Place specific rules above general rules and use meaningful policy names.

You can inspect configured policies with:

show firewall policy

To examine one policy, enter the policy configuration and display it:

config firewall policy
    edit <policy-id>
        show
    next
end

How does source NAT work on FortiGate?

Source NAT replaces the source address of outbound packets, allowing private clients to communicate through a routable address. With policy-based NAT, set nat enable normally translates the client address to the address of the outgoing interface.

For example, a packet may change as follows:

Before SNAT: 10.10.10.50:53000 -> 198.51.100.25:443
After SNAT:  203.0.113.10:61024 -> 198.51.100.25:443

FortiGate records the translation in its session table. When the reply returns, the firewall reverses the translation and sends the packet to 10.10.10.50.

An IP pool is useful when outbound traffic must use a public address other than the WAN interface address:

config firewall ippool
    edit "OUTBOUND_PUBLIC_IP"
        set startip 203.0.113.30
        set endip 203.0.113.30
    next
end

config firewall policy
    edit <policy-id>
        set nat enable
        set ippool enable
        set poolname "OUTBOUND_PUBLIC_IP"
    next
end

The upstream network must route or deliver that public address to the FortiGate. Configuring an IP pool alone does not guarantee that return traffic will reach the firewall.

FortiGate can also use central SNAT. When central NAT is enabled, source translation is managed under the central SNAT table rather than only by NAT settings inside each IPv4 policy. Check the operating mode before troubleshooting:

show full-configuration system settings | grep central-nat

Avoid mixing assumptions from policy NAT and central NAT, because the GUI workflow and translation rule location differ.

How does destination NAT with a virtual IP work?

A FortiGate virtual IP, commonly called a VIP, maps an external address or port to an internal server. The VIP must also be selected as the destination object in a matching inbound firewall policy.

Create a port-forwarding VIP for the DMZ HTTPS server:

config firewall vip
    edit "WEB_HTTPS_VIP"
        set extip 203.0.113.20
        set mappedip "10.10.20.10"
        set extintf "port1"
        set portforward enable
        set extport 443
        set mappedport 443
    next
end

Now create the WAN-to-DMZ policy:

config firewall policy
    edit 0
        set name "Internet_to_DMZ_HTTPS"
        set srcintf "port1"
        set dstintf "port3"
        set action accept
        set srcaddr "all"
        set dstaddr "WEB_HTTPS_VIP"
        set schedule "always"
        set service "HTTPS"
        set nat disable
        set logtraffic all
    next
end

The packet path is, in simplified terms: ingress interface → VIP lookup and destination translation → route lookup → firewall policy → security inspection → forwarding. Existing sessions can take a faster path because FortiGate already has the session state.

Source NAT is normally unnecessary on this inbound policy. The DMZ server should use FortiGate 10.10.20.1 as its gateway, or another routing design must ensure that replies return through the same firewall.

What should FortiGate traffic logging include?

FortiGate traffic logs should identify the policy, interfaces, source, destination, ports, action, NAT information and session result. Enable logging on important allow rules as well as deny events so that investigators can reconstruct what happened.

set logtraffic all records accepted traffic for the policy. Logs are generally generated when a session ends; set logtraffic-start enable can additionally create a start log when early visibility is required, but it increases log volume.

config firewall policy
    edit <policy-id>
        set logtraffic all
        set logtraffic-start enable
    next
end

Common destinations include local memory or disk where supported, FortiAnalyzer, FortiGate Cloud and an external syslog server. Retention depends on the destination, storage capacity and log policy.

A basic syslog configuration is:

config log syslogd setting
    set status enable
    set server "10.10.30.20"
    set port 514
    set facility local7
end

Confirm that routing and firewall controls permit traffic from the FortiGate to the log server. Security teams can then correlate firewall events with endpoint, identity and application data. For an introduction to searching centralised security events, see Splunk for beginners.

How do you troubleshoot a FortiGate policy or NAT problem?

Trouhoot the path in a fixed order: interface, addressing, route, policy, NAT, return route and logs. Changing several settings at once can hide the original fault and create additional problems.

1. Check interfaces and routes

get system interface physical
get router info routing-table all
execute ping 203.0.113.1

Confirm that the expected interface is up and that a route exists for the destination. If a source-specific test is required, set the ping source temporarily:

execute ping-options source 203.0.113.10
execute ping 203.0.113.1
execute ping-options reset

2. Check policy direction and objects

Verify that srcintf and dstintf follow the actual routed path. Confirm that address objects contain the correct subnet and that the required service includes the correct protocol and port.

show firewall address
show firewall vip
show firewall policy

A common mistake is using the internal server address as the inbound policy destination instead of the VIP object.

3. Capture packets

Use the built-in sniffer to confirm whether packets enter and leave the firewall:

diagnose sniffer packet any 'host 10.10.10.50 and port 443' 4 0 l

Verbosity level 4 shows interface names and packet headers. Stop the capture with Ctrl+C. Run narrow capture filters on busy production devices.

4. Trace policy processing

Debug flow shows route, policy and session decisions for matching packets:

diagnose debug reset
diagnose debug flow filter addr 10.10.10.50
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 20

After collecting the test traffic, stop debugging:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

Look for messages indicating a policy match, SNAT selection, route failure or denial. Use debug commands carefully because broad filters can produce substantial output.

5. Inspect the session table

diagnose sys session filter src 10.10.10.50
diagnose sys session list
diagnose sys session filter clear

The session entry can show the selected policy, interfaces and translated addresses. Remember that an existing session can continue using its established state after a policy edit; clear only the relevant test session when necessary, not the entire session table on a production firewall.

What are good FortiGate policy practices?

Use least privilege, descriptive objects, deliberate policy order and reliable logging. Review inactive rules and temporary access regularly rather than allowing the rule base to grow without ownership.

• Permit only required source, destination and service combinations.
• Keep management access separate from ordinary user traffic.
• Apply security profiles according to the organisation's inspection design and licences.
• Document why each public VIP and outbound IP pool exists.
• Verify symmetric return routing for published servers.
• Back up the configuration before major changes.
• Send important logs to a central system with suitable retention.

Summary

FortiGate policies decide whether routed traffic is allowed, source NAT provides outbound address translation, and VIPs publish internal services through destination NAT. Logging, packet captures, debug flow and session inspection provide the evidence needed to diagnose failed connections methodically.

To practise these FortiGate firewall basics in guided network-security and SOC labs, enquire about upcoming batch details for the Cybersecurity & SOC course.

Reviewed by Network Rhinos cybersecurity trainers.