NSE4 / FCP FortiGate 7.6 — Course-to-Exam Study Guide

Lab 1 — NAT header arithmetic

LessonL03·QuestionsQ39Q42Q57Q68·Time45 min

Four of the policy questions are NAT arithmetic against an exhibit. Here you produce the exhibit yourself: the session table prints the before-and-after address of every flow, and both Linux boxes log the client address they actually see.

Build

config firewall ippool
    edit "pool-1to1"
        set type one-to-one
        set startip 203.0.113.111
        set endip 203.0.113.112
    next
    edit "pool-overload"
        set type overload
        set startip 203.0.113.101
        set endip 203.0.113.101
    next
end
config firewall vip
    edit "vip-web"
        set extintf "wan1"
        set extip 203.0.113.10
        set mappedip "10.0.1.20"
        set portforward enable
        set extport 8080
        set mappedport 80
    next
end
config firewall policy
    edit 0
        set name "lan-out"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
        set ippool enable
        set poolname "pool-1to1"
    next
    edit 0
        set name "web-in"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "vip-web"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

Pool and VIP addresses must be unused addresses on wan1's subnet — the FortiGate answers ARP for them. On the internal VM, add 10.0.1.11 and 10.0.1.12 as extra addresses so one VM can play three PCs, and run sudo python3 -m http.server 80 as the lab server. On the outside host, run python3 -m http.server 8000.

Read translations with:

diagnose sys session filter clear
diagnose sys session filter dst 203.0.113.50
diagnose sys session list

In each entry, the hook=post dir=org act=snat line shows the original source → destination with the translated source in brackets. Between steps, clear the old sessions with diagnose sys session clear — it clears whatever the filter matches, so set a filter first: with no filter it clears every session on the box, your SSH login included.

Run it

1. Hold two sessions open from the first two addresses (nc -s 10.0.1.10 203.0.113.50 8000, then again from .11), then from the third run curl --interface 10.0.1.12 http://203.0.113.50:8000/.

   Predict: which source address does the outside host see for each client, and does the third one get out?

   What you should see

   The first two each take one pool address and keep their own source ports — one-to-one does no port translation. The third times out: both addresses are in use and there isn't a third to hand out. Both of Q68's fixes work: set type overload, or set endip 203.0.113.113.

2. Point lan-out at pool-overload, clear the filtered sessions, and repeat.

   Predict: what source address and ports do the three clients get?

   What you should see

   All three share 203.0.113.101. The session list shows each one with a different translated source port — that's what overload means.

3. On lan-out, set ippool disable (leave NAT on) and repeat. Then turn the pool back on.

   Predict: the source address with the pool off, and with it back on.

   What you should see

   Pool off: the source is wan1's own address. Pool on: the pool address again. Whenever the policy names a pool, the pool beats the interface address — Q39 and Q57.

4. From the outside host: curl http://203.0.113.10:8080/. Filter the session list on src 203.0.113.50.

   Predict: the source IP, source port, destination IP and destination port that the lab server receives.

   What you should see

   A hook=pre dir=org act=dnat line: 203.0.113.50:<port>->203.0.113.10:8080(10.0.1.20:80). The destination and port are rewritten; the source is untouched — the lab server's access log shows 203.0.113.50 itself. That's Q42.

Lab 2 — Policy order, the VIP deny, and implicit deny

LessonL03·QuestionsQ7Q37Q51Q64Q73Q81·Time40 min·NeedsLab 1's config

1. Run show firewall policy and note the IDs that edit 0 assigned. Move web-in above lan-out: config firewall policy → move <web-in id> before <lan-out id> → end. Then look at the policy list in both GUI views.

   Predict: do the IDs change? What does each view show?

   What you should see

   The IDs never change — an ID is fixed at creation and is not the evaluation order (Q37). By Sequence shows the new order. Interface Pair View groups policies by interface pair, and these two have different pairs, so the move doesn't show there at all (Q7).

2. Try to add wan2 as a second source interface on lan-out.

   Predict: will the GUI let you?

   What you should see

   Not until System → Feature Visibility → Multiple Interface Policies is on. After that, the source interface field takes both (Q51).

