Course menu

Module 2: Firewall PoliciesLesson 2.5 (5 of 5 in this module)10 of 18 in the FortiGate Administrator course

Lab: LAN, DMZ and Internet policies

Build FGT1's first rule base: LAN to Internet, LAN to the DMZ web server, admin access, then fix five broken policies.

Intermediate · 25 min read

What you will learn

After this lesson, you can build FGT1's first rule base from objects to logged policies, verify it with sessions and logs, and diagnose five faults with debug flow and policy lookup.

  • Policies
  • Objects
  • Verification
  • Troubleshooting

A rule base is the ordered list of firewall policies on a FortiGate. A good one allows exactly the traffic the organisation needs, in the right order, using named objects, with NAT where traffic leaves for the Internet and logging on every policy that matters.

In simple terms: The list of rules that says who may go where. Build it from named pieces, put it in the right order, and log what it does.

The situation

FGT1 is set up as in the first-login lesson: port1 203.0.113.2/30 to the ISP, port2 10.0.1.1/24 for the LAN, port3 10.0.2.1/24 for the DMZ, a default route and DNS. There are no policies yet, so the implicit deny drops everything. Requirements:

  • Staff (10.0.1.0/24) may browse the web (HTTP, HTTPS) and use DNS, with NAT.
  • Staff may reach WEB1 (10.0.2.10) on HTTP and HTTPS, without NAT.
  • Admin PCs (10.0.1.20–10.0.1.29) may also use SSH to WEB1.
  • Everything else is dropped and logged.
port1203.0.113.0/30port210.0.1.0/24port310.0.2.0/24InternetISP gateway 203.0.113.1FGT1FortiGatePC1LAN · 10.0.1.10WEB1DMZ · 10.0.2.10
  1. 1. LAN to Internet: HTTP, HTTPS and DNS, translated to 203.0.113.2.
  2. 2. LAN to DMZ: Web for staff, SSH for admin PCs only, no NAT.

Task 1: plan it

Show the plan
Seq.NameFrom → toSource → destinationServiceNAT
1Admin-SSH-DMZport2 → port3Admin-PCs → WEB1SSHNo
2LAN-to-DMZ-Webport2 → port3LAN-subnet → WEB1HTTP, HTTPSNo
3LAN-to-Internetport2 → port1LAN-subnet → allHTTP, HTTPS, DNSYes
4Deny-All-Logany → anyall → allALL(deny)

Policies 1 and 2 don't overlap in service, so their order between themselves doesn't matter; the deny must be last.

Task 2: the objects

Show the configuration
config firewall address edit LAN-subnet set subnet 10.0.1.0 255.255.255.0 next edit Admin-PCs set type iprange set start-ip 10.0.1.20 set end-ip 10.0.1.29 next edit WEB1 set subnet 10.0.2.10 255.255.255.255 next end

Task 3: the policies

Show the configuration
config firewall policy edit 1 set name "Admin-SSH-DMZ" set srcintf "port2" set dstintf "port3" set srcaddr "Admin-PCs" set dstaddr "WEB1" set action accept set schedule "always" set service "SSH" set logtraffic all next edit 2 set name "LAN-to-DMZ-Web" set srcintf "port2" set dstintf "port3" set srcaddr "LAN-subnet" set dstaddr "WEB1" set action accept set schedule "always" set service "HTTP" "HTTPS" set logtraffic all next edit 3 set name "LAN-to-Internet" set srcintf "port2" set dstintf "port1" set srcaddr "LAN-subnet" set dstaddr "all" set action accept set schedule "always" set service "HTTP" "HTTPS" "DNS" set nat enable set logtraffic all next edit 4 set name "Deny-All-Log" set srcintf "any" set dstintf "any" set srcaddr "all" set dstaddr "all" set action deny set schedule "always" set service "ALL" set logtraffic all next end

Created in this order, the sequence matches the plan. If you add a policy later, move it above Deny-All-Log.

Task 4: verify

From PC1, browse a website and open http://10.0.2.10. Then on FGT1:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys session list | grep policy_id
misc=0 policy_id=3 ...
misc=0 policy_id=3 ...
misc=0 policy_id=2 ...
First set diagnose sys session filter src 10.0.1.10. Internet sessions use policy 3, the DMZ web session policy 2. (Output trimmed.) In Log & Report › Forward Traffic the same sessions appear with their policy IDs, and SSH attempts from PC1 (not an admin PC) appear as denied by policy 4.

Find the fault

Fault 1

Nobody on the LAN can browse. Debug flow for a PC1 connection to the Internet shows:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # (debug flow, trimmed)
msg="vd-root:0 received a packet(proto=6, 10.0.1.10:50112->198.51.100.80:443) from port2. flag [S], ..."
msg="find a route: flag=04000000 gw-203.0.113.1 via port1"
msg="Denied by forward policy check (policy 4)"
Show diagnosis

The traffic reached the logged deny, so policy 3 didn't match. show firewall policy 3 reveals set srcintf "port3": the incoming interface is wrong. Fix: set srcintf "port2".

Fault 2

Browsing to IP addresses works, but no website name resolves. PCs use 1.1.1.1 as their DNS server.

Show diagnosis

DNS was left out of policy 3's services, so DNS queries from the LAN hit the deny policy. Fix: append service DNS in policy 3. (Remember: set service DNS would remove HTTP and HTTPS.)

Fault 3

A new policy "Block-Games" (deny, LAN-subnet to a games FQDN group) was added, but games still load.

Show diagnosis

New policies go to the bottom: Block-Games sits after LAN-to-Internet, which matches first, and after Deny-All-Log. Fix: move 5 before 3 (its ID is 5) inside config firewall policy.

Fault 4

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys session list (one session, trimmed)
hook=post dir=org act=noop 10.0.1.10:50120->198.51.100.80:443(0.0.0.0:0)
misc=0 policy_id=3 ...

Sessions are created with policy 3, but web pages never load.

Show diagnosis

act=noop and no translated address: NAT is off on policy 3, so packets leave with the private source 10.0.1.10 and replies can't come back. Fix: set nat enable. A working session shows act=snat … (203.0.113.2:…).

Fault 5

Staff can't reach the DMZ website. Policy Lookup for TCP 443 from 10.0.1.10 to 10.0.2.10 on port2 returns policy 4, the deny.

Show diagnosis

Policy 2 exists with the right interfaces and services, so check its objects: show firewall address WEB1 shows set subnet 10.0.2.100 255.255.255.255. The object points at the wrong host. Fix: correct the object; every policy that uses WEB1 is fixed at once.

Check yourself

Predict · scenario 1

In this rule base, PC1 (not an admin PC) tries SSH to WEB1. Which policy handles it?

Predict · scenario 2

Why is NAT off on the LAN-to-DMZ policies?

Predict · scenario 3

Which command adds DNS to policy 3 without removing HTTP and HTTPS?