- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-12-2017 05:15 AM
Hi,
Why is this happening? Policy recognises the request, but it doesn't work. User is trying to up stream audio over port 8305
Thanks.
09-12-2017 05:36 AM
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.
09-12-2017 09:01 AM
Hitting the magnifying glass on the left of those logs will give you some additional insight; but check your logs as @Kaje mentioned and see if you can find anything that would be stopping the traffic. Without some additional information age_out responses aren't that informative.
09-13-2017 03:15 AM
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.
09-15-2017 01:45 AM
Hi. No, we're not doing any of that.
09-15-2017 03:13 AM
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
09-15-2017 06:40 AM
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?
09-20-2017 04:15 AM
Hi,
I have uploaded the packet captures from the PA to here https://drive.google.com/open?id=0B3Jizok7n9kIUmRfMzczY2JqcnM
Thanks.
09-22-2017 03:48 AM
Does anybody have any ideas?
09-22-2017 04:04 AM
Hi Mark,
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,
Ben
10-03-2017 04:04 AM
Thanks for this. I am investigating a way round this.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!