3. Block the outside host from the VIP. Create a policy above web-in: wan1 → internal, source = a host address object for 203.0.113.50, destination all, action deny, set logtraffic all. Check the setting that matters with show full-configuration firewall policy <id> | grep match-vip. Test the curl from Lab 1 step 4. Then set the destination to vip-web and test again. Finally, put the destination back to all, flip match-vip, and test a third time.

   Predict: blocked or not, for each of the three versions.

   What you should see

   Destination = vip-web: blocked every time — that's Q73's answer. Destination = all: the result follows match-vip, because letting a deny policy match traffic a VIP already translated is the setting's only job. Write down the default your build showed; this page says new deny policies ship with it enabled.

4. Disable lan-out (set status disable) and curl out from the client while debug flow runs (commands in Lab 6). Then trigger the step 3 deny from the outside host with debug flow filtered on 203.0.113.50.

   Predict: the drop line in each trace.

   What you should see

   The client's traffic: Denied by forward policy check (policy 0) — policy 0 is the implicit deny. The outside host's traffic: the same line with your deny policy's ID. That one number is how Q64 separates implicit from explicit deny.

5. Run a single curl --max-time 20 at the denied VIP — the client retransmits its SYN on the same ports, which is exactly the case this setting targets. Note the session list and the Forward Traffic log. Then enable config system settings → set ses-denied-traffic enable and repeat.

   Predict: what changes in the session table, and in the log count?

   What you should see

   With the setting on, the denied flow gets a session entry (held for block-session-timer), so later packets match the session instead of being re-evaluated one by one. Q81's key says that also means fewer log entries — count yours and see whether it agrees.

Lab 3 — Application sensor: which entry wins

LessonsL10, L07·QuestionsQ10Q17Q21Q45Q65·Time60 min·NeedsLab 14's deep-inspection profile

Pick an application you can actually generate. Under Security Profiles → Application Signatures you can filter by Behavior and Vendor: choose one whose behaviour includes Excessive-Bandwidth (streaming video sites are the usual candidates) and note its vendor.

Build

Put a new application sensor on lan-out with your deep-inspection profile. Under Application and Filter Overrides, add two entries in this order:

1. Filter — Behavior: Excessive-Bandwidth → Block
2. Filter — Vendor: your app's vendor → Allow

Run it

1. Open the application from the client.

   Predict: does it load?

   What you should see

   Blocked. Overrides are evaluated top-down and the first match wins, so the vendor Allow below never gets a look. Security Events → Application Control shows the block. That's Q65, and half of Q10.

2. Move the vendor entry to the top and try again.

   Predict: does it load now?

   What you should see

   Yes. "Move it above the block" is Q21's second answer.

3. Put the Block entry back on top. Switch the policy's SSL profile to certificate-inspection, use the app again, and compare the Application Control log with what deep inspection produced.

   Predict: more identifications or fewer?

   What you should see

   Fewer and coarser. With certificate inspection, app control only sees the SNI and the certificate, so anything that can only be recognised inside the encrypted payload goes unseen. That's why Q21's first answer is deep inspection.

4. Set the winning entry's action to Monitor, generate traffic, then set it to Allow and generate more.

   Predict: which action writes an Application Control log?

   What you should see

   Monitor logs; Allow doesn't. The traffic still appears under Forward Traffic, just not as a security event (Q45).

5. In the sensor, turn on Network Protocol Enforcement: map TCP 80 to HTTP, violation action Block. On the outside host, run SSH on port 80 (sudo /usr/sbin/sshd -p 80) and connect from the client with ssh -p 80.

   Predict: does the SSH session come up?

   What you should see

   Blocked. SSH isn't HTTP, so it violates port 80's expected protocol. This is the control that catches applications tunnelled over standard ports (Q17).

Lab 4 — IPS: a signature you can trigger on demand

LessonL10·QuestionsQ18Q48Q53·Time45 min·NeedsLab 1's VIP

Real attack signatures are hard to fire on cue, so write your own that matches a harmless word in a URL.

Build

config ips custom
    edit "lab.trigger"
        set signature "F-SBID( --name \"lab.trigger\"; --protocol tcp; --service HTTP; --flow from_client; --pattern \"labtrigger\"; --context uri; --no_case; )"
    next
end

In the GUI, create an IPS sensor lab-ips, add lab.trigger as an individual signature with action Block and Packet logging on. Don't attach it to a policy yet.

Run it

