FortiGate FortiOS release madness

[make]

Hello Everyone,

I'm wondering what is Fotinet up to with all their current releases branches. This is absolutely madness.

- 5.2.x finally works stable on most of the FortiGate units but it's already End of Engineering Support and the end of support Date is 2018-12-13. It's also not available for the E/F series.

- 5.4.x received the most updates from the newer releases but ist still full of bugs.

- 5.6.x is patched to version 3 from 2017-12-05 and contains really a lot of bugs (Month of post: March). It seems like it doesn't get a lot of attention from Fortinet.

- The upcoming 6.0.0 release will also be full of bugs and most likely not recommend/suitable for prod environments. IMO most of the customers should wait at least 1 year of development and bug fixes before using it.

So what is your strategy for 2018 and FortiOS? Are you using FortiGate D Series with FortiOS 5.2 even after EoS or are you using 5.4/5.6 with the need to frequently bother the bug-tracker and/or support?

Thank you all

[SMabille · Accepted solution]

Hi,

Fully agree, lack of "long term" sustained engineering version is a real issue.

5.4.x prior to 5.4.8 was not production ready at all (is it now? It's probably getting were 5.2.5-5.2.7 was), so we didn't recommended large critical customer for whom stability is primordial to upgrade yet.

Now we got (very weird) performance issue on 5.2 (likely IPS/IPS Engine) but end of engineering means pushing the customer to upgrade, putting us in a very awkward situation. 

In perfect world (not driven by marketing), in my opinion, we need 5.2.x fully supported for at least another 12 to 18 months.

5.4, 5.6, 6.0 don't, in my opinion warrant three major revisions. Most of 5.4 and 5.6 under one version, with security fabrics and internet services, and another version with NGFW Policy mode and 6.0 new features.

More efforts should be in stabilising current version, with longer term support, and less new branches.

[emnoc]

If you read my post correctly, I complain about the lifespan of stable version,

That's not how it work and you should know that.

What 's stable for you, might mean 180 deg  different for the customer xyz  or abc.

FWIW: I have  "a stable version 5.2.4" devices still running. They can't legally be upgrade due to EULA and no contracts.

The industry  standard is approx 4 years for most vendors , and FTNT fits in this model.  If you research  FTNT and any of the version previously you will see v5.2.x was no different in total time out. FortiOS v5.2 has a final milestone of EoS scheduled for 12-2018 iirc. So you have slightly over 9 more months ;)

So with that track, it would be like 55months lifetime from original release. ;)

customers complaining that once they finally reach a stable platform they have to upgrade 6 months down the line with the risk of a new cycle of major bugs discovery

No one is forcing you to upgrade btw. Also if you  compare FTNT to vendor XYZ it's the same life spn, so you can vote with your feet and walk to another vendor but the  same will apply IMHO.

Ken

[SMabille]

5.2.x is already end of engineering support. Customer hitting performance issue on IPS engine been told upgrading only solutIon. I’m glad you / your customers don’t see it as a problem but I got a few large accounts thinking leaving Fortinet purely for that reason. I still believe having a longer lifespan wouldn’t be costing too much money and efforts and reassure customers.

[Kommissar]

SMabille wrote:
If you read my post correctly, I complain about the lifespan of stable version, so let’s be generous 5.2.7 was 03/17, exactly a year ago (and still discovered a couple of major bugs) and EOL today. 5.4.8 is now solid enough to recommend customers to use it, but with 6.0 being released 5.4 EOL is already in sight. And for reference PanOS lifecycle is very different to what you mention (it would mean 5.2.13 would have engineering support for 48 months). Commercially it’s invaluable Software release 5.0 or after: Major feature releases will be supported for 24 months. The last minor feature release of a major release cycle (see definition below) will be supported for 48 months. Support includes technical support, bug fixes, maintenance releases, workarounds, and patches for critical bugs And I’m sorry but customers don’t have to “live with it”, they are always free to vote with their feet. As FG partner it’s one of the biggest issue we got, customers complaining that once they finally reach a stable platform they have to upgrade 6 months down the line with the risk of a new cycle of major bugs discovery.

I completely agree with this stance. I think it's pointless to talk about an industry norm (regarding the lifetime of each major release), because each vendor/manufacturer handles their development differently.

As for Fortinet, my experience is that it takes too much time for a release branch to mature. The 5.2 is finally rock-solid with the v5.2.13 , and I feel the 5.4 only now starts to stabilize with the v5.4.8. It seems to me that Fortinet is always looking for the next big thing, the next major version with new cool stuff, but as a result the existing branches tend to hinge on stability for quite a while. So like SMabille says, it would be great to have an extended support for older branches like the 5.2, mainly for maintenance and critical bugs.

I say this as costumer that has dozens of appliances on the field (mostly Fortigates and FortiAPs) and that has the Fortinet products in high regard. "Surfing" the firmware release waves is definitely the only major downside that I would point out about them.

[emnoc]

Will we have FortiOS   v5.4 , v5.6 and now v6.x . The former is scheduled  EOS in mid-2020, so we should some how  focus in that train. No matter what we think, feel or want, v5.2.x is coming to a wrap up and that's not going to change. V5.4.x has mature enough that any org should be  comfortable with it and works very good on most ALL hardware that runs it.

It can only get better and aslong as we  ( end users ) open cases and reports problems, than FTNT-support can work on these to ensure bugs and fixes are properly resolved.

As far as other vendors they are inline on life-cycle as that of FTNT

