Do you have Any AV or threat scanning enabled on this rule? Also are you doing Decryption? Have you checked for URL filtering as well?
Some traffic does not handling being scanned, or decrypted well, also I recomend checking the URL filtering logs, just to be sure.
Agree with @BPryBPry, we need to more information from the logs. Biggest question from me is are you seeing returned traffic. Most of the time "aged-out" means you're not getting anything back.
Here is more detail. Not sure it helps though. I coulnd't upload the photo for some reason https://drive.google.com/file/d/0B3Jizok7n9kIWENkcjg3clExV2s/view?usp=sharing
Can you run a capture either on the firewall or the end client, the fact you have 1 sent packet and 5 received is weird, if both the source and destination are fully accessible for the TCP stream.
As you have Wifi in the rule name I would possible believe that inside device has connectivity issues and the destination is doing retransmits, thats why we're seeing more packets on the recieved end.
Can you get a wireshark capture? or run one on the firewall?
I've looked at your PCAPs and detailed log view.
The traffic is being sourced from VLAN 403 but return traffic (the SYN ACK) is being sent down to VLAN 400 (so down a different sub interface) You can see this by checking the 802.1Q tag in the PCAP. I suspect that this is being dropped by a device between the firewall and the server or the server due to this.
Its worth checking your policy based forwarding rule if you have any and/or routing.
hope this helps,
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!