If there’s one thing I like to do, it’s leave SSH sessions open to all my frequently accessed systems.  If there’s one thing I hate, it’s finding them disconnected when I least expect it.  I recently swapped out my trusty Cisco 1811 router for a Fortigate 30D because I wanted to do access controls on 6in4 tunneled IPv6 packets and AES256/SHA256 VPN tunnels.

First thing I noticed before even really getting any of that set up is that my ssh sessions kept dropping.  Turns out Fortigates have a default setting of five minute TTL’s for TCP sessions; active sessions that have no packet movement simply get dropped.

That parameter cannot be adjusted via the web interface, you have to use the CLI.  You have three options; you can adjust the default timeout for everything.  To make it one day, for example:

config system session-ttl
    set default 86400
end

That’s a less than ideal solution though because abruptly ended sessions (server crashed, upstream issue, browser crashed, streaming media, so on and so forth) will stick around consuming memory on the firewall for a day. So, instead, you can adjust just port 22 for SSH. Here’s an example of how to do that, along with a default of ten minutes for everything else:

config system session-ttl
    set default 600
        config port
            edit 22
                set protocol 6
                set timeout 86400
                set end-port 22
                set start-port 22
            next
        end
end

The “22” after the edit simply means the rule number; it has nothing to do with the port which is set within the rule as a range. The protocol is 6 for TCP. This is probably the best and easiest option.

The third way of doing this is adjusting the TTL on a rule basis. So you’d create a rule allowing you and whomever else to connect to wherever you want, permit ssh and then get into the CLI and find the rule within the “config firewall policy” section. The only real reason to do this is if you want to extend the TTL on a specific service for only specific people; otherwise, no reason to waste memory and processing time by having an additional rule in your policy. The updated rule will look like this (remember, the edit 4 is arbitrary, you have to find the right rule on your firewall):

    edit 4
        set srcintf "lan4"
        set dstintf "wan"
        set srcaddr "my-computer"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "SSH"
        set logtraffic disable
        set nat enable
        set session-ttl 86400
    next 

If we’re talking SSH specifically, there are of course other ways to deal with this by enabling keepalives on the server side, or perhaps the client side if your client supports it. Here’s a good article on that, including the useful ClientAliveInterval variable:

http://nodsw.com/blog/leeland/2011/09/23-keeping-ssh-sessions-alive-nats-firewalls