I'm running PanOS 5.0.11 on a 5060 and am looking at exporting netflow into SiLK. In the SiLK logs, I'm seeing thousands of messages that look like this:
Oct 9 09:37:43 hostname rwflowpack: IGNORED|18.104.22.168|22.214.171.124|33775|6917|6|0|0|no forward/reverse octets|
Digging a little further, I see that SiLK throws that error when the byte counts are zero. The SiLK source code indicates firewalls such as the ASA export flows like this for blocked connections.
In my case, they are not blocked connections, but legitimate and allowed ones. I can find the corresponding traffic (matching timestamp, source/dest IP, source/dest port, protocol) in the traffic logs on the device, except that the PaloAlto traffic logs report non-zero byte counts. It's not all the traffic being reported this way; there is still lots of good data being collected properly. Presently about 30-ish% of the flow records are not making it into the logs because of this.
I've verified via packet capture that the flows being received by SiLK on my collector box are indeed showing zero bytes, just to rule out SiLK.
Could this be a bug/issue? Is there some sort of rate-limiting or resource issue? (At the moment, probably generating 3500-4500 flows/sec).
Any help would be appreciated.
What is the Template Refreshed Rate configured as? Also can you put snapshot for the same traffic that is in your traffic logs and also in netflow? Do you have zone protection configured? UDP packets can have 0 bytes payload during regular scans such as nmaps. Also is it possible to change the service route from management interface to one of data plane ports for net flow and see if that makes any difference. Thank you.
At the moment, template refresh is set for 1 minute/600 packets. Zone protection is configured, however the problem is not limited to UDP packets. I see the same issue with TCP and ICMP packets as well. It's not happening during nmap scans, but with regular traffic. It happens with traffic going both directions, and zone protection is configured only on the external interface. The bulk of the issues relate to inbound traffic, but that could be just because the bulk of the traffic is inbound. It appears it happens to UDP much more often, and of the UDP traffic, it seems DNS traffic is most prominent. Those are just some casual observations though.
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!