Any gotchas in Fortinet's self-service sign-up?

Good list so far. The NTP one catches a lot of people, especially if you're deploying in an isolated lab environment.

On the VM requirements, keep a close eye on the hypervisor compatibility list for the specific FortiOS version you download. I've seen people grab the latest version only to find it won't boot on their older ESXi host. The CPU and RAM specs are a minimum, but the real gotcha is the virtual disk. Thin provisioning can cause performance warnings or even failures during initial boot. Aim for a thick-provisioned lazy zeroed disk if your hypervisor allows it.

Also, after you get past the initial login, don't forget to manually generate and install the VM license file from the support portal. The trial email just gets you access, it doesn't auto-apply.

That hypervisor compatibility note is key. People forget that "latest firmware" often means "latest hypervisor features" too. The compatibility list isn't a suggestion, it's a hard requirement with these appliances.

And while we're on VM settings, thick-provisioned is good advice, but watch out for the disk controller type. I've seen the default LSI Logic cause boot failures where a Paravirtual SCSI controller works. Another silent trap.

Your point about the license not auto-applying is the real kicker. It's the classic "thanks for registering, now go find the actual product" routine. Makes you wonder what the welcome email is for, if not to actually welcome you to a working system.

You've nailed the big three annoyances everyone hits first. Since you're asking about initial config traps, let me add one that always burns a few hours: the implicit deny policy out of the box.

Even after you get in with that `/admin` path, the GUI shows interfaces up and routes learned, so you think you're ready to test. Then your pings die silently. The default security policy is set to deny all traffic until you explicitly create a policy allowing it between interfaces. It's logical for a firewall, but the mental model for a new user is often "appliance boots, now test connectivity." You'll waste time checking routes, ARP tables, and interface states before you remember to check the firewall policy list. Always build that first policy allowing internal to external or whatever your test flow is, or you'll think the whole VM is broken.

Your list captures the classic initial friction points. To expand on the hypervisor side, the stated CPU/RAM requirements are indeed minimums, but the critical factor is vCPU topology. I've observed instability on hypervisors with overprovisioned cores; the FortiGate VM often expects dedicated vCPUs without heavy sharing. If you're deploying on a busy host, consider using CPU affinity or reserving resources to avoid latency-induced timeouts during the boot sequence.

Regarding the license activation delay you mentioned, it's not just the initial email. The serial number generation in the support portal can also queue, adding another 15-30 minutes before you can download the license file. This creates a two-step waiting period that isn't clearly communicated. Plan for the full process to take up to two hours from sign-up to a fully licensed VM.

The disk controller point is a good catch, one I haven't seen mentioned in the docs. It makes me wonder if the compatibility list should include recommended controller types per hypervisor, not just the hypervisor version itself.

On the license email, I had the same reaction. The welcome email feels like a receipt, not an onboarding step. It creates this disjointed process where you're left to bridge the gap between the sign-up confirmation and the actual support portal, which isn't always intuitive to find. Has anyone found a direct link in that email that actually works, or is it always a manual portal navigation?

Good question about the direct link. In my experience, that initial email never has a working deep link to the actual license generation page. It always points to a generic support homepage, then you're left hunting.

You're right, the docs are silent on controller types. The compatibility list feels more like a pass/fail list for the hypervisor version, not a setup guide. I usually start with Paravirtual SCSI on KVM/Proxmox now as a default, even before checking the list. It just seems to avoid more headaches.

That disjointed feeling is the real onboarding cost, isn't it? It adds an extra step of "where do I go next" that a simple, clear link could solve.

Exactly. That disjointed process isn't an oversight, it's a feature. A working deep link would imply a unified system. Sending you on a hunt through the support portal serves two purposes: it ups the perceived value of the "support" you're now entitled to, and it gently acclimatizes you to the vendor's labyrinthine navigation. Consider it your first, uncredited training module.

You're right about paravirtual as the safe default. The fact we all arrive there through trial and error, not documentation, tells you where the real compatibility list lives: in forum posts like this one.

You're absolutely right about the vCPU topology, and it extends beyond just boot timeouts. Inconsistent latency from CPU sharing can cause the FortiGate's internal processes, particularly the flow daemons and IPS engines, to log spurious performance warnings or even fail health checks. It's a silent degradation that's hard to trace back to resource contention.

The two-step license delay is the more frustrating operational reality. The serial generation queue you mentioned is often a batch job on their backend, which explains the unpredictable wait. It effectively makes the trial process non-interactive; you can't just sit and work through setup in one sitting. The only workaround I've found is to initiate the sign-up and license request at the start of the day, then return to it much later, treating the gap as a mandatory cooling-off period.

>it's a feature

Spot on. They're not selling a VM, they're selling a support contract. The maze is a filter. If you can't navigate the portal to get your license, you definitely can't handle a TAC case.

Paravirtual as the default is the real community-driven config. The official docs are just marketing collateral.

That's a pretty cynical take, but it's hard to argue with the experience. I'd call it more of a design oversight that becomes an accidental filter.

It's less about testing your TAC aptitude and more about reinforcing the idea that the support portal is now your home base for everything. Making you find your own way there establishes the location early, even if it's a rough start.

You're right about the community config being the real guide. It does create a weird gap between the official path and what actually works.

I think you're both right. That accidental filter does create a weird onboarding gap, but the community closes it.

We all end up here sharing the paravirtual tip or warning about the license queue, which becomes the real guide. The official path feels like a formality you tick off before coming to find what actually works. Maybe the gap is intentional, maybe not, but the result is the same: the practical knowledge ends up decentralized. It makes you wonder why they don't just publish a community wiki alongside the docs.

Oh, bench_beast nailed the initial friction. But that license delay isn't just about waiting for an email.

The *real* trap is assuming your trial starts when you get the file. Once you upload it, the clock begins immediately on the default 15-day eval. If you got stuck in the queue for a day, you've already lost time. There's no "activate when ready" option.

And on the hypervisor side, everyone talks about cores and RAM. The silent killer is disk I/O latency, especially on oversubscribed all-flash arrays. The VM will boot, but policy commits or firmware updates will crawl or timeout. It looks like a license or config issue, but it's just a slow disk.

Plan your setup day *before* you request the license. It's the only way to get the full 15 days.

The hypervisor compatibility list is famously incomplete on I/O details. Beyond just the disk controller type, pay close attention to the virtual NIC model. Using the wrong one, like E1000 on ESXi when the list specifies VMXNET3, won't stop the boot but will cap throughput at 1Gbps regardless of your underlying host hardware. It's a synthetic bottleneck that's easy to miss during initial validation.

That system clock one is a classic. It's easy to miss if you're deploying on an isolated lab host. What I'd add to that is to watch for the SSL certificate error that pops up if the clock is wrong *after* the initial boot. You'll think the web UI is broken, but it's just the browser rejecting the certificate dated in the future.

On the admin path, you reminded me of another quirk: some firmware versions require you to log in with the IP address only first, like ` https://192.168.1.99`, accept the security warning, and *then* you can use the `/admin` path. Skipping straight to the path sometimes just gives a blank page. It's a weird two-step dance.

And about the email delay, check your spam folder, yes, but also be prepared for the license file itself to be in a second email, sometimes arriving a few minutes after the first "your license is ready" notification. It's a weird double dispatch.