1. With no IPS sensor on any policy, run diagnose test application ipsmonitor 1 and save the output.
2. Attach lab-ips to web-in. From the outside host: curl -s -o /dev/null -w '%{http_code}\n' --max-time 3 http://203.0.113.10:8080/labtrigger

   Predict: what curl prints, and where the evidence ends up.

   What you should see

   000 — the request is dropped. Security Events → Intrusion Prevention has an entry, and because packet logging is on, the entry carries a copy of the matching packet (Q53). Run ipsmonitor 1 again and compare it with step 1: engine output from a box where no policy uses IPS is Q18's exhibit.

3. Make it rate-based. Find the entry ID with show ips sensor lab-ips, then:

   config ips sensor
       edit "lab-ips"
           config entries
               edit <id>
                   set rate-count 5
                   set rate-duration 60
                   set rate-mode periodical
                   set rate-track src-ip
               next
           end
       next
   end

   Run the curl ten times in a loop: for i in $(seq 10); do curl -s -o /dev/null -w '%{http_code}\n' --max-time 3 http://203.0.113.10:8080/labtrigger; done

   Predict: which of the ten requests get through?

   What you should see

   The early requests in the window return 200; blocking (000) starts once the count is reached, and resets after rate-duration. Rate-based blocking is set on a signature entry, not on a filter or a signature group (Q48). Try rate-mode continuous and compare.

Lab 5 — HA: election, override, forced failover

LessonL13·QuestionsQ22Q29Q54Q60Q80·Time90 min·Needstwo matching units

Build (both units)

config system ha
    set group-id 10
    set group-name "lab"
    set mode a-p
    set password <lab-password>
    set hbdev "port3" 50
    set monitor "port1"
    set override disable
end

Cable the heartbeat port directly between the units. Wait more than five minutes after the cluster forms before step 2: HA uptime differences smaller than ha-uptime-diff-margin (300 seconds by default) are ignored, and a lab run inside that window gives you priority-based results that won't match the flashcards.

Run it

P is whichever unit is primary right now; S is the other one.

1. Run get system ha status and read the "Primary selected using" lines.

   Predict: which unit is primary, and which criterion decided it?

   What you should see

   The reason line names the deciding criterion. With override off, the order is monitored ports → HA uptime → priority → serial number, and uptime only counts once the gap exceeds the margin.

2. On S, set priority 200 (P stays at the default 128).

   Predict: failover?

   What you should see

   No. With override disabled, uptime is weighed before priority, and changing priority on its own doesn't start a new election (Q60).

3. On P: diagnose sys ha reset-uptime.

   Predict: what happens?

   What you should see

   S takes over immediately, because P's HA uptime is now the youngest. With override off, this is the documented way to move the primary role (Q80).

4. On the old P (now secondary), set override enable and set priority 250. Then run show system ha on both units.

   Predict: who is primary, and what does the other unit's config say about override?

   What you should see

   The old P takes the role back: with override on, priority is weighed ahead of uptime. The other unit still says override disable — override and priority are per-unit settings that don't synchronise (Q29).

5. On the primary, take the monitored port down: config system interface → edit port1 → set status down → end.

   Predict: failover?

   What you should see

   Yes — to the unit with all its monitored ports up. Monitored ports come first in the election whether override is on or off, and an admin-down counts (Q54). Bring the port back up and watch the override unit reclaim the role.

6. Diff show full-configuration system ha and get system ha status between the two units.

   Predict: before you diff, list which lines you expect to differ.

   What you should see

   Only the per-unit lines differ — priority, override, and the status fields. Finding the one line that differs and naming the election rule it feeds is the whole method for paired-exhibit questions like Q22.

Last, try the explicit test switch: execute ha failover set 1 on the primary, then get system ha status — the reason line cites the EXE_FAIL_OVER flag. The cluster stays that way until execute ha failover unset 1.

Lab 6 — Read debug flow, then read conserve mode

LessonL14·QuestionsQ19Q41Q44Q83·Time40 min

The trace recipe

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr 10.0.1.10
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 20
diagnose debug enable
#   ... generate the traffic ...
diagnose debug disable

Run it

