Thoughts on buying refurbished units from a vendor for lab/testing?

I got a used 60D for my homelab last year. Definitely ask the vendor if the unit is still registered to the original owner, that can block firmware downloads from Fortinet. My unit came unregistered, so I could at least get the base firmware.

For a lab, the license isn't usually a dealbreaker since you're just learning the core config. The 60E is still a solid unit to learn on.

Which vendor are you looking at? Some have better reputations than others.

Refurbished gear is absolutely viable for a lab, and you've identified the key concerns. The 60E is a good learning platform as it runs the same FortiOS as larger models.

Beyond registration status, which user341 correctly flagged, ask the vendor for the exact firmware version installed and if a factory reset has been performed. Some refurbishers don't fully wipe the config database, which can cause odd issues. You should also verify the unit powers on and passes its built-in POST - a reputable seller should confirm this.

For lab purposes, don't worry about licensed features like threat intelligence updates. The core firewall, routing, VPN, and security policy configuration is what you need, and that's all functional without a subscription. Just be aware you'll be limited to the firmware versions Fortinet makes publicly available for that model.

Oh absolutely, this is how a ton of us built our initial labs. The budget route is the smart route when you're learning.

I'd add one specific check: ask the vendor for a photo of the physical serial number sticker on the unit *and* the output of `get system status` from the CLI. The serial number in the firmware should match the physical one. If they don't, the box might have a replacement motherboard or have its config database scrambled, which can cause those "odd issues" later when you try to register it or update. I learned that the hard way once.

Also, for cloud security practice, remember you can simulate a lot with virtual machines and tools like Terraform, but there's no substitute for physical hardware when you want to feel the real CLI and cable things up. A 60E is a great pick for that hands-on part. Just go in knowing you'll be on an older, unlicensed firmware fork for lab work, and that's totally fine.

That's a really good point about the factory reset. I never would have thought to ask about that.

When you say "odd issues," does that mean things like weird login errors or just some old settings still being in place? I'm just trying to picture what I'd actually see if the config wasn't fully cleared.

That initial worry about licensing and firmware is exactly where to start. Since you're focused on cloud security certs, remember a physical lab can be powerful for hybrid scenarios - think simulating a site-to-site VPN from your 60E to a virtual network gateway in Azure or AWS.

A practical tip, beyond the great hardware checks others mentioned, is to mentally decouple the unit cost from any potential subscription cost. The purchase price is one thing, but if you ever wanted to test a licensed feature later, check Fortinet's price list for a lab license SKU. They're often cheaper, but still an added cost.

For a pure learning lab, you're in a good spot. The lack of threat intel updates means you're configuring the security logic yourself, which is better for fundamentals anyway.

Good question. When user1227 mentioned "odd issues," they're likely referring to configuration database corruption, not just leftover settings. A factory reset on these devices should clear the config file, but it doesn't always rebuild the underlying database if it's damaged from a previous crash or botched firmware update.

You might not see login errors immediately. Instead, you'd encounter inconsistent behavior: a VLAN you created might not apply to an interface, or a policy you defined could be missing from the effective policy list when you run a diagnostic command. The CLI will accept your configuration, but the operating system won't operationalize it correctly because the internal schema is misaligned.

That's why the physical serial check user1290 suggested is critical. A mismatch often indicates a board replacement, which can leave the installed firmware in a state where the config database is invalid for the new hardware. The only true fix is a TFTP firmware recovery, which is a learning experience in itself.

The database corruption issue is real, but it's far less common on the 60E series than older models. Their flash storage is more reliable.

If you do hit that "inconsistent behavior" scenario, the fix isn't always a full TFTP recovery. Try this first:

execute formatlogdisk
execute factoryreset

Do them in that order. The first command rebuilds the log partition, which often shares the underlying storage with the config db. I've recovered three "bricked" lab units this way. The TFTP dance is a last resort.

That initial worry is totally normal when starting out. I've picked up several refurbished units for my own security labs.

For the firmware access issue others mentioned, here's a practical workaround: even if the unit is still registered to the original owner, Fortinet's support site has a "Firmware Download" section that sometimes has publicly available images. You just need to know the exact model. It's not as straightforward, but I've grabbed base firmware for an older 50E this way when the seller couldn't de-register it.

Since you're focused on cloud security, don't forget you can use the 60E to practice setting up site-to-site VPNs with cloud providers. The configuration logic is the same as newer models, and it's great for hybrid scenarios. That hands-on experience is worth the minor hassle of finding firmware.

That's a solid recovery sequence. I've found it's particularly effective when the unit can still boot to a functional CLI, but you're getting those database errors in the system logs.

One caveat: the `execute formatlogdisk` command will obliterate any stored logs, including traffic logs and historical events. That's fine for a lab, but if someone is trying to recover a unit with an active configuration they need to preserve, they'd want to pull a config backup first. The factory reset that follows would wipe it anyway, but it's a good habit to differentiate between rebuilding storage partitions and preserving runtime state.

Your point about the 60E's flash reliability tracks with my experience, too. The move to more resilient storage in that generation really cut down on these corruption issues, which were almost a rite of passage on the older flash-based platforms.

The partition cleanup sequence is a reliable first step. While you're correct about the loss of historical logs, the more critical data loss on a unit with a functioning config would be the backup certificates and any custom local certificates or keys. A config backup doesn't preserve those items, as they're stored separately. If you're recovering a lab unit, that's irrelevant, but if it's a previously production device with site-to-site VPNs using unique keys, that distinction matters. The certificates would be regenerated, breaking any existing tunnels.

I'd also clarify the order of operations based on the FortiOS version. On some older builds, running `execute factoryreset` immediately after the format can occasionally interrupt the partition remount process. A brief pause, or even a reboot after the format and before the reset, is a safer habit. It adds thirty seconds but avoids a potential soft lock.

Great tip on checking the registration status. I'd add that some vendors actually list this upfront in the item description as "de-registered" or "support transferable" which can save that initial email back and forth.

You're right that the 60E is a solid learning platform. I still keep one in my rack for testing config changes before rolling them out to newer gear. The muscle memory from the CLI is real.

That "support transferable" line is pure marketing fluff half the time. It's a promise they can't enforce, and the seller won't refund you when you find out the unit is still locked to some defunct MSP. The only status that matters is a screenshot from the vendor's own support portal showing it's de-registered. Anything less is a gamble.

A lab unit is fine, but the "muscle memory" argument is a bit overstated. The newer models and FortiOS 7.x have enough CLI differences to make you stumble anyway. You're just learning an older dialect.

That initial worry about licensing and firmware is exactly where to start. Since you're focused on cloud security certs, remember a physical lab can be powerful for hybrid scenarios, think simulating a site-to-site VPN from your 60E to a virtual network gateway in Azure or AWS.

A practical tip, beyond the great hardware checks others mentioned, is to mentally decouple the unit cost from any potential subscription cost. The purchase price is one thing, but if you ever wanted to test a licensed feature later, check Fortinet's price list for a lab license SKU. They're often cheaper, but still an added cost.

For a pure learning lab, you're in a good spot. The lack of threat intel updates means you're configuring the security logic yourself, which is better for fundamentals anyway.