FortiOS 6.2.3 is out

[James_G]

I will be reading this later

https://docs.fortinet.com/document/fortigate/6.2.3/fortios-release-notes/760203/introduction-and-sup...

[emnoc · Accepted solution]

Same here, 6.2.3 is solid and works great. 

Ken Felix

[emnoc · Accepted solution]

We have both on but on all medium size 200 and 300Es, so it looks good for now. Will keep monitor.

Ken Felix

[Jirka1 · Accepted solution]

ede_pfau wrote:

thanks for responding - neither do I, I prefer to use a FAZ instead of an x1 model, better investment even in the short run...

 Hi Ede, Today I upgraded to 6.2.3: 2x 81E HA -  from version 6.0.8, all without any problems (SSL VPN, IPsec VPN, without UTM) 1x 61E - from version 6.0.8, all without any problems (SSL VPN, IPsec VPN, full UTM)

everything is connected to FAZ200D, 6.0.7

only where I had in Custom device group in Policy after the update it changed to "all" - watch it.

Jirka

[Jirka1 · Accepted solution]

Hi Ede, yes, they do

Jirka

[James_G · Accepted solution]

Awesome!

[Jackk]

i need the iso feel of fortigate

[JaapHoetmer]

Further to my earlier message, the release notes have been updated with a known issue that looks like it matches the issue we've seen with one of the firewalls we're managing. We have also fallen back to 6.2.2 and the problems have disappeared as a result.

https://docs.fortinet.com/document/fortigate/6.2.3/fortios-release-notes/236526/known-issues

605950

RDP and other applications affected (freezing, disconnecting) after upgrading to 6.2.3 due to no session match error.

We'll wait for a fix and remain on 6.2.2 until this issue has been fixed.

[Hosemacht]

Hi there,

are there any news about the device enforcement in Policies for FortiOS 6.2.3 or higher?

[Jirka1]

the_giraffe_that_wasnt_president wrote:

Hi there,

are there any news about the device enforcement in Policies for FortiOS 6.2.3 or higher?

Unfortunately, no

[Jannik]

So how is your experience with 6.2.3 so far? I run it on an active-active 61E HA Cluster. I notcied DNS Filter Server is "unreachable" under Network>DNS. This occured on several FG models with customers units... FG61E, FG30E, FG80E, I have an open case with fortinet about that. Also very high memory usage while cpu is very low, <5% most of the time. FG enters conserve mode frequently.

[Magnitude_8]

My experience with 6.2.3 hasn't been great.  I've upgraded two customers with 200E clusters from 6.2.2 and had intermittent issues with web pages not loading and Outlook disconnections from Exchange Online.  Have rolled one back to 6.2.2, which resolved the issues.  Might roll back the other one as well, but this will reintroduce issues with RDP of SSL VPN, so I'm a little reluctant.

[justme]

This is a response for my open ticket regarding connection drops on pppoe links... As the one I manage is a production system there's a procedure to deploy the solution, it's gonna take some time to upgrade from 6.2.2 to 6.2.3 (for the third or fifth attempt).

I have analyzed the logs provided and noticed the following(and I am also attaching the wireshark captures ) : - for FortiOS 6.2.3 the packet length increases so you have 1514 packet size which is not being fragmented by FGT. - in both captures the flag of the packets sent is set to 1 : Don't fragment. - in both 6.2.2 and 6.2.3 the option # set honor-df is enabled on FGT however it seems to be working as expected only on 6.2.3 So my conclusion would be that Honor-df was not working as expected in 6.2.2 but it does in 6.2.3(that's why the packets are not being transmitted anymore). If enabled, "set honor-df" honors the information already set on DF-Bit and not change it. If the honor-df is set to disable, then FortiOS will ignore the packet’s DF flag by encapsulating and encrypting it. I have researched internally for similar situation and and found a few known issues related to # set honor-df but on previous versions : 6.0. and 5.4 If you want to upgrade to 6.2.3 you will have to disable this option in order to avoid any error.

[justme]

Another ticket update... I suggested FGT should probably respond with ICMP Fragmentation Needed (Type 3, Code 4) instead of dropping the packet.. and guess what - it got the WaitGArelease status :) 

Here's the followup 

Currently there is interim build that has the fix, the fix should be available in 6.2.4, currently scheduled for April.

[tanr]

@justme, looks like this is the same as the MTU / ICMP issues described in https://www.reddit.com/r/fortinet/comments/eqpctk/fortios_622_to_623_fortigate_80e_poe/?

Did Fortinet say if the interim build actually has the full ICMP message handling fix, or if it is just a workaround as you describe above?

[justme]

@tanr unfortunately that's all I know. Pretty much pasted the essence of the ticket response.