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

FGT 100D - Upgrade to 5.4 from 5.2

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.

2 Solutions
seadave

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.

View solution in original post

seadave
Contributor III

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!!!

View solution in original post

10 REPLIES 10
tanr
Valued Contributor II

Has anybody verified if the bug seadave ran into with IPSec VPN npu-offload has been fixed in 5.4.4?

 

I haven't been able to find any direct mention of it in the release notes.

 

Maybe this reference in the FortiOS Handbook - What's New Version 5.4.4 is a workaround?

 

 

  Configure the number of IPsec engines NP6 processors use (370586)

  config system npu

    set ipsec-dec-subengine-mask <engine-mask>     set ipsec-enc-subengine-mask <engine-mask>   end

 

Labels
Top Kudoed Authors