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?
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
We upgraded multiple locations to 5.2.8 in the hopes the SIP ALG issue was resolved - negative.
At some random point in time, the FG will start natting SIP (port 5060) traffic using the IP address of the outbound interface. When I say random, I mean random - like 2am when everyone is at home sleeping - so I'm quite confident it isn't someone making a change and breaking something. This has happened on multiple sets of 200D's so...
A new issue arose with 5.2.8 whereby when a pair of 200D's, is in an active-active configuration and "set load-balance-all enable" the synchronization of the application filters becomes synchronized and traffic is randomly denied or permitted depending on which firewall processes the traffic. The only way we've found to deal with this is to disable that setting and have only one of the firealls handle the application layer traffic inspection.
If a FG tech wants more information I'm happy to assist but I do not have 8 hours to work with your L1 techs to help them understand the issue ;)
We upgraded multiple locations to 5.2.8 in the hopes the SIP ALG issue was resolved - negative.
At some random point in time, the FG will start natting SIP (port 5060) traffic using the IP address of the outbound interface. When I say random, I mean random - like 2am when everyone is at home sleeping - so I'm quite confident it isn't someone making a change and breaking something. This has happened on multiple sets of 200D's so...
Does this apply even after disabling the sip-helper and sip-nat-trace settings, and deleting the session-helpers?, eg as per these:
We've got a strange, albeit intermittent, audio issue in our VOIP environment where traffic traverses the a pair of FG-200D's but on internal facing interfaces only (eg from corporate lan to VOIP server) - no NAT enabled.
I upgraded our 200B from 5.2.1 to 5.2.8 following the recommended upgrade path.
Yesterday (5 days after the upgrade), one of our IPSec tunnels to an 800C stopped passing traffic. The tunnel was up on both sides but no traffic was flowing. I tried flushing and resetting the tunnel but that didn't fix it. I had to reboot the 200B. As soon as it came back online the tunnel starting passing traffic.
Wary of 5.2.8 now.
--Update--
3 weeks have passed since the tunnel failure and I've had no issues since.