1. With lan-out enabled, run curl http://example.com from the client.

   Predict: the egress interface, the next-hop gateway, the policy, and the translated source.

   What you should see

   Three lines carry the answer (illustrative — your IDs, ports and flags will differ):

   msg="find a route: flag=... gw-203.0.113.1 via wan1"
   msg="Allowed by Policy-1: SNAT"
   msg="SNAT 10.0.1.10->203.0.113.101:61234"

   The via interface and the gw- address are how Q83 identifies the default gateway; the policy line gives you allow or deny.

2. Disable lan-out and repeat.

   Predict: the drop line.

   What you should see

   Denied by forward policy check (policy 0) — the implicit deny. The RPF drop line, reverse path check fail, drop, comes up in Lab 10. Learn to tell the two apart at a glance.

3. Now the conserve-mode half. Don't push a box into conserve mode on purpose — reading the settings that decide its behaviour is the lab.

   diagnose hardware sysinfo conserve
   get system performance status
   show full-configuration system global | grep av-failopen
   show full-configuration system global | grep memory-use-threshold
   show full-configuration ips global | grep fail-open

   Predict: with the values you just read, the box crosses the red threshold. What happens to (a) a new session through a proxy-inspected policy, (b) a new session through a flow policy with IPS, and (c) a config change you try to save?

   What you should see

   The defaults are av-failopen pass, IPS fail-open disable, and thresholds of 82% (green), 88% (red) and 95% (extreme). So: (a) the proxy is bypassed and traffic flows uninspected; (b) new sessions that need IPS are dropped; (c) the change is refused. Change either fail-open setting and the answers flip — which is why Q41 and Q44 have different keys, and why Q19 depends on the exhibit.

Lab 7 — FSSO: agentless polling, then the collector

LessonL06·QuestionsQ12Q30Q31Q46Q66Q74Q78·Time90 min·NeedsWindows DC and a domain-joined client

Run it

1. Go to Security Fabric → External Connectors → Create New → Poll Active Directory Server. Enter the DC's address and a domain account that can read the Security event log. Then create an FSSO user group and try to add AD groups to it.

   Predict: which AD groups can you pick? Is there a workstation-check option anywhere?

   What you should see

   None, until you add the DC under User & Authentication → LDAP Servers and select that server on the connector. Polling reads logon events, not group membership (Q78). There's no workstation check in this mode (Q12).

2. Use the FSSO group as lan-out's source. Log on at the client and browse, then run diagnose debug fsso-polling detail and diagnose firewall auth list.
3. Break it. Disable the connector, clear the user list with diagnose firewall auth clear, then log on at the client again.

   Predict: Windows logon works but browsing doesn't. What do you check first?

   What you should see

   The FortiGate's list of logged-on users — diagnose firewall auth list — for the client's IP. It's empty, which tells you the logon never arrived, before you spend any time on AD groups or SSL (Q74).

4. Optional — the collector. From the Fortinet support site, install the Collector Agent on a member server and the DC Agent on the DC. Point the FortiGate at the collector (External Connectors → FSSO Agent on Windows AD), and sniff on the FortiGate: diagnose sniffer packet any 'tcp port 8000' 4 0 a

   Predict: which addresses talk to the FortiGate, and who opens the connection?

   What you should see

   Only the collector's address, on TCP 8000 — the SYN shows which side initiates. Nothing ever arrives from the DC: the DC agent reports to the collector over UDP 8002 and never to the FortiGate (Q31, Q66). Check diagnose debug authd fsso server-status for the connection state. While you're in the collector, switch it between Standard and Advanced group mode and watch the group-name format change on the FortiGate (Q30). Then compare NetAPI with event-log polling by logging off at the client under each and watching diagnose debug authd fsso list (Q46).

Lab 8 — IPsec: break phase 2 on purpose

LessonL11·QuestionsQ9Q25Q40Q49Q67·Time90 min·NeedsFortiGate-VM trial as the peer

The trial VM only offers DES-based proposals, so the 70F has to match them. That's weak on purpose — lab only. The VM's LAN is 10.0.2.0/24 and its port1 is 203.0.113.60.

Build (70F side; mirror it on the VM)

config vpn ipsec phase1-interface
    edit "to-vm"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set proposal des-sha256
        set dpd on-demand
        set remote-gw 203.0.113.60
        set psksecret <lab-psk>
    next
