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

FGT 90D ips process keeps coming on and traffic load doubt

Hi people,


I have a fgt90d with os 5.2.3 setup for an office of upto 100 users. I created an IPS profile for client windows and linux machines and applied to all traffic for the internet. Also AV and app control and webfiltering is on with cert-inspection.


The very next day we started facing problems of the cpu usage shooting to 90-100% and so ips was disabled completely from the config>features menu but still i keep seeing the ipsengine process on diag sys top.


It shuts down only after i kill it with diag test application ipsmonitor 98.


Also how can one figure out if the fgt90D is enough for the traffic load its facing, i keep seeing up to 4k sessions and 11-20 sessions per sec.

Esteemed Contributor III



you're talking about IPS load and not IPsec (pls edit your post; there's nothing wrong with using proper case).

Disabling the WebGUI feature won't touch the IPS process, as enabling it will not "magically" enforce IPS on your traffic. Edit your policy/policies and disable the IPS sensor applied to it.


Independly of the hardware in use you can always configure IPS such that the CPU will hit 100% load.


That is to say: select IPS signatures that you really intend to use and not whole categories. Filter the list down as much as you can: level=critical, OS=Windows, vendor=Adobe,... Scanning for 4.000 signatures on a busy policy will lead to CPU congestion, especially with AV and AppControl to top it up.


As for # of sessions and session setup rate, I'd say the 90D is sufficient. It will surely depend on the throughput / bandwidth across the FGT.


Do you happen to have an PPPoE WAN connection? Will take a toll as well as it seems that PPPoE is handled by CPU.


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"



Shouldn't disabling the IPS in config features disable it at the process level and in the policies both? As it takes out the IPS option from the policies itself.


The fortigate doc on IPS config simply says to activate it by choosing the client option with the os and leave the rest to default.


Also is it recommended to use IPS for normal desktop user machines or use it only for servers?  The doc says it dismantles dos type attacks, something user PCs would rarely face i guess.


I don't have a wan pppoe, using static ips for both the wans.


The fortigate handbook simply says to choose the OS and severity for IPS and leave the rest to defaults. It recommends this for SMBs though.


My client has a FGT-90D with upto 100 users.


Also should i even be worried about IPS on normal client machines? What exact threats will IPS help in mitigating?


Will IPS dismantle connections like a worm, virus on the network trying to download more worms on to the network? What else can it work with?


Sorry if the questions just sound really noobish, IPS technology is really confusing as of now. Would really appreciate if anyone could point out good reading material on it.


HI fortiguys,


Bumping this thread up because im really not getting any help from the tac on this.


the cpu use keeps hovering in the 70% range and hits 100% at times when im looking at it. We're not facing any issues though but is this normal?


I have followed many optimization steps as recommended by tac, but none are helping.


Also i have 2 LAN networks  - one wlan and another lan and both are intercommunicating too, so all that traffic passes from fortigate. Will this add to the cpu use?


Thanks and Regards.

Esteemed Contributor III

To (temporarily) disable IPS,

- enable IPS in the GUI/Features

- uncheck the IPS box in policies


Disabling the GUI feature for IPS will not change policies! You just won't be able to change IPS settings in the GUI. The config will still be there and active - check it out in the Console window ("conf firewall policy").


As I already stated, create your own IPS sensors by picking up signatures or categories which you know will match your clients' traffic. There is no point in examining client traffic with server IPS signatures. Personally, I do enable IPS for clients because of the bunch of software flaws in Adobe software (Flash, Reader). Also, IE should be protected as well (against buffer overruns etc.).


If not already done, create policies for clients and for your servers to be able to shape your protection accordingly.


For servers, it depends on the services they offer. With web servers, guard against cross-site scripting, and, if applicable, SQL injection. You see it really depends on your situation.

The worst scenario would be to just enable the "client" and "server" categories and leave it at default (i.e., some attacks are blocked and some only logged). Your FGT will easily be overloaded if traffic rises.


I think that most of this is well documented in the Handbook. More advice is given here in the forums.


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"

Thanks a ton for clearing that doubt ede. I checked in the cli and yes the IPS was still visible even with it being disabled in the features menu. The TAC's response was that won't be a problem.


For now I have disabled IPS from all policies and also don't have any public servers except for the AD domains.


TAC also suggests I don't need the IPS for client machines and it's only recommended for public facing servers.

Esteemed Contributor III

...and is the CPU index down now?


For the better part of last year I've configured IPS for client hosts as well. Currently, attacks concern mostly Flash, IE buffer overruns and SSL heartbleed vulnerabilities. These are so common that I felt I'd better protect my clients before having to clean their machines...

If you don't have any internet-facing servers then you don't need IPS for them at all. One more reason to split server and client traffic into separate policies.


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Top Kudoed Authors