Monday, December 31, 2012

fortigate Session Timeouts

The Fortinet platform like most other stateful firewalls keeps track of open TCP connections. Each established session is assigned a timer which gets reset every time there is activity. If the timer expires due to inactivity the session is removed from the firewall tables and you will have to re-establish the connection. The session can also be cleared without waiting for the timer to expire if the firewall sees a FIN or RST packet for a given session.

Imagine you have a telnet connection on port 23 to a server in your DMZ. There is a script which executes periodically to poll some data using the telnet session. You notice that when the script hasn't executed in 60 minutes the telnet session is lost and you have to re-establish the session.

The easy answer is to increase the session ttl (time-to-live or timeout). This can be done on the CLI on a global basis for all ports or only for specific ports. Keep in mind that raising the timeout values for all ports can significantly increase the amount of system resources (especially RAM) consumed. This is due to the fact that the firewall now has to potentially keep track of the same number of sessions for a longer period of time. The default value of 60 minutes/3600 seconds should be ok for most applications.

The following example sets the timeout value for all TCP services to 3000 seconds but increases the timeout for telnet (port 23) to 7200 seconds.

config system session-ttl
set default 3000
config port
edit 23
set timeout 7200
next
end
end

fortigate Web URL Filtering does not block Websites

If you have defined a Web URL filter for blocking certain web sites but simply can't seem to get it to work (i.e. you can still access the websites you want to block) try restarting the HTTP proxy. On the CLI enter the following command:

diag test application http 99

High CPU usage Problem Fortigate

CLI commands you can issue to try and correct the problem in the short term.

# diag test application ipsmonitor 
 
IPS Engine Test Usage: (Values for >
1: Display IPS engine information
2: Toggle IPS engine enable/disable status
3: Display restart log
4: Clear restart log
5: Toggle bypass status
6: Submit attack characteristics now
97: Start all IPS engines
98: Stop all IPS engines
99: Restart all IPS engines and monitor


The most common command that we issue to deal with the IPS Engine running high is the following which restarts the IPS process:

# diag test application ipsmonitor 99