end
config vpn ipsec phase2-interface
    edit "to-vm-p2"
        set phase1name "to-vm"
        set proposal des-sha256
        set src-subnet 10.0.1.0 255.255.255.0
        set dst-subnet 10.0.2.0 255.255.255.0
    next
end
config router static
    edit 0
        set dst 10.0.2.0 255.255.255.0
        set device "to-vm"
    next
end

Add accept policies in both directions between internal and to-vm, with NAT off. Bring it up and ping across. The commands for every step: get vpn ipsec tunnel summary, diagnose vpn ike gateway list, diagnose vpn tunnel list, and diagnose debug application ike -1 followed by diagnose debug enable. To force renegotiation, use diagnose vpn ike gateway clear — it clears every IKE gateway on the box.

Run it

1. On the VM, change dst-subnet to 10.0.9.0/24. Clear and renegotiate.

   Predict: phase 1 up or down? Phase 2?

   What you should see

   Phase 1 is established; phase 2 never comes up — the summary shows no selectors up, and the IKE debug complains about traffic selectors. Mismatched selectors are one of Q25's two answers.

2. Restore the selector, then set the VM's phase 2 proposal to des-sha1.

   Predict: the symptom this time.

   What you should see

   The same — phase 1 up, phase 2 down — and the debug says no SA proposal chosen. That's Q25's other answer.

3. Restore the proposal. On the VM only, set keylifeseconds 3600 in phase 2.

   Predict: does it come up?

   What you should see

   Yes. A lifetime mismatch doesn't stop phase 2 — which is exactly why it's Q25's distractor.

4. With dpd on-demand, stop all traffic and take the VM's port1 down. Wait a minute with the IKE debug running, then ping across.

   Predict: when do DPD probes start?

   What you should see

   Nothing happens while the tunnel is idle. Probes start only once you send traffic and nothing comes back — that's On Demand (Q9). Set dpd on-idle and repeat: now the probes start during the idle period.

5. Add a second tunnel, to-vm2, over wan2 to the VM's port3. On the 70F, give the route via to-vm distance 10 and the route via to-vm2 distance 20. On the VM, put both tunnels in one zone so its policy count stays at two, and mirror the routes — that makes three routes with its default, the trial's maximum. Then cut the primary path.

   Predict: how does traffic move, and what triggers the move?

   What you should see

   DPD declares to-vm dead, its route leaves the table, and the distance-20 route via to-vm2 is installed (Q67). Watch it in get router info routing-table all. Turn DPD off and the dead tunnel's route stays in the table while traffic disappears into it.

6. Optional — dial-up. Convert the 70F side to dial-up: set type dynamic, set ike-version 1, set mode aggressive, set peertype one, set peerid "sales", set add-route enable. On the VM: set localid "sales" and aggressive mode.

   Predict: when does the route to 10.0.2.0/24 appear on the 70F? What happens if the VM's localid becomes "eng"?

   What you should see

   The route appears only after phase 2 is up, and only for the subnet named in the phase 2 selectors (Q40). With "eng", no phase 1 matches and the VM can't connect — the peer ID is what lands each dial-up user on the right tunnel (Q49).

Lab 9 — Where each log lands

LessonL02·QuestionsQ1Q13Q16Q70Q84·Time30 min

The 70F has no log disk (the 71F is the storage model), so it logs to memory. That's enough for this lab, but memory logs roll over fast. Set logtraffic all on the policies you use.

1. Generate three events: an allowed browse through lan-out, a hit on Lab 2's deny policy, and an application or web-filter block.

   Predict: which Log & Report page shows each one?

   What you should see

   The allowed and denied sessions are under Forward Traffic. The security-profile block is under Security Events (Q13, Q84).

2. Find a policy's UUID with show firewall policy <id> (the set uuid line). In Forward Traffic, add the Policy UUID column and filter on it, then add an application filter on top.

   Predict: which identifier ties a log line to its policy across FortiGate, FortiAnalyzer and FortiManager?

   What you should see

   The UUID. Policy IDs can repeat across VDOMs and devices; UUIDs can't (Q16). UUID plus application name is how you isolate one entry (Q13).

3. If you have a FortiAnalyzer:

   config log fortianalyzer setting
       set status enable
       set server "<faz-ip>"
       set reliable enable
   end
   execute log fortianalyzer test-connectivity

   Predict: are logs accepted yet?

   What you should see

   Not until you authorise the FortiGate on the FortiAnalyzer, in its Device Manager (Q70). After that, the log settings page shows reliable logging — TCP with acknowledgements — which is the setting Q1 asks about.