e.g PaloAlto

For software products and releases, the following End-of-Life policy applies:

[ul]

Software release 5.0 or after:[ul]

Major feature releases will be supported for 24 months.

The last minor feature release of a major release cycle (see definition below) will be supported for 48 months.

Support includes technical support, bug fixes, maintenance releases, workarounds, and patches for critical bug[/ul][/ul]

If a customer feels this ( FTNT life-cycle ) is not doable than you have many other choices but I highly doubt you will see a big difference even tho I'm very happy with JuniperSRX and PAs ;)

Ken

[seadave · Accepted solution]

All the above concerns are valid, but in some cases, user configuration can play a part in stability.  The classic for me was the "Inspect All Ports" option under "Protocol Port Mapping" for a "SSL/SSH Inspection" profile in 5.4.x.  Turning that on caused all sorts of issues.

For all the talk about how bad 5.4.x is.  I'm running 5.4.5 on a 500D with a single VDOM in proxy mode, with ~85 rules, 1Gbps Internet Link, SSLVPN, MFA via FAC, FSSO, logging to FAZ, VIPs, using all UTM features with the exception of SPAM filtering, and ~225 users.  My current uptime is 83 days.  CPU util is ~10% on average and Mem util is 60%. Maybe I have a simple setup, but seems fairly standard.  Of course some have much more or less complexity.  Also I feel that many folks don't take advantage of the "Feature Select" option in 5.4.X to free up Mem.  If you aren't using a feature, turn it off.  I think this isn't an option in 5.2.X if I remember.  Not sure.

Another problem is update exhaustion.  I see it across all of the hundreds of products I manage.  It is never ending and only getting worse from a frequency and quality standpoint.  Considering the days of 5.0.X I think Fortinet is doing better than most. 

To make updating less error prone, I always buy two firewalls of the same model when we upgrade every 4 to 5 years.  One is for testing, other is production.  This isn't good from a fail-over standpoint but I've never had a Gate brick.  I have over the last 15 years experienced a few bad AV/IPS sig updates, but those can be fixed with a definition refresh.  I can afford (but not enjoy :-)) a few hours of downtime. If I was a bank or retail outfit, this model wouldn't work and I would need a traditional HA setup.

This allows me to take my existing config on the spare Gate, update it and use the "diag debug config-error-log read" to see what the new firmware update didn't like about the old config before moving to production.  Far too few people do this.  We also log to FAZ and via FAZ to Splunk.  This allows us to quickly determine when something changed if a problem occurs.  I use the rule in the FAZ to email me every time a config change is made so I can keep track of those in the event I need to revert.  I realize that some of you are MSPs and this model isn't appropriate for the fleets of small offices you manage.

Herein is the challenge for those folks.  You are working with small shops who don't really understand why they need a firewall and why it should be replaced every 4 to 5 years.  They see it as just another expense they don't want to incur.  Then when there is an issue due to updating because you lack either time or resources to test, they see it as a disruption.  I remember those scenarios from my consulting days and I don't wish to relive them any time soon.

Everyone has the challenge of "its running just fine, why should I get rid of it" when the device is going on 6 to 8 years.  I have that problem with my Force10/Dell switches right now (going on 10!!!).  But I know that continuing to run these will on a daily basis increase the chance that I will experience a major failure, so even though they are "just fine" it is time for them to go.  I would argue you need to be willing to do the same with your firewalls but on a more frequent basis (4 to 5 years) due to the evolving threat basis.

One final comment regarding reliability is sizing.  I've always felt that Fortinet doesn't make it easy to determine what size of firewall you need for a given number of users.  Based on simple economics, many sites go; for obvious reasons, with the least expensive model that seems appropriate.  For example, we used to be running 100Ds, but when it was time to upgrade I asked my VAR what we should be using this go around based on usage patterns and anticipated growth.  They suggested the 500D.  Seemed like a big jump to me at the time, but their advice was solid and as a result we have had zero issues related to resource contention.

[emnoc]

 All the above concerns are valid, but in some cases, user configuration can play a part in stability

agreed ( part in bold ) , I've  seen numerous  sml to lrg biz configurations,  that creates havoc& stink  and then they complain about my firewall is unstable or this version sucks or ,,,,,,,,............

The same for the access/network parts.

To make updating less error prone, I always buy two firewalls of the same model when we upgrade every 4 to 5 years.

IMHO with  the sml-2-medium ORGs this  is next to impossible, the big ORGs are more prone to have LAB , UAT, TEST environments,  so this more easier to bite the bullet and spend the money. They also has more at risk so they invest in lab  gear. They only , lab-gear is hard to mimic traffic-flow for most ORGs

One final comment regarding reliability is sizing.  I've always felt that Fortinet doesn't make it easy to determine what size of firewall you need for a given number of user

this is where good SSEs and Partners and consultants with experiences comes in ;)

good comments tho...

Ken

[JB79]

dfollis wrote:

...but in some cases, user configuration can play a part in stability. 

It seems to me, that mature firmware ought to at least make it difficult for user configurations to cause stability issues.  An analogy for this is how the automotive industry builds in safeguards to prevent you from hitting reverse while moving forward at high speeds.  Reverse is a valid option, but the car could tear itself to pieces without that safeguard.  This kind of thinking just makes sense!

In any case, I agree with pretty much everyone here - more effort in the QA department will make for happier customers, and it's happy customers that like to come back for future business.

[btp]

We run 5.4.8 on all new deployments. Seems stable.