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.
FWF60D x2 FWF60C x3 FGT80C rev.2 FGT200B-POE FAP220B x3 FAP221B x2
FSW224B x1
Solved! Go to 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.
dfollis wrote: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 **** 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.
Completely agree!! And this is NOT the first time this happens........
Fortigate <3
Jordan_Thompson_FTNT wrote:BrUz wrote:+ Google Chrome is unstable on all devices running 5.2.4.
You are likely running into this Google Chrome issue that causes certificate exemptions to be reset:-
https://code.google.com/p/chromium/issues/detail?id=513903
https://code.google.com/p/chromium/issues/detail?id=473390
It is not a FortiOS bug. Using a trusted certificate would solve the problem.
It happens only in 5.2.4. That does not happen in any of < -5.2.3 .. I login without problems, and after 1-2min I have to log in again.
Fortigate <3
BrUz wrote:
It happens only in 5.2.4. That does not happen in any of < -5.2.3 .. I login without problems, and after 1-2min I have to log in again.
And that's why I said "likely" the same problem since there was no other information in the original report.
Can you provide more information about the problem? Chrome version, operating system, HTTP vs HTTPS access, and the specific symptoms that happens when you are forced to log in again? Errors from Chrome developer tools would be particularly helpful.
Jordan_Thompson_FTNT wrote:I have seen this from different computers at different sites, the last days in:BrUz wrote:
It happens only in 5.2.4. That does not happen in any of < -5.2.3 .. I login without problems, and after 1-2min I have to log in again.
And that's why I said "likely" the same problem since there was no other information in the original report.
Can you provide more information about the problem? Chrome version, operating system, HTTP vs HTTPS access, and the specific symptoms that happens when you are forced to log in again? Errors from Chrome developer tools would be particularly helpful.
40C : 5.2.4
60D : 5.2.4
90D : 5.2.4
Computer1 (Win8.1pro_x64)Login to FWF90D: 21:36:?? browsing around in random places, falling out 21:37:50 with this screen:
Computer2 (Win7pro_x64)Login to FGT40C: 21:49:30 browsing around in random places, falling out 21:55:20.
It does not happen every time..
Then menu at the left side is still working(Can still click the menu), but the big gray window at the right side is failing..
I have not seen this in IE. I can provide more info, if you cannot recreate this.
Fortigate <3
BrUz wrote:
It does not happen every time..
Then menu at the left side is still working(Can still click the menu), but the big gray window at the right side is failing..
I have not seen this in IE. I can provide more info, if you cannot recreate this.
Are you using HTTPS or HTTP? If HTTPS, are you using a self signed certificate or have you uploaded custom certificates to these devices?
Can you open developer tools in Chrome and include a screen capture of the "Network" tab when the right side starts failing?
BrUz wrote:I have seen this from different computers at different sites, the last days in:
40C : 5.2.4
60D : 5.2.4
90D : 5.2.4
Computer1 (Win8.1pro_x64)Login to FWF90D: 21:36:?? browsing around in random places, falling out 21:37:50 with this screen:
Computer2 (Win7pro_x64)Login to FGT40C: 21:49:30 browsing around in random places, falling out 21:55:20.
It does not happen every time..
Then menu at the left side is still working(Can still click the menu), but the big gray window at the right side is failing..
I have not seen this in IE. I can provide more info, if you cannot recreate this.
I don't think this is caused by 5.2.4. We've been getting this on 5.0.12. We think it coincided with Chrome 44, which broke lots of things for us. We've reverted to using Firefox to log into our FGTs until either Google or Fortinet fix it.
Another thing I'd like to add.
When I upgraded to 5.2.4, I noticed that about 20 WIFI clients were logged onto a single FortiAP 221B. I have five of them around the office where I work at and usually the clients are dispersed among the APs. After downgrading as per TAC advice (for another issue I posted above), the APs then started load balancing them and the usual client dispersal pattern was seen once again.
I think so far 5.2.3 is the most stable for me 100D and my FortiAP 221Bs.
Zulhardy wrote:Another thing I'd like to add.
When I upgraded to 5.2.4, I noticed that about 20 WIFI clients were logged onto a single FortiAP 221B. I have five of them around the office where I work at and usually the clients are dispersed among the APs. After downgrading as per TAC advice (for another issue I posted above), the APs then started load balancing them and the usual client dispersal pattern was seen once again.
I think so far 5.2.3 is the most stable for me 100D and my FortiAP 221Bs.
I have similar problems. FAP21B take all users and working fine.. But, no users are able to connect through local radio in fwf90d.
Fortigate <3
BrUz wrote:
I think so far 5.2.3 is the most stable for my 100D and my FortiAP 221Bs.
I agree. We went from running 5.2.3 on a 100D to running it on a 500D and it is running without any issues that we have been able to detect. I would say that when I migrated the config, I did it in blocks, by copying and pasting sections of the config file and uploading them via the script import option. I had to prune/clean the sections with interface name changes using notepad++ but all in all it was a fairly smooth process.
Made the huge mistake of upgrading a few customers from 5.2.3 to 5.2.4 last night. Please do not install this firmware...
As some others have hinted, when more than one external interface is used in a load-balanced or virtual-wan-link configuration, external management and SSL VPN traffic stops working. In one case, it is always asymmetric. In one external interface, out the other. No idea. Fortinet confirmed the bug. We've also seen lightly used units entering conserve mode. The ones I upgraded included 100Ds, 300Ds, and 500Ds.
I'm not sure why this firmware is still available for download. Lost some major points with customers today
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1738 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.