Lab 10 — Routing: distance, priority, RPF

LessonL04·QuestionsQ2Q15Q23Q62Q63·Time45 min

Use static routes for this lab. If wan1 is DHCP, its default route arrives at distance 5 and will skew every step.

1. Add two routes to the same prefix:

   config router static
       edit 0
           set dst 192.0.2.0 255.255.255.0
           set gateway 203.0.113.1
           set device "wan1"
           set distance 10
       next
       edit 0
           set dst 192.0.2.0 255.255.255.0
           set gateway 198.51.100.1
           set device "wan2"
           set distance 20
       next
   end

   Compare get router info routing-table all with get router info routing-table database.

   Predict: how many 192.0.2.0/24 routes appear in each?

   What you should see

   The routing table shows only the distance-10 route. The database shows both, with the wan2 route not selected. To move the traffic to wan2, lower its distance or raise wan1's — both of Q23's answers.

2. RPF test. On a Linux host on wan2's segment, add a source address the FortiGate has no reason to expect, and send a ping through: sudo ip addr add 192.0.2.77/32 dev eth0, sudo ip route add 10.0.1.0/24 via 198.51.100.2, ping -I 192.0.2.77 10.0.1.20. Trace it with debug flow filtered on 192.0.2.77.

   Predict: with strict RPF off, does the ping pass the check?

   What you should see

   reverse path check fail, drop. A route back through wan2 exists, but it's inactive (distance 20), so it doesn't count.

3. Set the wan2 route to distance 10 and give it a higher priority number than wan1's (leave wan1 at the default; use 10 on wan2). Ping again.

   Predict: what's in the routing table now, and does RPF pass?

   What you should see

   Both routes are now in the table; traffic prefers the lower priority number (wan1). RPF passes, because the wan2 route is active even though it isn't the best. The trace moves on to policy lookup — and ends at Denied by forward policy check (policy 0) unless you add a wan2 → internal policy. That line alone proves RPF passed. This is Q2.

4. Turn on strict RPF: config system settings → set strict-src-check enable → end. Ping again. Then, on wan2 only: config system interface → edit wan2 → set src-check disable → end, and ping once more.

   Predict: the result after each change.

   What you should see

   Strict: dropped, because the best route back to 192.0.2.77 is via wan1. With src-check disable on wan2: passes — RPF is skipped on that interface, and strict still applies everywhere else (Q15). Undo both.

5. Make the two routes identical (same distance, same priority) and run show full-configuration system settings | grep ecmp.

   Predict: which setting picks the load-balancing method?

   What you should see

   Both routes are used (ECMP), and v4-ecmp-mode in system settings picks the method — source-ip-based by default. Once SD-WAN is enabled, load-balance-mode under config system sdwan takes over (Q63).

6. Create an address object lab-net for 192.0.2.0/24 and try to use it in a static route with set dstaddr "lab-net".

   Predict: accepted?

   What you should see

   Not until the address has set allow-routing enable (Q62).

Lab 11 — Antivirus: why HTTP catches it and HTTPS doesn't

LessonsL08, L07·QuestionsQ43Q56Q76Q79·Time40 min·NeedsLab 14's deep-inspection profile

Build

Download the standard EICAR test file from eicar.org onto the outside host. From the same directory, serve it over both protocols (two terminals):

sudo python3 -m http.server 80
openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 7 -subj "/CN=lab-av"
sudo openssl s_server -accept 443 -cert cert.pem -key key.pem -WWW

Fetch it from the client with:

curl -s  -o /dev/null -w 'http  %{http_code} %{size_download}\n' http://203.0.113.50/eicar.com
curl -sk -o /dev/null -w 'https %{http_code} %{size_download}\n' https://203.0.113.50/eicar.com

(-k is needed because under deep inspection the FortiGate re-signs the lab's self-signed certificate with Fortinet_CA_Untrusted — on purpose.)

Run it

1. Put an antivirus profile on lan-out with the SSL profile set to certificate-inspection.

   Predict: HTTP, HTTPS — blocked or delivered?

   What you should see

   HTTP is blocked. HTTPS delivers all 68 bytes: certificate inspection never decrypts the payload, so there's nothing to scan (Q79, and Q56's first answer).

