FortiOS 6.4.1 is out

bommi · ‎06-04-2020

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

Has someone tried this version already?

NSE 4/5/7

Jordan_Thompson_FTNT · ‎07-13-2020

Raudi wrote:
Yesterday i had a issue with 6.4.1 too, after 24 days in my homeoffice my internet access was gone, so i logged in to the 100E and the device shows "conserve mode".

I made a litte research and all the memory was used by "480" tasks with the name "node".

Now after a reboot the memory usage is going slowly straight up, so i think in a few days i must reboot the device again. At the moment i have 186 of the "node" tasks, and every few minutes i can count one more...

Thanks for the report. We are working on a fix for this issue for 6.4.2.

View solution in original post

Magnitude_8 · ‎07-07-2020

I don't think there were any policies with SD-WAN members before the upgrade (is that even possible when they are members of an SD-WAN?). However, I would have used VIPs on individual members. Could that be the cause of the issue?

Sorry, I'm not in a position to share the config in this case.

owla · ‎07-07-2020

We didn't have individual SD-WAN members in firewall policies as well. But you are right we used the members in VIPs as well and I remember after upgrade VIPs had a warning signs.

thuynh_FTNT · ‎07-10-2020

Magnitude 8 wrote:
I don't think there were any policies with SD-WAN members before the upgrade (is that even possible when they are members of an SD-WAN?). However, I would have used VIPs on individual members. Could that be the cause of the issue?

Sorry, I'm not in a position to share the config in this case.

Yes, we do allow using individual SD WAN member in firewall policy in 6.4.0. However, that design is now converted to SD WAN zone in 6.4.1.

Having an inactive VIP on your member interface should not trigger the zone separation. But if the VIP is being used in a policy, this means your policy must have used the member interface since the VIP depends on it, then the member interface will be put in a separate zone. Also worth noting that this is for all policy type, not just IPv4 Firewall. If you still think your SD WAN member should not be put in a separate Zone automatically, please report it to customer service so we can properly follow up on your case there.

owla · ‎07-06-2020

Same happened with SD-WAN.

2 member interfaces belong virtual-wan-link and 1 member interface moved to upg-zone-wan1 after upgrade to 6.4.1

I moved 1 member interface from upg-zone-wan1 to virtual-wan-link and had to update all firewall polices (deleted upg-zone-wan1) and Interface Pair View is Ok now.

But still there are some more small issues:

- CLI from GUI doesnt work (lost connection).

- 'Firewall User Monitor' doesn't show 'User Group' for 'Radius Single Sign-on users' (RSSO works but just doesn't show name of 'User Group')

Decided to roll back to 6.2.4 and wait the next update.

owla · ‎07-07-2020

We had one more issue with 6.4.1

All firewall policies with Flow-based Inspection mode had a warning signs, You can not use inspection mode with current settings. We didn't find the cause of that messages (probably there are new requirements for flow-based mode)

There are not messages in [strike]6.4.2. [/strike] 6.2.4

seadave · ‎07-07-2020

owla wrote:
We had one more issue with 6.4.1
All firewall policies with Flow-based Inspection mode had a warning signs, You can not use inspection mode with current settings. We didn't find the cause of that messages (probably there are new requirements for flow-based mode)
There are not messages in 6.4.2.

Do you mean 6.2.4? I don't see 6.4.2 released unless you are beta testing?

seadave · ‎07-07-2020

One other point of note, is I assume you upgraded from 6.2.4 to 6.4.0 and then 6.4.1? Going from 6.2.4 to 6.4.1 isn't supported if I recall. I just took at 500D from 5.6.4 to 6.4.1 (going to 6.4.0 first was part of the process) and it is running fine, but we are only using it as a one arm sniffer without any other policies so the config is very simple.

owla · ‎07-07-2020

We followed the update path 6.2.4 -> 6.4.0 -> 6.4.1

Our config is complicated. Couple extra VDOMs, SD-WAN, VPN, VIPs, Explicit proxy, 100 firewall rules, deep inspection....

We would like to use new version 6.4.1 because there is new feature 'Upstream proxy authentication in transparent proxy mode'.

seadave · ‎07-08-2020

Ah. Yes I appreciate the complexity now. Good on you for having a good backup so you could revert. Far too few folks keep that option viable due to their processes. Last year we migrated from 500D to 501E. We used the script import section to import our rules and policies with updated interface names. It was a lot of work but got us to a stable config. You have to think through the logical dependancies for it to work. Configure interfaces, then addresses, then security policies, and finally firewall rules. It is tricky but it worked after some false starts.

One other suggestion is after each upgrade have the console online with a laptop via serial so you can watch the process. Use the diag debug config-error-log read to see what it indicates didn't convert properly or is a source or error. One other thing I've done in the past is keep a pre upgrade config and a post upgrade config and use a diff feature such as Notepadd++ or Sublime Editor to look for the differences. Can help pinpoint the problem.

owla · ‎07-07-2020

Sorry, of course to 6.2.4 (roll back)