FGT 100D - Upgrade to 5.4 from 5.2

[dcm2k]

Hi to all,

I am quite new to the FGT world. My Company bought a FGT 100D three months ago, that came with v. 5.2.4 installed. The GUI has shown the message about the update to 5.2.7, but nothing about 5.4. What do I need to update to 5.4? Do I need any support contract?

Thank you all.

[seadave · Accepted solution]

5.4 is a major upgrade and still considered to be unstable in some use cases.  I've been using it with moderate success on a 500D for three months but got hit by two bugs:

IPSec NPU offloading can cause a runaway process and requires a hard reboot.

-resolution is to disable npu offloading via the IPv4 policy for IPSec inbound.

Setting SSL/SSH DPI to "All Ports" kills the Proxyd after ~24 hours and requires hard reboot.

-resolution is to disable "all ports" in favor of the static 443, 22, etc. via the DPi options screen.

If the current build is working for you, I might suggest waiting until 5.4.3 or 5.4.4.  If you do upgrade, follow the upgrade guide in the 5.4 Admin Handbook.  Backup your config, setup a serial connection, and keep a local copy of the latest 5.2.X version you are running so that you can downgrade if the upgrade doesn't go well.

[ede_pfau]

hi,

in order to access firmware images legally, you need a customer account with Fortinet Support and a valid contract (FortiCare is sufficient for this).

Other than that you should read the Release Notes and follow the recommended upgrade steps - you might need intermediate upgrades. Please search the forums for this, keyword "upgrade matrix" or such. An upgrade is partially 'active' by running scripts to adopt previous settings to new syntax or settings, it's not only copying some software into the device.

And of course have a current backup of the config, and the firmware image of the now current version, in case you want to revert/downgrade.

[seadave · Accepted solution]

5.4 is a major upgrade and still considered to be unstable in some use cases.  I've been using it with moderate success on a 500D for three months but got hit by two bugs:

IPSec NPU offloading can cause a runaway process and requires a hard reboot.

-resolution is to disable npu offloading via the IPv4 policy for IPSec inbound.

Setting SSL/SSH DPI to "All Ports" kills the Proxyd after ~24 hours and requires hard reboot.

-resolution is to disable "all ports" in favor of the static 443, 22, etc. via the DPi options screen.

If the current build is working for you, I might suggest waiting until 5.4.3 or 5.4.4.  If you do upgrade, follow the upgrade guide in the 5.4 Admin Handbook.  Backup your config, setup a serial connection, and keep a local copy of the latest 5.2.X version you are running so that you can downgrade if the upgrade doesn't go well.

[tanr]

@seadave   Could you go into more detail about the 5.4 problem with IPSec NPU offloading?  

I've done a quick search of the forums but couldn't find any reference to the bug.  

If you have a bug number, that would be helpful.  And was it with 5.4.0 or 5.4.1?

I'm supposed to config a new 300D (5.4.1) as an IPSec hub next week, so would appreciate any warnings.

[seadave · Accepted solution]

I must have been dreaming about a post here, sorry.  Here was the situation.

I've been testing dialup IPSec with our FAC for 2FA for about a week.  Last Friday I was suddenly unable to reconnect after I came back to my MacAir running FortiClient 5.4.  I was on vacation so this was a problem.  I thought perhaps was a MacOS issue so I rebooted to no avail.  We still have a legacy PPTP connection, so I VPN'd in to that.  I thought, I must have some type of hung connection and tried to login to the FG GUI, no luck.  Login hung with no response.  Starting to get worried.  I try to open a SSH session using Putty, no response.  I then RDP'd into a laptop I keep connected to the FG serial port and I see the following messages repeating every few seconds.  I leave a Putty Serial session open to act as a console log.

unregister_netdevice: waiting for IPSec NAT_6 to become free. Usage count = 2 unregister_netdevice: waiting for IPSec NAT_3 to become free. Usage count = 4 unregister_netdevice: waiting for IPSec NAT_1 to become free. Usage count = 18 unregister_netdevice: waiting for IPSec NAT_6 to become free. Usage count = 2 unregister_netdevice: waiting for IPSec NAT_3 to become free. Usage count = 4 unregister_netdevice: waiting for IPSec NAT_1 to become free. Usage count = 18

Attempting to login via the serial console also does not work.  We have internal AD DNS, but all of a sudden DNS starts acting erratic because the firewall is slowly losing its mind.

Since 6/12 (when something changed FORTINET!!!) I've been fighting 5.4 bugs.  We had it running for three months before that without issue.  As a result of having two situations where the firewall locked up and I was not able to be onsite, I purchased a remote power reset.

http://3gstore.com/product/6081_2_outlet_ip_switch.html

Best $100 I've ever spent.  We have a backup connection so I connected the remote switch to it (I'm not brave enough to use the auto-reboot feature of this switch ).  THIS TIME I was able to simply login to the switch from my iPhone and power cycle the Fortigate.  Everything came back up fine.

I started searching the error and I came across this article:

https://forum.fortinet.com/tm.aspx?m=132310

So I modified the IPSec Policy rule as mentioned (disabled npu offload) and I have not had a problem since, with the result being that I'm losing the benefit of NPU efficiency.

The other problem we had started occurring on 6/12.  I'm guessing that something was updated by Fortinet as all of a sudden the firewall would enter conserve mode after a massive CPU/Mem spike.  Temporary solution was to enabled auto-restart at 03:45 each day which mostly alleviated the problem.  Final solution was to disable the option to "inspect all ports" for the SSL/SSH Deep Inspection Scanning profile.  Leaving the "inspect all ports" option enabled causes the proxyworker process to crash repeatedly.  Crashlog indicates we have not had the problem since we did that.

I want to move to 5.4.1 but might wait for 5.4.2.  Hopefully it won't take six months to see that release!!!

[tanr]

Ouch.  Thanks for the information.

I'll post in the old thread to see if anybody has tested it out with 5.4.1.  

If nobody has confirmed if the bug is fixed or not with 5.4.1 I'll try it out and see how it goes.

I've been looking at the remote power reset options.  One more thing to add to the to do list.

[seadave]

I must have done this wrong as I'm seeing the same "unregister_netdevice: waiting for FC_IPSec_0 to become free" errors on my hardwire console log.

Just did the following:

fg # show full | grep -f npu-offload  (this shows you were the command is located)

config vpn ipsec phase1-interface edit "FC_IPSec" (Name will differ by customer)

set npu-offload enable <---

next

end

Looks like I didn't disable the npu-offload on the phase1-int.  I just changed the setting but the darn error persists. Looks like reboot is needed.

[ecsupport]

Is there any confirm of this resolved in 5.4.2? With sooo many Resolved and Known issues, couldn't really tell. Besides 11/17 relnotes show two RESOLVED issues getting yanked back into known! Ay!

[abgilson]

Read the release notices, it will advise what versions you can jump, however if the FW is working properly and is still receiving updates to AV, IPS etc then I would leave it, as 5.2.9 is the latest, and from my experience we have 2x100d 2x60e 1x 140d and 2x1500d. From memory 5.2.4 on our 140d was issue free, only when I start chasing updates the fortinet required much more T&C, IPS engine issues, memory issues.. weil i am sure fortinet intent is to improve the product with each update, but they have some real issues with IPS memory and high cpu's on most models which would happily peak at reach 20%-35% CPU or 45%-55% memory utilisation , until 5.2.7 and beyond was introduced. keep scanning the blogs for information until you here about trouble free version which 5.2.4 was for me. 

[ecsupport]

5.24 has a rather horrible WAN2 (SSL VPN / HTTPS admin login) bug. We only run 5.23 and 5.26 now.