Course menu

Module 7: Operations and PracticeLesson 7.3 (3 of 4 in this module)32 of 33 in the FortiGate Administrator course

Troubleshooting tickets

Eight realistic support tickets across the whole course, each with the evidence an administrator would collect and the fix.

Advanced · 25 min read

What you will learn

After this lesson, you can work through FortiGate problems from symptom to fix, choosing the command that gives the deciding evidence for each layer: interfaces, routing, policies, NAT, VPN, profiles and HA.

  • Method
  • debug flow
  • IKE debug
  • Logs and sessions

A troubleshooting method is a fixed order of questions that narrows a problem down quickly: does the traffic arrive, is there a route, which policy matches, is it translated, is it inspected, does the reply come back. On a FortiGate each question has a command that answers it: the sniffer, the routing table, debug flow, the session list, the logs, and protocol-specific debugs such as IKE.

In simple terms: Follow the packet. At each step, find the one piece of evidence that shows whether it got through.

Each ticket is written the way a user reports it. Decide what you would check first, look at the evidence, then open the answer. All tickets use the course lab: FGT1 with LAN 10.0.1.0/24 on port2, DMZ 10.0.2.0/24 on port3, two ISPs in SD-WAN, and the branch FGT2.

1. Does it arrive?
diagnose sniffer packet on the incoming interface.
2. What does FGT1 decide?
diagnose debug flow: route, policy, NAT.
3. What was logged?
Forward traffic, security and event logs, with the policy ID.
4. Protocol-specific checks
IKE debug, SD-WAN health checks, HA status, FortiGuard rating.
The order used in every ticket.

Ticket 1: "I can't open the firewall's web page any more"

An administrator changed port2's settings this morning. From the LAN, https://10.0.1.1 times out, but ping works.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # show system interface port2 (from the console)
config system interface
    edit "port2"
        set ip 10.0.1.1 255.255.255.0
        set allowaccess ping
        set role lan
    next
end
Show the answer

HTTPS (and SSH) were removed from allowaccess, so FGT1 only answers ping on port2. Ping working was the clue. Fix, from the console: config system interface, edit port2, set allowaccess ping https ssh. (append allowaccess https ssh also works.)

Ticket 2: "New laptops in the guest area get no network"

Guests who arrived earlier work. New guests' laptops show a 169.254.x.x address.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # execute dhcp lease-list guest
guest
  IP              MAC-Address        Hostname        VCI        Expiry
  10.0.20.100     02:00:00:aa:01:01  ...                        ...
  ...
  10.0.20.199     02:00:00:aa:01:64  ...                        ...
Show the answer

All 100 addresses of the range 10.0.20.100–199 are leased (to many short visits with long leases). New clients get no offer and fall back to a link-local address. Fix: widen the range and shorten the lease time (for example set lease-time 7200, two hours) on the guest DHCP server.

Ticket 3: "Our new supplier portal is blocked"

Staff see the FortiGate block page for portal.supplier.example, which went live last week.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # (Log & Report › Security Events › Web Filter, trimmed)
date=2026-10-11 time=09:41:02 type="utm" subtype="webfilter" eventtype="ftgd_blk"
srcip=10.0.1.23 hostname="portal.supplier.example" policyid=3
catdesc="Newly Registered Domain" action="blocked"
Show the answer

The domain is so new that FortiGuard rates it Newly Registered Domain, a category Staff-WF blocks. The rule is working; the site is a known exception. Fix: add a static URL filter entry (allow or exempt) for portal.supplier.example, or a local rating override to a business category, and submit it to FortiGuard for re-rating.

Ticket 4: "The website stopped working after the network upgrade"

Since the SD-WAN migration last night, Internet visitors can't reach www.example.com (VIP to WEB1). Staff still can.

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, 198.51.100.77:61022->203.0.113.20:443) from port1. flag [S], ..."
msg="find DNAT: IP-10.0.2.10, port-443"
msg="find a route: flag=00000000 gw-10.0.2.10 via port3"
msg="Denied by forward policy check (policy 4)"
Show the answer