2. Switch the SSL profile to your deep-inspection profile.

   Predict: both?

   What you should see

   Both blocked.

3. Add 203.0.113.50 to the deep-inspection profile's exempt addresses.

   Predict: HTTPS?

   What you should see

   Delivered again — an exemption is as blind as certificate inspection. That's Q56's second answer.

4. Switch lan-out between flow-based and proxy-based inspection, fetch over HTTP with curl -v in each mode, and compare what the client receives and what the AV log says.

   Predict: how does the client-side experience differ?

   What you should see

   Record it. Proxy mode holds the whole file before deciding. Q76's key says flow mode streams the file while scanning and, on detection, withholds the last packet and resets the session — the EICAR file fits in one packet, so look at what curl actually got.

5. Create a new antivirus profile and turn off every inspected protocol.

   Predict: which settings go grey?

   What you should see

   With no protocol to inspect, the scan settings have nothing to apply to — Q43's greyed-out toggle.

Lab 12 — SD-WAN: rules, the implicit rule, and what beats them

LessonL12·QuestionsQ3Q26Q38Q55Q61·Time60 min

Build the base from the Study Buddy's SD-WAN exercise: wan1 and wan2 as members, a ping performance SLA, and a Lowest Cost (SLA) rule. The SD-WAN SLA lab note walks through the failover. One catch: an interface that a policy or route references can't become a member, so point lan-out and the default route (set sdwan-zone "virtual-wan-link") at the zone first.

1. Try to delete the virtual-wan-link zone. Then create a zone called underlay with no members.

   Predict: what each attempt does.

   What you should see

   The default zone can't be deleted; the new zone lists no members (Q38).

2. Blackhole the SLA target on wan1's path and watch diagnose sys sdwan service and diagnose sys sdwan health-check status.

   Predict: is wan1 still "alive"? Where do new sessions go?

   What you should see

   wan1 stays up and routable; it only fails the SLA, and new sessions move to wan2. The SLA measured the path with probes — not the FortiGate itself (Q3).

3. In the rule editor, cycle through the strategies.

   Predict: which strategies offer load balancing?

   What you should see

   Manual and Lowest Cost (SLA) — Q55's pairings.

4. Disable the rule, generate the same traffic, and look at the SD-WAN rule column in Forward Traffic.

   Predict: which rule name appears?

   What you should see

   None. The traffic took the implicit rule, which has no name to log (Q26).

5. Re-enable the rule (preferring wan1), then add a policy route (Network → Policy Routes) for the same destination out wan2. Check diagnose firewall proute list and where the traffic actually goes.

   Predict: which one wins?

   What you should see

   The policy route — regular policy routes are checked before SD-WAN rules (Q61).

Lab 13 — Web filter: Exempt is not Allow

LessonL09·QuestionsQ8Q28Q52Q59·Time40 min·Needsweb filtering subscription

Look up a site's category with FortiGuard's web filter lookup before you pick a test site. Hostname-level filtering works under certificate inspection (it reads the SNI); full URL paths over HTTPS need deep inspection.

1. Create a web filter profile with the Proxy-based feature set, leave lan-out in flow mode, and try to select the profile on the policy.

   Predict: is it in the drop-down?

   What you should see

   No. A proxy-based profile can't be selected on a flow-based policy (Q8). Change either side to match and it appears — the same mismatch sits behind Q28.

2. Block the Social Networking category. Add a static URL filter entry for a site in that category with action Allow, and browse to it.

   Predict: does it load?

   What you should see

   Still blocked. Allow only ends static URL processing — the request continues to FortiGuard category filtering, which blocks it. Change the action to Exempt and it loads, because Exempt skips the remaining checks (Q59).

3. Take a site in an allowed category and block it two ways: a web rating override that moves it into a blocked category, and a static URL filter entry with action Block.

   Predict: do both work? What happens to the rest of the category?

   What you should see

   Both block the one site and leave the rest of the category alone — Q52's two answers.

Lab 14 — Deep inspection: trust, exemptions, the SNI check

LessonL07·QuestionsQ5Q11Q27·Time45 min·Do beforeLabs 3 and 11

The full SSL inspection lab note explains the handshake this lab exercises.

