Troubleshooting Tip: How to troubleshoot the 'No Session Matched' error
Description
This article describes that the error 'No Session Matched' will appear in debug flow logs when there is no session in the session table for that packet. The session has been removed from FortiGate, so the traffic cannot be matched.
Possible reasons for this error are listed below.
Scope
FortiGate.
Solution
Scenario 1.
One possible reason for 'No Session Matched' is that the session was closed according to the 'tcp-halfclose-timer' before all data had been sent for that session.
id=13 trace_id=101 func=resolve_ip_tuple_fast line=4299 msg="vd-root received a packet(proto=6, 172.16.189.1:63620->172.16.199.100:8888) from lan."
id=13 trace_id=101 func=vf_ip4_route_input line=1603 msg="find a route: gw-172.16.199.100 via lan"
id=13 trace_id=101 func=fw_forward_dirty_handler line=309 msg="no session matched"
tcp-halfclose-timer:
These settings define how many seconds the FortiGate unit should wait to close a session after one peer has sent a FIN packet but the other has not responded.
The valid range is from 1 to 86400 seconds.
By default in FortiOS, tcp-halfclose-timer is 120 seconds.
This option can be configured at the global level or the firewall service:
config system global
set tcp-halfclose-timer <integer>
Steps on how to extend the TCP half-close timer for port 8888. This is the ports observed in the logs above.
- Create a custom firewall service for TCP port 8888. Set the expected tcp-halfclose-timer for the new custom service.
config firewall service custom
edit "TCP-8888"
set tcp-portrange 8888
set tcp-halfclose-timer 3600
next
end
-
Use this custom service in all relevant policies:
config firewall policy
edit 55
set srcintf "lan"
set dstintf "port7"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "TCP-8888"
set logtraffic all
next
end
The tcp-halfclose-timer will be applied to the session and therefore applied regardless of which end initiates the half-close.
Note:
The TCP half-close timer can be changed for other ports on the FortiGate as well. For example, below, it is possible to find the configuration change for the HTTPS service:
config firewall service custom
edit "HTTPS"
set tcp-portrange 443
set tcp-halfclose-timer 3600
next
end
This service can be added to the right firewall policies as per user requirements.
Scenario 2.
Another possible reason is asymmetric traffic, where the FortiGate does not receive a SYN packet, resulting in the firewall blocking those packets due to the absence of a matching session.
Scenario 3.
In a sniffer captured with the destination as a filter, it is observed:
--need to frag(mtu1450)
Change the value of 'set tcp-mss-sender' and 'set tcp-mss-receiver'.
config firewall policy
edit x
set tcp-mss-sender 1200
set tcp-mss-receiver 1200
end
This value can differ depending on the network infrastructure.
For considerations regarding changes to MSS behavior and values, refer to the notes in the article Technical Tip: Setting TCP MSS Value.
Scenario 4: Session previously cleared by an administrator.
If a session was manually removed (e.g., using diagnose sys session clear, or cleared via the GUI), subsequent packets for that flow will hit no session matched because no active session exists.
Scenario 5: Session removed by a user logout event.
When a user logs out, related sessions are deleted from the firewall session table. Packets arriving after this logout-triggered removal will have no session context and be dropped.
Scenario 6: Packet arrives after session timeout.
FortiGate removes sessions when the configured timeout expires. If a packet arrives after the session has aged out, it will not match any existing session and trigger no session matched.
Scenario 7: Rapid TCP session reuse.
The client reuse the same source/destination/ports very quickly (under 0.5 seconds) - the FortiGate finds no matching active connection and discards the packets.
Scenario 8: Packet received after route change causing interface mismatch.
If a session is initially established with a specific ingress and egress interface (e.g. port1 -> port2) and a routing change occurs mid-session (e.g. egress changes to port3), subsequent packets arriving on the old path (port2) will not match the existing session. This is because the session lookup includes interface information, leading to a 'no session matched' drop.
Example:
A session is created for traffic flowing from port1 to port2. After a route update, the new egress interface becomes port3. If return traffic is still received on port2, it will not match the existing session due to the interface mismatch.
Solution:
Enable auxiliary session under system settings:
config system settings
set auxiliary-session enable
end
Related articles: