FortiGate 7.6 in Production

A ticket arrives: “the website is down”, “the office can’t reach the lab”, “the ISP says we are announcing private networks”. There are good books on how to configure a FortiGate. This one is about the moment after that, when something that worked yesterday is broken today.

Every incident in chapters 4 to 8 was built as a script: set up a working configuration, prove it works, break it the way production breaks it, investigate, fix, and prove the fix. The scripts ran on a real FortiGate-VM, and the book was built from what they recorded. Some fixes in the book deliberately don’t work. Section 6.4 tries a documented fix that FortiOS accepts without a single error, and that fixes nothing. Knowing which fixes fail, and how to tell from the evidence, is half of troubleshooting.

Who it’s for

• Network and security engineers who run FortiGates and want a faster way from ticket to cause.
• Administrators who know the configuration side and want to get fluent with debug flow, the sniffer and the routing commands.
• Students working towards Fortinet certifications who want hands-on practice beyond the happy path.

You should know basic IP networking and have seen a FortiGate CLI. You don’t need to be an expert in either.

What’s inside

Method and tools

• The incident method: six steps from ticket to proven fix, and the path of a packet through FortiGate
• Building the automated lab on a Windows PC with VMware Workstation and Fortinet’s free permanent trial license
• The troubleshooting toolkit: debug flow, the sniffer, configuration checks and routing protocol commands

When the rule doesn’t match

• The allow rule is there, but something above it wins
• “Encrypted only”, but the site still speaks HTTP
• Nobody changed anything: the rule simply expired

Source NAT

• Internet down after the firewall swap
• A new public IP for outbound traffic, and nobody answers for it

Port forwarding (VIPs)

• The website died after the change window
• The rules were “simplified” and the port forward vanished
• Right server, wrong port: refused in an instant
• Works from the Internet, not from the office

Routing

• Half of the lab network is unreachable
• The new lab subnet can’t reach the office
• A policy route for Internet traffic swallows the lab network

OSPF and BGP

• OSPF neighbour gone after the timers were “standardised”
• OSPF stuck in ExStart after the ISP’s maintenance
• BGP to the ISP never comes up after the firewall replacement
• The ISP calls: you are announcing private networks

Appendices: a symptom index (by user test, routing protocol and debug-flow line) and a lab reference.

IPsec, SSL inspection, security profiles, SD-WAN and high availability need a licensed FortiGate and are the subject of Volume 2.

From the book

The method starts before any FortiGate command: reproduce the failure from where the user is, and look closely at how it fails. Here are three broken port forwards from chapter 6, all tested with the same command:

lab@inet1:~$ curl -sS -m 5 http://203.0.113.10:8080/
curl: (28) Connection timed out after 5002 milliseconds

lab@inet1:~$ curl -sS -m 5 http://203.0.113.10:8080/
curl: (7) Failed to connect to 203.0.113.10 port 8080 after 3135 ms: Couldn't connect to server

lab@inet1:~$ curl -sS -m 5 http://203.0.113.10:8080/
curl: (7) Failed to connect to 203.0.113.10 port 8080 after 0 ms: Couldn't connect to server

Three different failures, three different places to look, and not a single FortiGate command typed yet.

Tested on

All command output was recorded on FortiGate-VM64 v7.6.7, build 3704, running the permanent trial license. The lab scripts are free at github.com/vashy-labs/fortigate-lab, and one command replays any incident in the book.