Blaming the firewall is a time-honored technique practiced by users, IT managers, and sysadmins alike. As network engineers we could point out that solar flares are as likely a cause of the [insert issue of the day] as the firewall, but honestly, if they can’t see that the software updates they just did are likely the true reason the thing that wasn’t broken now is, chances are you aren’t going to convince them the firewall isn’t actively plotting against them.
My most successful strategy has been to take up residence in Wireshark Land, where the packets don’t lie and blame-storming takes a back burner. Recently, for example, I took captures on two Linux servers, one a web server in the DMZ, and one a database server on the internal network. The captures showed that the web server could initially reach the database server, but that communications broke down after a few minutes. The database server clearly didn’t get the last of the web server’s packets.
Realizing there may actually be something to the “it’s the firewall” claim, I turned to the CLI of the firewall to see if the packets were even getting to the firewall interface and then out the other side. If you haven’t done this in the Fortigate world, it looks something like this, where port2 is my DMZ port:
My_Fortigate1 (MY_INET) # diag sniffer packet port2 ‘host 10.10.X.X’
interfaces=[port2]
filters=[host 10.10.X.X]
1.753661 10.10.X.X.33619 -> 10.10.X.X.5101: fin 669887546 ack 82545707
2.470412 10.10.X.X.33617 -> 10.10.X.X.5101: fin 990903181 ack 1556689010
I ran a similar sniffer session to confirm that the database server wasn’t seeing the traffic in question on the trust side of the network. Sure enough, a few minutes after initially establishing communications, packets making it from the web server to the DMZ side of the firewall, quit making their way to the trust side of the firewall, not even getting a chance to talk the database server. The traffic log from the FortiAnalyzer showed the packets being denied for reason code “No session matched.” Fabulous.
Thinking it looked to be a session timer of some kind, I examined the Fortigate policies from the GUI admin page, but couldn’t find anything labeled “hey dummy, here’s the setting that’s timing out your sessions.” That’s because the setting I was looking for is apparently only seen in the CLI.*
The CLI showed the full policy (output abbreviated), including the set session-ttl:
My_Fortigate1 (My_INET) # config firewall policy
My_Fortigate1 (policy) # edit 50
My_Fortigate1 (50) # show full
config firewall policy
edit 50
set srcintf “port2”
set dstintf “port1”
set srcaddr “MY WEBSERVER”
set dstaddr “10.10.X.X” “Servers_10.10.X.X/32”
set rtp-nat disable
set action accept
set status enable
set session-ttl 0
A session-ttl of 0 says “use the default” which in my case was 300 seconds. I was able to up this just for the policy in question using these commands:
My_Fortigate1 (My_INET) # config firewall policy
My_Fortigate1 (policy) # edit 50
My_Fortigate1 (50) # set session-ttl 3900
My_Fortigate1 (50) # end
This gave the application we were dealing with in this instance enough time to gracefully end sessions before the firewall so rudely cut them off and also managed to keep my database guy from bugging me anymore (that day).
*If this is in the GUI, I certainly do not possess patience levels high enough to take the time to find it, but feel free to point me to its location in the comments.
Published 2/4/2014
Amy Engineer 
I recently took both the Fortigate 201 and 301 courses towards certification. There is a LOT that you have to do in the CLI that simply doesn’t exist in the GUI. Even turning on some logging features can only be done via CLI.
The built in debug and packet trace options are fairly cool though.
I’m noticing that, cool that there is so much you can do, I just need to get more familiar with all the features and commands! I should look into the classes as well…
I too liked the debug and packet trace features in the Fortigate. It gives you exactly what you want to see without looking out for hidden codes and numbers. 🙂
Definitely cool! Has to be one of my favorite features for sure!
There is alot of the IPv6 configuration only in the CLI in ver 4.x of FortiOS. There is more IPv6 in the GUI in ver 5.x FortiOS, but still some only in CLI (DHCPv6 services for example).
With all that said, my limited research shows the FortiNet has more and better IPv6 support than most others in the mid-large SMB firewall space….interesting unto itself.
Thanks for posting this. It was the only thing I could find on this error. Definitely appears to be timeout issues with the application. It waits for a while and then tries to re-send traffic on the port after the firewall has cleared the session, firewall doesn’t see the 3-way handshake so it blocks it. Would be nice if FortiNet had this message documented somewhere.
I haven’t used the packet trace tool as it is recent with v4mr3p15 i have still be using the perl script conversion to get a pcap from the debug output…
that being said, i much rather have a simple excel of the top 100 errors and not reasons for why it happens but a definition for example replay packet(allow_err) drop to fortinet means …
Amy do you use the FortiManager too?
I haven’t used FortiManager at all. Have used FortiAnalyzer though, can be helpful.
On v4.3, the session-ttl is in GUI. Double click the policy you want to edit, scroll down to Advanced Options section at the bottom of the pop-out window, scroll down to the bottom again and you will be able to edit session-ttl among other options for the policy.
Awesome! Did the upgrade to 5.x and haven’t checked yet, but nice to know it’s in the GUI with later versions!
Hi Megan,
There is no option in the GUI to change session-ttl….if you double click the policy it brings you to the “edit policy” page and no session-ttl settings are there…am I looking in the wrong place?
via the GUI. if you double click the rule at the end is advanced option. Session-ttl is set to 0 and can be changed there.
I’m using a FG-50B (v4.0,build0689,140731 (MR3 Patch 18) and there’s no advanced options to change the TTL.
It felt good to read your post…
However fortigate has been a pain to me.. Not the troubleshooting part… That’s fairly good…
But its Configuring the policies that’s taking a toll on me… The feature add a policy below or above… Just keeps malfunctioning… I feel soo annoyed…
It can definitely be quirky, but I’ve really come to like the ones we have from a reliability perspective. I wish I knew the CLI better, though, would offset some of the funky GUI experiences. Not enough hours in the day to learn all the things!