FortiOS, 2002

What you will do

1. view firmware version, hostname and operation mode get system status

   Fortinet was founded in 2000 by Ken Xie and Michael Xie; the first FortiGate appliance shipped in 2002, bundling firewall, VPN and antivirus into one purpose-built box — the category the industry came to call Unified Threat Management (UTM).

2. view the current interface configuration (both ports blank on a fresh unit) show system interface

   A FortiGate ships as a purpose-built appliance: port1/port2 are fixed hardware, not user-created — the opposite of a general-purpose Linux box with swappable NICs.

3. enter the interface configuration table config system interface

   Entering `config <table>` drops you into an editable list. FortiOS config is built almost entirely from these tables (interfaces, addresses, policies), each with the same edit/set/next/end rhythm.

4. select port1 — the interface you will designate as the LAN side edit port1

   `edit` on an existing name selects it for editing; for object tables it silently creates the entry if it does not exist yet. Re-running `edit` on the same name never duplicates it — that idempotency is deliberate FortiOS behavior.

5. assign port1 an address and mask on the internal LAN subnet set ip 192.168.1.99 255.255.255.0

   Every interface needs both an address and a mask — FortiOS never infers one from the other the way some older tools guessed from address class.

6. allow ping, HTTPS admin GUI and SSH management on the LAN interface set allowaccess ping https ssh

   `allowaccess` is the single knob controlling which admin protocols may even reach an interface. An interface with nothing in that list answers no management traffic at all, from any protocol.

7. save port1 and stay in the interface table, ready to edit another entry next

   `next` commits the object you were editing and drops back to the table level — it does not leave config mode, unlike `end`.

8. select port2 — the interface you will designate as the WAN side edit port2

   Port numbering says nothing about role by itself — port2 only becomes "the WAN port" because that is the interface an eventual default route points out through.

9. assign port2 its public-facing address set ip 203.0.113.5 255.255.255.0

   203.0.113.0/24 is one of three ranges IANA reserved (RFC 5737) specifically for documentation and examples — it never routes on the real internet, which makes it the standard choice for labs like this one.

10. harden the WAN interface — allow only ping, nothing administrative set allowaccess ping

    This is the habit that matters most in this whole track: an internet-facing interface should answer as little as possible. Ping-only means the box is reachable enough to diagnose, but never administrable, from the WAN side.

11. save and leave the interface table entirely, back to the top-level prompt end

    `end` commits and closes the whole config block in one step — the FortiOS equivalent of walking all the way back out, no matter how deep `edit` had taken you.

12. enter the firewall address-object table config firewall address

    Firewall policies never reference a bare IP directly — everything routes through a named address object, so one object can be reused, renamed, or audited independently of every policy that points at it.

13. create an address object named LAN edit LAN

    Object names are free text — "LAN" means nothing to FortiOS itself. It exists purely so the next engineer can read a policy and understand what it does at a glance.

14. define the subnet this address object represents set subnet 192.168.1.0 255.255.255.0

    A subnet-type address object is defined the same way as an interface: network address plus mask — not a range or a single host, which are different object types entirely.

15. save the LAN address object next

    Same rule as before: `next` saves and stays in the table, ready for another `edit` — this is how you would build a second address object (say, a DMZ subnet) right after this one.

16. leave the address table, back to the top-level prompt end

    One address object built. The next table, firewall policy, is where that object actually starts doing something.

17. enter the firewall policy table — the heart of the device config firewall policy

    The policy table is the core of the whole appliance — FortiOS evaluates policies top to bottom and stops at the first match, exactly like an access list.

18. create policy 1 edit 1

    Policy IDs are just table keys, assigned in creation order by default — the actual matching ORDER is governed separately by each policy's position in the list, not by its ID number.

19. this policy matches traffic arriving on port1 (LAN) set srcintf port1

    srcintf/dstintf bind a policy to a direction of travel between two interfaces — this one policy only ever matches traffic entering on port1.

20. this policy matches traffic leaving via port2 (WAN) set dstintf port2

    Pairing srcintf and dstintf is what makes a policy directional. FortiOS handles the stateful reply path automatically — you do not need a mirrored WAN-to-LAN policy just for return traffic.

21. the policy source is the LAN address object you built earlier set srcaddr LAN

    srcaddr always points at an address OBJECT, never a bare subnet typed inline — this is exactly why address objects exist: one object, referenced by any number of policies.

22. the policy destination is anywhere on the internet set dstaddr all

    "all" is a built-in address object meaning 0.0.0.0/0 — every FortiGate ships with it pre-defined, the same idea as Cisco's "any".

23. explicitly allow traffic that matches this policy set action accept

    Every policy defaults to implicit deny until you explicitly set action accept — miss this one line and traffic matching everything else still silently drops.

24. this policy is active 24/7 set schedule always

    Every policy needs a schedule object too — "always" is FortiOS's built-in 24/7 schedule; time-boxed access (say, office-hours only) just swaps in a different one.

25. allow all services/ports for this lab policy set service ALL

    service scopes a policy to specific ports/protocols (HTTPS, DNS, ...) — ALL is the broadest built-in service object: fine for a lab, far too broad for a real production policy.

26. enable source NAT so LAN clients can actually reach the internet set nat enable

    Without NAT, LAN clients with private RFC 1918 addresses would try to talk to the internet using addresses no internet router can route back to. NAT is what actually gets the office online — the allow action alone is not enough.

27. save policy 1 next

    Same rhythm as every table in this sim: `next` saves and stays, ready for the next `edit` if you had another policy to add.

28. leave the policy table, back to the top-level prompt end

    Interfaces configured, an address object built, a policy with NAT in place. The next missions verify it all, then the boss arc puts it to the test.

29. review the policy list — including the invisible implicit-deny at the very end show firewall policy

    Reading a policy list top to bottom, remembering the invisible implicit-deny that always sits after the last rule, is one of the most-used skills in real firewall administration.

30. view the routing table get router info routing-table all

    "C" is a directly-connected route, learned automatically the moment an interface gets an IP and comes up — no routing configuration required, just physics and cabling.

31. dump the entire running configuration in one shot show full-configuration

    A `show full-configuration` dump is FortiOS's answer to "what does this box actually do" — every object and policy, in the exact syntax you would type to rebuild it from scratch.

32. test the FortiGate's own reachability to the internet execute ping 8.8.8.8

    `execute` commands run an action rather than change configuration — this ping tests the box's OWN reachability, not a policy's behavior.

33. capture live traffic on the device without touching its forwarding path diagnose sniffer packet any icmp 4

    FortiOS's built-in sniffer, a thin wrapper over the same libpcap engine tcpdump uses, lets you watch traffic hit an interface without disrupting the box's actual forwarding decisions.

34. BOSS ARC — load the small-office scenario: a fresh appliance that needs hardening from scratch scenario start

    Good hardening work is repeatable: every real deployment starts from a mostly-open default and gets locked down deliberately, one object at a time — never assume yesterday's configuration is still there.

35. Boss missionFINAL CHECK — rebuild the LAN address object, the LAN->WAN allow policy with NAT, and the WAN management lockdown, then verify all three are correct execute policy-check

    Interfaces, an address object, a policy with NAT, and a hardened management plane — those four pieces, in that order, are the entire job of standing up a small-office firewall. This is the exam: doing beats recall.

Certificate

Nearby eras

All 25 eras in the Terminal Academy