How to reduce TTL sessions ?

[#1]

Hello, On a fortigate 310b (3.0 mr7), I am trying to reduce the ttl session timeout. But I can' t set it under 300s. What i am doing : #config system session-ttl # config port #edit 53 # set timeout 100 The value must be between 300 and 604800 node_check_object fail! for timeout 100 value parse error before ' 100' Command fail. Return code -2 Any ideas ? 300s is way to much for a dns session :(

[Carl_Wallmark]

300 is the lowest you can go for session TTL

[#3]

Thanks for the quick answer. Is the lowest still 300s for newer fortigate ?

[FortiRack_Eric]

You' re looking at the TCP timers. Giving port 53 you want to eliminate the pseudo for sessions for DNS sessions. This is configured as follows: config system global set udp-idle-timer 30 end udp idle timeout: 1-86400s, default 180s Cheers Eric

[ede_pfau]

Bear in mind that this affects all UDP traffic, including NTP, IPSec/IKE, streaming. I agree that the majority of idling sessions often is UDP DNS because resolving is pretty fast. Session setup and tear-down is ressource costly, though. What exactly is wrong with a TTL of 300s? Do you feel the number of sessions is too high on your FG? About what numbers are we talking here?

[ede_pfau]

just curious, this is what I can do in v4.00:

 config system session-ttl
     set default 3600     # good to know...
     edit 0 # 0==next available
         set protocol 17   # 6=tcp, 17=udp
         set timeout 90   #  in seconds
         set end-port 53  # for tcp and udp only
         set start-port 53
     end
 ...        
 

This gives you a lot more options.

[#7]

Thanks for your answer. I am talking about 30k udp (no vpn, mainly dns) sessions over 120k. So setting a timer of 90s, may lead to a reduction of 10% of sessions. Do you know how the firewall handles the session ? Each seconds, it checks its tables and to some cleaning ? So I guess, the smaller the table is, the faster it will be to process this timer, no ? I don' t see how changing idling sessions timer may increase cpu ressources :(

[ede_pfau]

Just a quick thought on how the number of idling sessions is calculated... I think it depends on the rate of new sessions per second. Let' s look at the equilibrium state, i.e. the table size is constant (more or less). If you have a rate of 100 new sessions/sec, and wait for 300 seconds, then you have 30k sessions in the table. From the next second on, 100 sessions are timing out each second - the rates of new sessions and deleted sessions must be equal or else the table size would grow/shrink. So if you change the lifetime of this kind of session from 300 to 90 seconds, you should end up at an equilibrium of 9k sessions. Which is 70% less. If you have 120k sessions in all before, you' ll have 99k sessions after, a reduction of 17.5%. Please give me an idea if this is all wrong, and what the real reduction looks like in a couple of minutes. Back to your questions. When the firewall records a new session it has to allocate memory for it, write the table entry, start a session timer (it won' t go through all session entries sequentially - not scaleable), and probably some more effort. All of this is handled by the CPU. If you have sessions that are used only once (like NTP) during their lifetime, shorter lifetime means less CPU handling the session timers. But if sessions could be reused, like DNS when you load a web page with multiple requests, but have expired already, the FG would have to create more sessions than before, increasing CPU load. I' ve been told once by a Fortinet SE that you could choke a firewall by a high rate of new sessions. I' ve seen 500 sessions opened by a single user on regular web traffic. So with enough users I can imagine you could really load a Fortigate if the session lifetime was really short (not with 90s).

[#9]

I will update this post as soon as I get some numbers. sessions, cpu & co :)