" no session matched" message

[JPM]

Hi, I am hoping someone can help me. We get a " no session matched" (log_id=0038000007) message several thousand times a day for various different connections on our Fortigate 310B (4.0 MR3 patch 9) I believe this is caused by the anti replay setting which we could disable but I wanted to ask if it is safe to disable this setting or if there is some other setting which could be causing this message to be logged so many times per day. We also receive the message " replay packet(allow_err), drop" (log_id=0038000007) several thousand times a day which appears to be related to the same issue. If anyone can help with this I would appreciate it. Regards, JP

[hklb]

Hi, Did you check if you have no asymmetric routing ?

[JPM]

Hi hklb, Thanks for the reply. No most of these connections are dropped between 2 directly connected network segments (via the Fortigate) so there is only a single route available between the segments. JP

[ede_pfau]

Looks like a loop to me. If you assume that the messages are correct then you do have a massive problem on your network. I' d check that first, probably using the built-in sniffer (diag sniffer packet...). Which ' anti-replay' setting are you refering to? I only know this from IPsec which you probably will not use on your LAN. Maybe you could update the FOS to 4.3.17, just to make sure...4.3.9 is quite old. Still, my first suspicion would be ' network problem' .

[JPM]

The anti-replay setting is set by running the following command: #config system global #set anti-replay (strict|loose|disable) #end When you say loop, do you mean that there is more than 1 route to a specific host? JP

[JPM]

On looking at the logs further I can see that for each of the dropped connections the outbound interface is ' unknown-0' . Would this also indicate a routing issue? Does this help troubleshoot the issue in any way?

[lightmoon1992]

what is the destination for that traffic? this could be routing info missing

[emnoc]

The diag debug flow command would be your friend and probably would give you better direction. Also make sure you have no PBR policies or if you do make sure these policy routes are correct.

[netmin]

Totally agree...try to determine source and target, applications used, think about long running idle sessions (session-ttl). For example, others (just consult your favourite search engine) observed this issue between webservers and database servers, with idle rdp sessions or caused by improper vlan tagging.

[JPM]

Hi All, Thanks for all your responses, I feel like I am making some progress here. Most of the dropped traffic is to and from 1 IP address although there are other dropped packets not relating to this IP. I ran the following commands and captured the output which I have attached to the post (IP addresses have been changed) diagnose debug enable diagnose debug flow show console enable diagnose debug flow filter add 192.168.9.61 diagnose debug flow trace start 10000 I have looked through the output but I cannot see anything unusual. We do not have any PBR in place and the routes between these networks are in place as they are all directly connected to the Fortigate. Thanks again for your help. JP