FortiOS 5.2.8 is Out

[Baptiste]

http://docs.fortinet.com/uploaded/files/3130/fortios-v5.2.8-release-notes.pdf

[Mark_Holtkamp]

Had an update notice on our FGT 100D, will update the unit to 5.2.8 this weekend but no love for the FGT 60C yet. The 60C is included in the 5.2.8 release notes as being supported, but the unit itself and FortiCloud report 5.2.7 as the latest firmware for this model. Anyone else have a 60C and hasn't received an update alert?

[Mattbaldwin]

FGT_60C-v5-build0727-FORTINET.out is listed in the firmware downloads for 5.2.8 in the support portal.

[Lucascat]

Any feedback?

[Itguy]

Upgraded a couple (out of our 400 managed) Fortigates to 5.2.8 after testing internally.

No issues. Plans to push it to all 400 next week unless something comes up between now and then.

[Lucascat]

which models?

[Mattbaldwin]

Upgraded a 100D and 60D and no problems so far.

[Baptiste]

Hi, I plan to update 5.2.8 this week.

I upgrade FSSO collector from 5.0.241 to 5.0.250 without error (running win 2k8 & win 2k12)

But I failed to upgrade manually DC agent on my two DC (win2k3 R2 SP2 : one 32bits, one 64 bits).

both fail at the end with same error : Windows can't open this software because of a software policy

So I remove DC agent on the 2k3 64bits server, reboot, install DC agent was successfull.

Will do the same for the remaining 2k3 32bits server.

Did you update DC agent without error ?

[Itguy]

Mattbaldwin wrote:

Upgraded a 100D and 60D and no problems so far.

We have a few 60's on it right now, no issues. Pushing it to more this weekend, some 100's, 80's, 92's, and a 200 or two. We will see how it goes.

[krdoor]

stay away from 5.2.8 if you are using IPV6

We have seen multiple crashes (kernel panics) during linux system upgrades (yum update, apt-get update) on ipv6 enabled servers.

Could be related to apply ctrl / ips / web filtering , but so far Fortinet was not really helpful in explaining why the crashes occurred.  Fortinet answer:

>> The kernel panic is not related to yum specifically..   >> It is related to ipv6 traffic and from the notes is caused by kernel NULL pointer dereference for ipv6 traffic.  >> Now, it was remarked during the investigation that (at least in that case), the crash was caused when tftp

>> session helper was used by the traffic (which was tftp traffic). As soon as the tftp session helper was removed

>> the crash  was not observed anymore.  

But we didn't do any tftp at the time of the crashes, so in my opinion the problem is worse