Build a safe learning workspace

Foundations: guided analysis. Animations are authored examples, not captured appliance results. Practical exercises are conditional drafts: run them only after exact-build licensing, isolation, private management, protected backup and baseline acceptance checks pass. No FortiGate/GNS3 appliance runtime has been validated for this course.

This is a fresh three-node GNS3 project inside the existing VMware-hosted GNS3 VM. Setup is an instructor-assisted prerequisite, separate from the numbered lessons. Lessons 1–3 can be studied in guided-analysis mode while runtime is gated. They teach decisions, then addressing, then services; detailed policy administration remains later in the 36-lesson course.

Stop before changing an appliance

1. Record exact version/build, valid/invalid license status and supported CPU/RAM/interfaces. Do not share the full status output. Check available host/GNS3 memory and KVM support; historical 16 GB host / 2 GB GNS3 values are unverified. Do not change allocations or host security.
2. Use an entitled appliance workflow without cloning licensed disks, moving assignments, upgrading firmware or activating another instance. If a new instance needs activation or resources, stop for a separate authorized preflight. Preserve old projects.
3. Create a blank project named QCS-FortiGate-Foundations; use the existing approved template only when license use is settled. Add disposable Ubuntu client/server with iproute2, curl and Python 3 already installed through an authorized provisioning process. No package download is needed in the isolated exercise.
4. Connect client data NIC to verified FortiGate client port, and server NIC to verified server port. Leave management disconnected initially. No Cloud, NAT, bridge, shared DHCP or links to other projects. Outer VM NAT is not proof of guest isolation.
5. Verify NIC/MAC/cable mappings using console interface listings and GNS3 adapter records. Port2/port3 in this pack are provisional. If ranges overlap, revise manifest, commands and all visuals together before use.

Console versus GUI

Right-click the intended GNS3 node → Console opens its text terminal. FortiGate’s top-level prompt resembles hostname #; Ubuntu resembles user@LabClient:~$. These prompts identify where to type and are never copied. A GUI is a browser dashboard and needs a separately verified private management route. A Linux sudo prompt asks for the local password privately; typed characters may be invisible.

At the FortiGate top-level prompt, get system status reads system metadata; privately retain only version/build and license-validity summary. show system interface reads configured interface names and addresses. These may reveal identifiers: inspect locally, never upload full output. If the prompt contains a configuration section, stop and return to top level with end before a read command.

Private management and baseline gate

Management subnet/address remain deliberately unassigned. Verify a dedicated host-only path, overlap checks, adapter binding and absence of physical uplinks before connecting port1. Use console access until that path is approved. Limit HTTPS administration to that private interface and the administrator host; do not enable it on the data ports. Verify certificate identity privately; do not blindly bypass certificate warnings.

Before any exercise change, obtain a protected baseline from the actual build. The 8.0 reference GUI path is username menu → Configuration → Backup → Local PC → FortiOS format → Encryption enabled. Keep the recovery password privately, verify the file exists and record its hash outside this served folder. A password-masked sharing copy is not a recovery backup. If GUI/private management is unavailable, hold configuration work until a supported protected backup method is verified. Do not substitute insecure TFTP.

Prepared baseline contract — instructor gate

After exact-build review, configure the manifest’s addresses and only the two endpoint-specific remote routes. No default Internet route. Ordinary routed, single-VDOM lab; connected FortiGate routes to both /24s; NAT off. Map objects QCS_CLIENT = 10.77.10.10/32, QCS_SERVER = 10.77.20.10/32, custom service QCS_TCP8080 = TCP destination 8080. An unused verified policy ID (proposed 1101) permits only port2 → port3, these two objects, this service, always schedule, logging enabled. No other data forwarding rule. Verify policy order, storage/log-view capability and host firewall allowance narrowly for this client/port. Do not disable endpoint security. Actual IDs/names must be checked for collisions.

This is a baseline specification, not a paste-ready FortiGate setup script. Final appliance configuration and its inverse must be generated after the build and original configuration are known. Lessons use read-only observations or disposable-endpoint changes. Do not claim an executable FortiGate configuration has been validated.

Transfer and service preparation

Transfer the included fixed-response helper to the disposable server using an approved private file-transfer channel, before final isolation. Record its SHA-256 against checksums.json. Do not add a public connection just to transfer it. Use the server console to run it; client console remains separate. It binds only the server lab address, returns fixed text and serves no disk files.

Acceptance and rollback

• Record address, route, cable and private-management evidence; verify no public/default route or physical bridge.
• Obtain encrypted baseline, record host firewall and policy state, then prove a fresh client HTTP request reaches the local helper, with matching policy/session or log evidence.
• Keep evidence and backups outside this preview folder. The learner worksheet contains only safe summaries.
• For cleanup stop only the helper with Ctrl+C; restore the endpoint route fault exactly as lesson 2 describes. Instructor deletes only newly created QCS policy and objects in dependency order, restores original data-interface values and narrow endpoint firewall changes from the recorded change ledger. Never touch management as casual cleanup.
• If exact original values or ownership are unknown, stop; do not guess cleanup. Full backup restore is a separate disruptive recovery step: matching appliance/build, private console, username → Configuration → Restore, protected file/password, confirm reboot, then verify management and baseline. No factory reset or global session clearing.

{
  "status": "PROPOSED \u2014 actual build and interface mapping unverified",
  "project": "QCS-FortiGate-Foundations",
  "client": {
    "ip": "10.77.10.10/24",
    "interface": "C_IF (verify)",
    "route": "10.77.20.0/24 via 10.77.10.1"
  },
  "firewall": {
    "client": "port2 (verify): 10.77.10.1/24",
    "server": "port3 (verify): 10.77.20.1/24",
    "management": "port1 (verify), disconnected until private path verified"
  },
  "server": {
    "ip": "10.77.20.10/24",
    "interface": "S_IF (verify)",
    "route": "10.77.10.0/24 via 10.77.20.1"
  },
  "service": "TCP 8080 fixed-response HTTP; no TLS, DNS server or NAT",
  "management": "address/subnet TBD after overlap and private-host-only mapping checks"
}