1. The built-in deep-inspection profile is read-only, so edit custom-deep-inspection or a clone of it. Apply it to lan-out and browse to an HTTPS site from a client that doesn't trust Fortinet_CA_SSL.

   Predict: what the browser does, on HTTPS and on HTTP.

   What you should see

   A certificate warning on every HTTPS site, and the certificate's issuer is the FortiGate. HTTP is unaffected — it has no certificate (Q5).

2. Download Fortinet_CA_SSL from System → Certificates and import it into the client's trust store.

   Predict: do the warnings stop everywhere?

   What you should see

   Everywhere except apps that pin their certificates. Those need an exemption, not more trust.

3. Open the profile's exemption list.

   Predict: which FortiGuard categories are exempt out of the box, and why those?

   What you should see

   Three: Finance and Banking, Health and Wellness, Personal Privacy. The reasons are HSTS/pinned sites breaking under a replacement certificate, and privacy regulation (Q11). If your build lists something different, note it.

4. Test the SNI check against Lab 11's outside server (certificate CN lab-av):

   config firewall ssl-ssh-profile
       edit "<your deep profile>"
           config https
               set sni-server-cert-check strict
           end
       next
   end

   From the client: openssl s_client -connect 203.0.113.50:443 -servername wrong.example </dev/null. Repeat with enable.

   Predict: the result under strict and under enable.

   What you should see

   strict: the FortiGate closes the connection, because the SNI matches neither the CN nor any SAN (Q27). enable: the mismatch is tolerated, and the FortiGate uses the certificate's CN for URL filtering instead.

Lab 15 — Captive portal and group matching

LessonL05·QuestionsQ6Q35Q58Q75·Time40 min·Needsthe Lab 7 DC for steps 2–3

1. Create local user lab1 in group lab-users. Disable lan-out and add auth-out: internal → wan1, source = the LAN plus lab-users, services HTTP and HTTPS only. Point the client's DNS at an outside resolver — if it uses the FortiGate as its resolver, DNS never crosses a firewall policy and the test proves nothing. Browse to http://neverssl.com.

   Predict: do you get a login prompt?

   What you should see

   No. The name never resolves, so no HTTP request ever reaches the FortiGate to be redirected. Add a DNS-only policy (no user group) above auth-out and the prompt appears (Q6, Q75).

2. Optional — RADIUS (NPS on the DC, or FreeRADIUS). Add the server with Include in every user group (set all-usergroup enable), then log in as a RADIUS account that isn't in lab-users.

   Predict: allowed?

   What you should see

   Allowed. The server — and everyone who can authenticate against it — is now a member of every group, lab-users included (Q35).

3. Add the DC as an LDAP server. In lab-users, add a remote group: that server, restricted to one specific AD group. Log in as a user outside that group, then as one inside it.

   Predict: which logins succeed?

   What you should see

   Only members of the matched group get through (Q58).

Lab 16 — A fifteen-minute settings read

LessonL01·QuestionsQ4Q32Q33Q77·Time15 min

1. Run get router info routing-table connected. Give an unused interface (dmz works) an address, then run it again. Then set a role and enable a DHCP server on that interface.

   Predict: which of those changes touch the routing table?

   What you should see

   Only the IP address. It creates the connected route the moment it's set; the role and DHCP are conveniences (Q4).

2. Set config system global → set admintimeout 5. Clone prof_admin as noc, then config system accprofile → edit "noc" → set admintimeout-override enable → set admintimeout 480. Assign noc to a lab admin and leave both sessions idle for six minutes.

   Predict: whose session drops?

   What you should see

   Yours. The noc admin stays logged in: the override lives in the admin profile, not in the global setting or the account's role (Q32).

3. Run diagnose debug rating and read the FortiGuard server list (weight, RTT, flags, losses). Then show full-configuration system fortiguard | grep protocol.

   Predict: what happens to a server's weight as it loses packets? Which transports are on offer?

   What you should see

   Weight rises as failures accumulate, and higher weight means less preferred. UDP is an available transport alongside HTTPS (Q33).

4. Run show full-configuration system dns.

   Predict: the protocol used to reach the FortiGuard DNS servers.

   What you should see

   set protocol dot with server-hostname "globalsdns.fortinet.net" — DNS over TLS, not plain UDP 53 (Q77).