DNAT and routing are fine, but no accept policy matched. To free port1 for SD-WAN, policy 6 was disabled during the migration and never updated: show firewall policy 6 shows set status disable. Fix: set its srcintf to the SD-WAN zone virtual-wan-link and set status enable. Staff were unaffected because their hairpin policy uses port2.

Ticket 5: "The branch can't reach the file server since this morning"

The branch changed ISP overnight. The tunnel is down on both sides.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # (IKE debug on FGT1, trimmed)
ike 0:to-BR1:21: sent IKE msg (SA_INIT): 203.0.113.2:500->198.51.100.2:500 ...
ike 0:to-BR1:21: sent IKE msg (RETRANSMIT_SA_INIT): 203.0.113.2:500->198.51.100.2:500 ...
ike 0:to-BR1:21: sent IKE msg (RETRANSMIT_SA_INIT): 203.0.113.2:500->198.51.100.2:500 ...
ike 0:to-BR1:21: negotiation timeout, deleting
Show the answer

FGT1 keeps sending to 198.51.100.2 and never gets an answer: that is the branch's old address. FGT2's own attempts to 203.0.113.2 arrive from an address FGT1's phase 1 doesn't expect. Fix: update remote-gw on FGT1 to the branch's new address. If the branch address can change again, use a dynamic DNS name (set type ddns with remote-gw-ddns) instead of a fixed IP.

Ticket 6: "Video calls are terrible every afternoon"

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys sdwan health-check
Health Check(Internet-SLA):
Seq(1 port1): state(alive), packet-loss(3.100%) latency(212.880), jitter(41.502), sla_map=0x0
Seq(2 port4): state(alive), packet-loss(0.000%) latency(22.310), jitter(1.884), sla_map=0x1

The SD-WAN rule for video calls shows strategy manual with member port1.

Show the answer

port1 misses the SLA badly every afternoon, but a manual rule doesn't care about SLAs: calls stay on port1 while port4 is healthy. Fix: change the rule to Lowest Cost (SLA) (set mode sla) with the Internet-SLA target and members port1, port4.

Ticket 7: "Everything is unstable after the switch replacement"

Both cluster units now show themselves as primary; users see duplicate-IP warnings and drops.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # get system ha status (on each unit, trimmed)
FGT1-A:  Primary : FGT1-A , FGVM0000000A, HA cluster index = 0
         (no secondary listed)
FGT1-B:  Primary : FGT1-B , FGVM0000000B, HA cluster index = 0
         (no secondary listed)
Show the answer

Split brain: the units can't see each other's heartbeats. Both heartbeat ports were patched through the replaced switch, into a VLAN that doesn't exist on it. Fix: restore heartbeat connectivity, preferably with two direct cables between the units, then check get system ha status lists one primary and one secondary, in sync.

Ticket 8: "WEB1 can't download its updates"

The web server admins report that package updates on WEB1 (10.0.2.10) time out. Staff browsing works.

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.2.10:44120->192.0.2.80:443) from port3. flag [S], ..."
msg="find a route: flag=00000000 gw-203.0.113.1 via port1"
msg="Denied by forward policy check (policy 4)"
Show the answer

There is no policy from the DMZ to the Internet; the VIP policy only covers inbound connections, and the deny-all policy catches WEB1's outbound sessions. Fix: add a policy port3 → the SD-WAN zone, source WEB1, destination an FQDN or Internet Service object for the update servers, service HTTPS, with NAT, rather than opening the whole Internet to the server.

Check yourself

Predict · scenario 1

The admin page times out but ping to the same interface works. What do you check first?

Predict · scenario 2

IKE debug shows SA_INIT retransmitted until "negotiation timeout". What does it mean?

Predict · scenario 3

After an SD-WAN migration, inbound VIP traffic is denied. Why might the VIP policy no longer match?