It's good for what it is. I could achieve the same results with a pfSense firewall. This one just comes in a nice hardware package.
Better documentation about usage of the CLI. I learned most of what I know in diagnostic functionality through saving SSH sessions with the customer support staff while in WebEx sessions.
I have tried looking up the manuals. They are OK in some respects, but I feel exhaustive documentation about the CLI "with examples" should be there, and I feel it's not.
I'm saying, hey lets consolidate some of the primary real world scenarios like:
Section A: - Troubeshooting B2B VPN peering with a business partner or client when initially setting up the VPN tunnel.
Inevitably, there are always quirks and nuances between the fortigate vendor versus peering with a Palo Alto or an ASA firewall or even a Juniper SSG.
Imagine providing all steps, command line syntax, and GUI (if available) and how to take steps to debug the flow and see what's failing.
Sometimes it's super hard to figure out what's wrong with a fortigate VPN unless you know the commands on the CLI to see the flow and how to interpret it.
If they had all the methods / syntax and the "how's and why's" for a scenario; even possibly an instructional video showing how via the CLI and gui alongside the documentation. It would be like the pearly gates had opened and I had gone to heaven.
I have used it for three years.
I never encountered any stability issues. It is a very stable product.
Scalability's not been an issue for my org. We only utilize it for certain applications.
Technical support is excellent, although it can be a bit difficult to understand the tech. As with most support staff from almost all vendors now, the support comes from somewhere across the pond.
On the site where the FortiGate is stationed, it's never been changed out.
Initial setup was straightforward.
Buy the support package! Upgrades, advice about upgrade paths, and troubleshooting help is paramount. There have been some times where, without it, I'd have been dead in the water.
This was an in-place firewall when I integrated the site to my org.
Figure out what features you want, and what policies you want. Look up how to do it in advance, and create an implementation plan.
Plan for policies, routing, NATting, etc. Create a step-by-step process in advance, possibly create the environment in a DEV sandbox, test it, then implement.
It has a good feature set. However, sometimes you are forced to solicit technical support to get it working.
Also, I find the web interfaces sometimes do not display things properly.
The easy way to migrate from one model to another is taking the config file and modify it manually, say rename port WAN to port-1 ( sometimes you need to modify the syntax of commands when moving between different versions) and upload the config back. Another method is to divided the config file to multiple sections say interfaces , NAT policies , Firewall ACLS / objects / object groups , then modify every part as required and upload them one-by-one.