Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
bommi
Contributor III

FortiOS 6.4.1 is out

NSE 4/5/7
1 Solution
Jordan_Thompson_FTNT

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

36 REPLIES 36
Magnitude_8

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

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

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

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
New Contributor

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
Contributor III

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

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
New Contributor

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
Contributor III

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
New Contributor

Sorry, of course to 6.2.4 (roll back)

Top Kudoed Authors