FortiGate policy zone then NAT then session

Lessons · FortiGate series · Zones, policy, NAT

Hero · host hits a zone, not a port nickname

Why a route is not a session

The day-one ticket is always the same: “Routing is fine, so the firewall is broken.” Wrong. RIB lookup only names the egress interface. FortiOS still needs a firewall policy whose srcintf / dstintf (interface or zone), addresses and service cover that 5-tuple. No match → implicit deny. No accept → no session to list.

Three silent-zero states look identical from the host (timeout):

• Default route exists; policy is still LAN→LAN or missing dest zone WAN.
• Policy is accept, but srcintf is port2 while the packet arrived on a VLAN that is not in that object — zone membership is the real incoming interface.
• VIP exists; no WAN→LAN policy with that VIP as dstaddr. DNAT without accept is still a drop.

Zone, policy, NAT — three objects

A zone is an interface object: one or more physical, VLAN, LAG or tunnel interfaces grouped so a policy can say LAN instead of listing every port. Members of the same zone do not need a policy to talk to each other unless you enable intra-zone block. Policies still match on the zone name as srcintf / dstintf.

A firewall policy is the allow/deny. Required match fields: incoming interface(s), outgoing interface(s), source address(es), destination address(es), service(s), schedule. Optional: user, internet-service, security profiles. Action is accept or deny. NAT is a separate knob on that policy, or a separate VIP / Central NAT table.

Path · zone, then policy, then NAT, then session

How a session is built

Existing session first. If FortiOS already has the 5-tuple, later packets skip policy lookup and follow the installed NAT hooks. New flows walk the full path. DNAT (VIP / Central DNAT) rewrites destination before routing and policy so the RIB and the dest-zone match the real server. SNAT runs after accept.

Policy NAT vs VIP vs Central NAT

Pick the NAT engine the VDOM is actually running. Mixing them is the usual “NAT is on but nsrc is wrong” ticket.

Runbook Side A / B / C

Side A is objects. Side B is the policy and NAT. Side C is the session table. Do not start at C.

Side A — zones and addresses

1. Zone LAN and WAN

   Network › Interfaces › Create New › Zone. Lab: LAN member = internal (or port2); WAN member = wan1. CLI config system zone. Address on the member interface, not on the zone: LAN 10.20.20.1/24, WAN 192.0.2.1/24. Source: FortiOS Administration Guide — Zone.

2. Address object

   Policy & Objects › Addresses — LAN_NET subnet 10.20.20.0/24. Do not use all as source on the first outbound policy if you want a readable session later.

config system zone
    edit "LAN"
        set interface "internal"
    next
    edit "WAN"
        set interface "wan1"
    next
end
config firewall address
    edit "LAN_NET"
        set subnet 10.20.20.0 255.255.255.0
    next
end
config router static
    edit 1
        set gateway 192.0.2.254
        set device "wan1"
    next
end

Side B — policy then NAT

1. Outbound accept + SNAT

   Policy id 1 LAN-to-WAN: srcintf LAN, dstintf WAN, srcaddr LAN_NET, dstaddr all, service ALL, action accept, nat enable, logtraffic all. This is hide-NAT to 192.0.2.1.

2. Inbound VIP (separate from allow)

   Policy & Objects › Virtual IPs — web_pub, interface WAN, external 192.0.2.80 map to 10.20.20.80, port 443→443. Then policy id 2 WAN→LAN, dstaddr web_pub, service HTTPS, accept, NAT off unless the server’s gateway is not the FGT.

config firewall policy
    edit 1
        set name "LAN-to-WAN"
        set srcintf "LAN"
        set dstintf "WAN"
        set srcaddr "LAN_NET"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
        set logtraffic all
    next
end
config firewall vip
    edit "web_pub"
        set extintf "WAN"
        set extip 192.0.2.80
        set mappedip "10.20.20.80"
        set portforward enable
        set protocol tcp
        set extport 443
        set mappedport 443
    next
end
config firewall policy
    edit 2
        set name "WAN-to-WEB"
        set srcintf "WAN"
        set dstintf "LAN"
        set srcaddr "all"
        set dstaddr "web_pub"
        set action accept
        set schedule "always"
        set service "HTTPS"
        set nat disable
        set logtraffic all
    next
end

Side C — prove the session

1. Filter, then list

   From 10.20.20.10 open HTTPS to 203.0.113.80. On the FGT: diagnose sys session filter clear, diagnose sys session filter src 10.20.20.10, diagnose sys session filter dport 443, diagnose sys session list. Source: FortiOS — Using a session table.

2. Read the hooks

   You want policy_id=1, hook=post dir=org act=snat with (192.0.2.1:…), and bytes on org and reply. Empty list after a live attempt = no accept. act=noop on org = accept without SNAT.

3. Clear after an edit

   diagnose sys session filter src 10.20.20.10 then diagnose sys session clear so the next packet re-walks policy. Old sessions keep old NAT.

diagnose sys session filter clear
diagnose sys session filter src 10.20.20.10
diagnose sys session filter dport 443
diagnose sys session list
# session info: proto=6 proto_state=11 …
# hook=post dir=org act=snat 10.20.20.10:54321->203.0.113.80:443(192.0.2.1:54321)
# hook=pre dir=reply act=dnat 203.0.113.80:443->192.0.2.1:54321(10.20.20.10:54321)
# policy_id=1  vd=0
# nsrc / nport match the SNAT you intended

diagnose firewall iprope lookup 10.20.20.10 54321 203.0.113.80 443 6 internal
# which policy would match — use when list is empty (device = ingress member, proto 6 = TCP)

One flow after go-live

Host 10.20.20.10 SYN to 203.0.113.80:443. Ingress LAN. Session miss. No VIP. RIB: default via 192.0.2.254, egress WAN. Policy 1 matches LAN/WAN/LAN_NET/all/ALL. Accept. SNAT source to 192.0.2.1. Session installed. Reply hits WAN, reverse DNAT to 10.20.20.10, egress LAN. Second packet of the same 5-tuple skips policy and uses the hooks.

Inbound: SYN to 192.0.2.80:443. VIP DNAT to 10.20.20.80:443. Route to LAN. Policy 2 matches WAN/LAN/all/web_pub/HTTPS. Accept, no SNAT. Session act=dnat on org. Hairpin from 10.20.20.10 to 192.0.2.80 needs extra policy + often SNAT so the server replies via the FGT — that is a different ticket.

Proof · session built is a table row, not a dashboard tile

diagnose debug reset
diagnose debug flow filter addr 10.20.20.10
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 20
# look for: find a route / allowed by policy 1 / SNAT 10.20.20.10 -> 192.0.2.1
# or: denied by policy 0  → zone/address/service miss, not a NAT bug
diagnose debug disable

Traps + proof

Sources

• FortiOS Administration Guide — Firewall policy (incoming/outgoing interface, address, service, schedule; VIP vs ordinary policy / match-vip)
• FortiOS Administration Guide — Zone
• FortiOS Administration Guide — Using a session table (diagnose sys session filter / list / clear; nsrc/nport)
• FortiOS Best Practices — Policies (specific interface, not any; zones group interfaces)
• FortiOS Administration Guide — Destination NAT / Configuring VIPs; Source NAT / Central SNAT (policy NAT vs central-nat)
• Fortinet Community — Technical Tip: How to check NGFW policy matching (diagnose sys session list shows policy_id and SNAT hooks)
• FortiOS — Using the debug flow tool (diagnose debug flow trace start)

Related: Policy first-match · FortiGate command center · FortiGate interview · VDOMs