FortiOS v5.2.4 is out(Unstable GUI, Bad SSLVPN)....

[storaid]

a little disappointed..

no enhancements..

it's just a bugs fixed release....

[size="5"]definitely 1 of terrible f/w for FOS...[/size]

UNSTABLE GUI

[size="6"]ANNOYING SSL VPN problem..............[/size]

[size="3"]fortinet, I think you must quickly push out next fixed release or give some explains.........[/size]

201508020844, CSB-150730-1-Partial-Config-Loss

FortiGate models listed below may lose configuration pertaining to IPsec interface, virtual access point interface, loopback interface, or virtual-switch interface after a reboot when the FortiGate is deployed with FortiOS 5.2.4 with build number 0688 and time 150722.

FGT20C3X12000161 # get sys stat

Version: FortiGate-20C v5.2.4,build0688,150722 (GA)

Potentially Affected Products:

FortiGate: FG-20C, FG-20C-ADSL, FG-30D, FG-30D-PoE, FG-40C

FortiWiFi: FW-20C, FW-20C-ADSL, FW-30D, FW-30D-PoE, FW-40C

Resolution:

FortiOS 5.2.4 software images for the models above have been rebuilt and re-posted on the customer support web site with build number 0688 and time 150730.

[seadave · Accepted solution]

Why does this keep happening?  Fortinet makes such great hardware, but they have seriously burned some of us with bad firmware releases.  I'm a constant Fortinet advocate, but this kind of crap demonstrates a lack of QC and concern for the customer environment.  These type of issues should definitely be exposed by a good QC system and if the firmware has the potential to wipe a config, for godness sakes it should not be released.  Those of us who are long time Fortinet customers have learned to be wary of new releases and to always reboot the appliance, take a back up, and wait for others to expose the bugs, but it doesn't need to be that way with the right internal controls at Fortinet.  Pick up the slack guys.  You make a great product but you are tripping over your own feet when you release builds like this.

[Flyshuffle]

We upgraded a FG300D from v5.2.2 to v5.2.4 last night and it didn't take long to find a policy had stopped working. It is just a simple policy that redirects http/https to a VIP address for a web server. I ran a flow trace on the console and found the traffic was "Denied by forward policy check (policy 0)" after the firmware upgrade, however I couldn't find any reason traffic would not match a policy.  I downgraded to v5.2.3 and the policy started working right away.

Reading these posts, I wonder if there is a bug in the https service object, similar to the v5.2.2 "All" service group bug where the protocol number was changed in that release causing the All service group to be ignored. Other policies with https service objects appeared to work fine for me though and afaik it was just the one policy.

[Paul_S]

Flyshuffle,

Thank you for sharing about your upgrade.

 It sounds like your issue might be related to the VIP since your other HTTPS rules worked. do the other HTTPS rules use a VIP?

Did you submit a ticket so the rest of the community can figure this out before we upgrade?

-Paul

[Flyshuffle]

Paul S wrote:

Flyshuffle,

Thank you for sharing about your upgrade.

 It sounds like your issue might be related to the VIP since your other HTTPS rules worked. do the other HTTPS rules use a VIP?

Did you submit a ticket so the rest of the community can figure this out before we upgrade?

-Paul

I think you're right. As far as I could tell other policies with HTTPS worked just fine, though I was pretty focused on a single problem when I was troubleshooting. I have a ticket open with Forticare and they mentioned that what I was seeing could be the result of a known bug in version 5.2.4, but could not say for certain without troubleshooting it with me. I needed to get back into production, so I downgraded to 5.2.3 and moved on.

Tech support also offered to work with me live if I wanted to upgrade to version 5.2.4 again, which I thought was cool. However, I am going to wait a bit longer before I feel comfortable attempting to upgrade again.

[Paul_S]

Flyshuffle wrote:

I think you're right. As far as I could tell other policies with HTTPS worked just fine, though I was pretty focused on a single problem when I was troubleshooting. I have a ticket open with Forticare and they mentioned that what I was seeing could be the result of a known bug in version 5.2.4, but could not say for certain without troubleshooting it with me. I needed to get back into production, so I downgraded to 5.2.3 and moved on.

Tech support also offered to work with me live if I wanted to upgrade to version 5.2.4 again, which I thought was cool. However, I am going to wait a bit longer before I feel comfortable attempting to upgrade again.

Thanks for the update. let me know if you do figure this one out. I am on version 5.2.3 and I already have a VIP issue with TLS 1.2 . 5.2.4 is suppose to fix it, but I don't want to trade one bug for a worse bug.  Perhaps you can send them your entire config and suggest they do the upgrade in their lab. maybe they can determine if it is a bug without affecting your production. They may say no, but it is worth a try. I have had some success with these types of suggestions in the past.

[seadave]

Flyshuffle wrote:

We upgraded a FG300D from v5.2.2 to v5.2.4 last night and it didn't take long to find a policy had stopped working. It is just a simple policy that redirects http/https to a VIP address for a web server. I ran a flow trace on the console and found the traffic was "Denied by forward policy check (policy 0)" after the firmware upgrade, however I couldn't find any reason traffic would not match a policy.  I downgraded to v5.2.3 and the policy started working right away.

Reading these posts, I wonder if there is a bug in the https service object, similar to the v5.2.2 "All" service group bug where the protocol number was changed in that release causing the All service group to be ignored. Other policies with https service objects appeared to work fine for me though and afaik it was just the one policy.

The "All" one was a fun time :)

[dwilliams1979]

I have noticed unstable connectivity to the web interface on models ranging from 60C/D up through 200D using 5.2.4.  It is very annoying but if I had to choose an annoying bug over a vulnerability that makes the entire product line fail PCI audits I'd happily take the annoying.  Too bad 5.2.4 has both problems.

https://forum.fortinet.com/tm.aspx?m=128617#129954

[OPSEC]

Upgraded my 800c 3 weeks ago and seems to be stable. IE runs like garbage, Chrome is MUCH better.  Previous version (5.0.9) would take forever to load my objects, but 5.2.4 seems to load them faster. My only problem is that I lost the capability to filter objects. I can filter policy, but not objects (addresses /services) Also, the new "add policy above/below" adds a disabled any/any rule that has cert inspection and NAT turned on by default, really annoying.  I opened a ticket 3 weeks ago about the above and I have heard nothing.

[FatalHalt]

We don't have any 5.2.4 devices, but yesterday I did a support session for a customer's 5.2.4 device. Committing a change like making a new address would take 5 minutes to process, the gui would hang. Absolutely silly. 

[ede_pfau]

IDK if that is of any help to you, but I can confirm that object filtering is working as intended on v5.2.3. Filter even are persistent when changing section/global view mode. I'm using FF 40.0.latest.

[OPSEC]

ede_pfau wrote:

IDK if that is of any help to you, but I can confirm that object filtering is working as intended on v5.2.3. Filter even are persistent when changing section/global view mode. I'm using FF 40.0.latest.

It does as TAC is saying that in version 5.2.x they removed filtering  for the search bar.  However, he is confused as he is referencing page 16(document linked below) that talks about the new search bar for log viewer only.

http://docs.fortinet.com/d/fortigate-whats-new-for-5.2