Troubleshooting Tip: Connection is denied even if it has the 'all to all' allow policy rule

[yangw]

Description	This article describes that the policy rule 'all source ip/service to all' has been created for the outbound traffic flow but the deny log is still recorded in the forward traffic log.
Scope	FortiGate v7.0.
Solution	In the forward traffic log below, found the deny log caused by 'no session matched'. The commands below could look into the session table records. Filter-related IP address and service port: diagnose sys session filter src 10.165.10.229 <----- The related source IP address for the outbound traffic flow. diagnose sys session port 25  <----- The related service port number in the traffic flow. In this case, there is no session has been established in the table: diagnose sys session list total session 0    <-----  Result. Capturing packet for further investigation packet flow details: diagnose sniffer packet any 'host 10.165.10.229 and port 25' 4 0 l <----- Filter by the source IP address and service port interfaces=[any] filters=[host 10.65.1.29 and port 25] 2024-01-08 10:50:13.313209 port2 in 10.165.10.229.57360 -> 142.250.157.26.25: rst 3249793968 ack 1677881727 ^C 1 packets received by filter 0 packets dropped by kernel In the packet flow, the TCP three-way-hand-shaking first packet SYN has never been received but the RST/ACK packet yes. This means that in an asymmetric environment if the FortiGate does not receive an SYN packet, it will not establish a session and allow it even if the policy rule has been created.