Building a FortiGate 7.6 Lab on VMware Workstation I needed a FortiGate lab for NSE 4 study. Two firewalls, a private link between them, a client machine behind each, GUI access from my laptop, no hardware. VMware Workstation does this well. But the path has more dead ends than the tutorials suggest, and three of them cost me most of an evening: a licensing limit that invalidates your topology design, a NIC enumeration quirk that silently swaps your interfaces, and a host-side failure that makes every firewall unreachable at once while looking exactly like a firewall problem. This is the build that worked, in the order I'd do it again, with the diagnostics that actually isolate each failure. Final topology: --- Part 1: Designing the segments Host-only VMnets, not NAT The instinct is to put both firewalls on NAT so they can reach each other. Don't. NAT is a shared segment where VMware's own gateway does the routing — you can't control what sits between the firewalls, and you can't put a subnet behind one of them. Use host-only VMnets. Each is an isolated L2 segment, which is exactly what a cable is. Segment Role ------ VMnet1 Management — port1 on every firewall, reachable from the host VMnet2 Link between FGT-A and FGT-B VMnet3 LAN behind FGT-A VMnet4 LAN behind FGT-B Don't use 192.168.1.0/24 for management. That's the default range on most home routers. You will bridge an interface to your real network during licensing, and the moment you do, you have two interfaces in one subnet and routing breaks in ways that look like firewall faults. 172.16.x.x keeps you clear. Attach a host adapter to VMnet1 only Virtual Network Editor (as admin) → Add Network → Host-only → set the Subnet IP → untick "Use local DHCP service." For VMnet1, tick "Connect a host virtual adapter to this network" — that's how your laptop reaches the firewall GUIs. For VMnet2, 3 and 4, leave it unticked. They're firewall-to-firewall and firewall-to-PC segments; Windows has no business on them. Host adapters on those segments end up with no IP, sit on APIPA 169.254.x.x addresses, and clutter your routing table for no benefit. The catch: a VMnet without a host adapter doesn't appear in the VM's network adapter dropdown, even after restarting Workstation. That pushed me into attaching host adapters to everything, which later contributed to a much worse problem. The right answer is to edit the .vmx directly and skip the GUI: ethernet0 is "Network Adapter 1" — the numbering is zero-based. Any key that isn't present simply gets created by typing it. VMware reads the file on load, so this always works, and it avoids a trap covered in Part 5. Subnet labels are cosmetic The Subnet IP field in Virtual Network Editor only controls what address VMware gives its own host adapter and DHCP scope on that segment. With no host adapter and no DHCP, nothing uses it. The VMnet is a dumb L2 switch. So a VMnet labelled 10.0.23.0 will happily carry a 192.168.20.0/24 network. The attached devices define the subnet. Don't renumber the labels to match — see Part 5 for why you want to stay out of that dialog. --- Part 2: Getting the right image Fortinet's download portal offers more ways to get this wrong than right. Three distinctions matter: Distinction Take Not --------- Product FGT (FortiGate) FFW (FortiFirewall — no UTM) Architecture VM64 (x86-64) ARM64 Package "New deployment" .ovf.zip "Upgrade from previous version" .out Set the platform selector to VMware ESXi, not KVM. The KVM package unzips to a single fortios.qcow2 with no OVF descriptor — useless in Workstation without converting it, and that build assumes virtio NICs rather than vmxnet3. On version: take 7.6.x, not 8.0. The NSE 4 exam targets FortiOS 7.6. Don't bother with 6.4 I initially deployed three FortiGate 6.4.5 VMs, reasoning that an older release would be more permissive when unlicensed. It isn't — it's worse. An unlicensed 6.4 VM doesn't just lock the GUI. It strips commands from the CLI entirely: That isn't a syntax error. config firewall policy genuinely does not exist on an expired 6.4 VM. You can configure interfaces and static routes, and nothing else. It is not a lab. --- Part 3: Deploying the VMs File → Open → FortiGate-VM64.ovf — the plain one, not .hw13, .hw14, .nsxt or .vapp. Deploy each firewall from the OVF separately. Don't clone a licensed VM — the clone carries the original's serial number and activation fails. Before first boot, per VM: Remove network adapters 3–10. The OVF creates ten, all defaulting to Bridged, which puts them on your real home network. Set the remaining adapters via the .vmx as above. Change hardware compatibility to the latest. The OVF defaults to "Workstation 6.5-7.x," which costs you proper vmxnet3 support. Don't store VMs in OneDrive. It will try to sync multi-gigabyte disk files while they're running. First boot and addressing Console login is admin with a blank password; it forces a change immediately. Two things that waste time here: browser autofill…