FortiOS 5.2.8 is Out

Baptiste · ‎07-04-2016

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

2 FGT 100D + FTK200

3 FGT 60E FAZ VM some FAP 210B/221C/223C/321C/421E

netwrkr · ‎07-28-2016

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 ;)

Bunce · ‎07-31-2016

netwrkr wrote:
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:

http://www.pkguild.com/2015/08/how-to-disable-sip-and-rtp-processing-on-your-fortigate-for-voip-good...

http://www.3cx.com/blog/docs/disable-sip-alg-on-fortigate/

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.

Wondering if it might be relevant..

Thanks in advance.

Andrew

donnat · ‎08-01-2016

Other info about SIP: http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD36175&languageId=

Cluster Active/Passive Fortigate-1500D 6.0.9 (AV, DLP, AppCtrl & IPS, DHCP, AlertMail, Fortiguard Web & AS, OSPF & RIPv2, SSL-VPN Portal Web and Tunnel) FortiAnalyzer-3000D 6.0.8 (Log, Syslog, Alert event, Quarantine & Report)

Itguy · ‎08-02-2016

All of our managed Fortigates are now on 5.2.8 as of 2 weeks ago.

No issues noted, with any client. Devices range from 30D up to 3000.

FortiOSman · ‎08-04-2016

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.

Itguy · ‎08-25-2016

This tunnel error seems to be around since 5.2.5..

Tunnel is up. Pings between tunnel is fine. But no data otherwise will pass. Reboot fixes it.

We've been struggling with this error a long time with no resolution from Fortinet. Very frustrating.

FortiOSman · ‎08-25-2016

Itguy wrote:
This tunnel error seems to be around since 5.2.5..

Tunnel is up. Pings between tunnel is fine. But no data otherwise will pass. Reboot fixes it.

We've been struggling with this error a long time with no resolution from Fortinet. Very frustrating.

Have you ever gotten them on the phone while the issue was happening to diagnose? I feel like that is the only way to really pinpoint it. I didn't get a chance given the criticality of a tunnel being down, and after I rebooted I lost my logs since it couldn't connect to my Analyzer which was on the other side of the tunnel.

Is rebooting the only thing that has fixed it for you? And is it just 1 tunnel that has the issues or do all tunnels experience this when it happens? My 200B only had one tunnel configured so I couldn't tell.

Mattbaldwin · ‎08-25-2016

Itguy wrote:
This tunnel error seems to be around since 5.2.5..

Tunnel is up. Pings between tunnel is fine. But no data otherwise will pass. Reboot fixes it.

We've been struggling with this error a long time with no resolution from Fortinet. Very frustrating.

We had an issue with a VPN tunnel not passing traffic and Fortinet diagnosed it as being a known bug to do with the NPU offloading IPSEC and it was fixed by running the command "set npu-offload disable" against the phase 1 of the problematic VPN.

FortiOSman · ‎08-26-2016

Mattbaldwin wrote:
Itguy wrote:
This tunnel error seems to be around since 5.2.5..

Tunnel is up. Pings between tunnel is fine. But no data otherwise will pass. Reboot fixes it.

We've been struggling with this error a long time with no resolution from Fortinet. Very frustrating.

We had an issue with a VPN tunnel not passing traffic and Fortinet diagnosed it as being a known bug to do with the NPU offloading IPSEC and it was fixed by running the command "set npu-offload disable" against the phase 1 of the problematic VPN.

Excellent news. Thanks for sharing that. Do you happen to have the bug ID? I want to reach out to their support for more information.

MrSinners · ‎08-26-2016

I am also interested in this bug ID. Planning to upgrade critical FG's soon from 5.2.4 to 5.2.8 which are using policy based VPN's..

Maybe someone from Fortinet can also reply in this topic?