NSE4 Part 5: Logging, Monitoring & Diagnostics

NSE4 Part 5: Logging, Monitoring & Diagnostics

Part 5 of the NSE4 series. This post covers Lesson 6 plus the diagnostic toolkit you’ll lean on across every other topic in the syllabus.

Log categories

A FortiGate produces three categories of log:

Category	What it captures
Traffic	Per-session start/end, bytes, policy ID, NAT mappings
Event	System changes, admin logins, HA failover, VPN tunnel up/down
Security	Detections from AV, IPS, web filter, app control, DLP

Each log entry has a severity from emergency (0) down to debug (7). The severity threshold is configurable per destination — set it too noisy and you flood your logger; too quiet and you miss real events.

Where logs go

Three storage tiers exist, often used together:

1. Memory — small ring buffer in RAM. Survives until reboot. Always available, no licence required.
2. Disk — internal flash or SSD on models that have it. Persistent. Watch the wear on entry-level units that use eMMC.
3. Remote — FortiAnalyzer, FortiGate Cloud, or syslog. Where production logs actually live.

Configure each:

config log memory setting
    set status enable
end

config log disk setting
    set status enable
    set maximum-log-age 30
end

config log fortianalyzer setting
    set status enable
    set server 10.10.1.30
    set serial "FAZ-VM..."
    set upload-option realtime
end

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

Severity per destination is set with set severity inside each block. The exam likes asking which severities are forwarded to which destination given a config snippet.

What gets logged for each policy

Per-policy logging has three settings:

• set logtraffic disable — no traffic log for this policy.
• set logtraffic utm — log only sessions that triggered a security profile (default).
• set logtraffic all — every session.

Logging the implicit deny rule was covered in Part 3 — same mechanism.

Threat weight

FortiOS assigns a numeric weight to each detection (low=5, medium=10, high=30, critical=50 by default). Per-source weights accumulate over a configurable window, surfacing “the user generating the most risk” rather than “the user with the most detections”. Configure under System → Settings → Threat Weight or:

config system replacemsg-image
config log threat-weight
    set status enable
    set blocked-connection medium
    set web high
end

Top threats appear on the FortiView → Threats dashboard.

FortiView and the dashboard

FortiView is the GUI’s drill-down explorer over recent log data. Sources include local memory, disk, FortiAnalyzer, or FortiGate Cloud. Key views: Sources, Destinations, Applications, Cloud Apps, Web Sites, Threats, VPN, System Events. Each can be filtered by time and exported.

A common exam question is “I see traffic in real-time monitor but not in FortiView” — the answer is usually that the policy is set to logtraffic utm and the session never triggered a UTM profile.

Diagnostics — the must-know commands

These commands appear in exam scenarios and on every troubleshooting ticket:

diagnose debug flow filter saddr 10.10.1.50
diagnose debug flow filter daddr 8.8.8.8
diagnose debug flow trace start 50
diagnose debug enable

This walks a packet through every decision point. Stop with diagnose debug flow trace stop and diagnose debug disable.

diagnose sniffer packet any 'host 10.10.1.50' 4 0 a

Built-in tcpdump. The fourth argument controls verbosity (1 = headers, 4 = headers + interfaces, 6 = with hex). The fifth is packet count (0 = unlimited). The sixth (a) prepends absolute timestamps.

diagnose sys session list
diagnose sys session filter src 10.10.1.50
diagnose sys session clear

Live session table — invaluable for confirming NAT, policy ID, and which TCP state a connection is in.

get system performance status
diagnose sys top 5
diagnose hardware sysinfo memory

Quick health check: CPU load, top processes, free memory.

execute ping-options source 10.10.1.1
execute ping 8.8.8.8
execute traceroute 8.8.8.8

Test connectivity from the FortiGate itself, sourced from a specific interface IP — useful when policies look correct but FortiGuard or NTP isn’t reaching the internet.

Reading flow trace output

Most exam-style flow output looks like this:

id=20085 trace_id=1 func=print_pkt_detail line=5867
msg="vd-root:0 received a packet... from port2."
id=20085 trace_id=1 func=resolve_ip_tuple_fast line=5982
msg="allocate a new session-..."
id=20085 trace_id=1 func=fw_forward_handler line=898
msg="Allowed by Policy-10:"

Three lines you’ll see most often:

• Allowed by Policy-N — matched a policy. The number is the policy ID.
• Denied by forward policy check — implicit deny.
• reverse path check fail — RPF rejected the source IP because the route table says it should arrive on a different interface. Set set strict-src-check disable per VDOM if you legitimately have asymmetric routing.

Part 6 covers the security profiles — web filter, application control, antivirus, IPS and DoS — together because they’re nearly always discussed together in the exam.