Technical Tip: FortiGate does not Generate Traffic Logs for Established or Denied TCP Sessions Lacking Application Data

[ssanga]

Description	This article describes an issue where FortiGate, with Central SNAT enabled, does not generate traffic logs for TCP sessions that are either established or denied and lack application data.
Scope	FortiGate v7.2, v7.4, v7.6.0.
Solution	When traffic matches multiple security policies, FortiGate's IPS engine ignores the wildcard security policy, as other potential matches are still under consideration, awaiting additional traffic to detect the application and make a decision.  If only the 3-way handshake messages are present and no further traffic is observed, the IPS engine defers its decision-making process, resulting in no log being generated. Sample config: config firewall security-policy     edit 185         set name "Bittorrent"         sset srcintf "any"         set dstintf "any"         set srcaddr "all"         set dstaddr "all"         set enforce-default-app-port disable         set service "ALL"         set schedule "always"         set logtraffic all         set application 6     next     edit 51         set name "outside"         set srcintf "outside"         set dstintf "any"         set srcaddr "all"         set dstaddr "all"         set enforce-default-app-port disable         set service "ALL"         set schedule "always"         set logtraffic all     next end PME debugs: diagnose ips filter set "host <sourceIP> and port <portnumber>" diagnose ips pme debug enable diag ips pme detail all diagnose debug enable Scenario 1: When FortiGate receives only the TCP three-way handshake packets without any application data, ngfwid is shown as 'n/a' in the session list output and no log is generated by FortiGate.  PME[31984779/0] session was created PME[31984779/0] PME features: 00000000+00000004-00008d63=00000004 PME[31984779/0] policies 3 { 01 : 185 Bittorrent 03 : 51 outside } PME[31984779/0] match: app=none url=-1 UNKNOWN PME[31984779/0] matching policy "Bittorrent" PME[31984779/0] ...matching apps PME[31984779/0] ...no app, keep the policy, ignore wildcards PME[31984779/0] matching policy "outside" PME[31984779/0] ...matching apps PME[31984779/0] ...wildcard matches, but ought to be ignored  <-- IPS engine ignores the security policy 51 since it is a wildcard match and not an explicit match. PME[31984779/0] PACKET END size=0 prolog=0 next_force_eval=0 PME[31984779/0] PACKET END size=0 prolog=0 next_force_eval=0 hook=pre dir=org act=dnat 172.17.96.151:59194->10.9.32.18:9999(10.193.29.254:9999) hook=post dir=reply act=snat 10.193.29.254:9999->172.17.96.151:59194(10.9.32.18:9999) hook=post dir=org act=noop 172.17.96.151:59194->10.193.29.254:9999(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=3 pol_uuid_idx=22401 auth_info=0 chk_client_info=0 vd=0 serial=00007103 tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id=00000000 ngfwid=n/a   --> ngfwid is shown as n/a. However, when the application is identified as SSL through PSH, ACK packets after the TCP three-way handshake, the ngfwid is updated to 51, with an action of block, and a log entry is recorded under Forward Traffic Logs. hook=pre dir=org act=dnat 172.17.96.151:5955->10.9.32.18:9999(10.193.29.254:9999) hook=post dir=reply act=snat 10.193.29.254:9999->172.17.96.151:5955(10.9.32.18:9999) hook=post dir=org act=noop 172.17.96.151:5955->10.193.29.254:9999(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=3 pol_uuid_idx=22401 auth_info=0 chk_client_info=0 vd=0 serial=00007335 tos=ff/ff app_list=0 app=15893 url_cat=0 rpdb_link_id=00000000 ngfwid=51  --> ngfwid is shown as 51. Scenario 2: When traffic explicitly matches only policy ID 51 when the destination interface is set to 'outside' in security policy 185, a policy match decision is taken and as a result, traffic is denied and a log entry is seen under Forward traffic logs. PME debugs for reference: PME[32540689/0] session was created PME[32540689/0] policies 1 { 01 : 51 outside } PME[32540689/0] match: app=none url=-1 UNKNOWN PME[32540689/0] matching policy "outside" PME[32540689/0] ...matching apps PME[32540689/0] ...explicit match   <-- Explicit Match. PME[32540689/0] ...matching actions PME[32540689/0] [EXPLICIT DROP_SESSION] outside : url=-1 PME[32540689/0] ...trigger policy 51 outside PME[32540689/0] [DECISION MADE] DROP_SESSION view=207 policy=51 features={p:0 s:0} PME[32540689/0] policy=51 action=5 log_traffic=1 isdb_src/dst=0/0 Starting from IPSE versions 7.4.6:0553, and 7.6.1:1017, security policy match timeout can be configured using the following commands to generate a log that lacks application data. config system ngfw-settings     set match-timeout <>     set tcp-halfopen-match-timeout <>     set tcp-match-timeout <> end For more information, visit config system ngfw-settings. Workaround: Ensure traffic is an explicit match with wildcard policy to deny and log the session.