Suggested Steps for Investigating Flows

When drilling into specific flows when examining policy results, the following suggestions and filters may be helpful:

1. Focus on ESCAPED FLOWS initially:

   Escaped flows require special attention as their actual flow dispositions differ from the intended actions based on the currently analyzed policies. Investigate to ensure that enforcing these policies does not block needed flows and adversely impact your applications.

   Click the violation type, such as Escaped.

   (Later, you can look at rejected and permitted flows as needed.)

   Escaped flows can occur for many reasons, including but not limited to:

   • Another policy higher in the priority order is taking effect

   • The traffic is taking a different path than the route that your policies address, or

   • The policy that you expect the traffic to hit is in a workspace that is not being analyzed (if you are looking at escaped flows on the Policy Analysis page) or enforced (if you are looking at escaped flows on the Enforcement page), for example in an ancestor scope or even in a secondary workspace in the same scope.

2. Identify flows that matched the catch-all policy (inbound and outbound) :

   It is important to understand what flows are matched to catch-all policies, especially in an allow-list policy model. If these flows are legitimate but do not have explicit allow policies configured for them, you may want to add appropriate explicit policies in the corresponding inbound or outbound scopes. If they are suspicious flows, you want to quickly identify them and further investigate their details.

   To focus on these flows, apply filters based on the catch-all value of inbound_policy_rank or out- bound_policy_rank, depending whether you are looking at the inbound, outbound or both sides, shown below.

   

3. Filter out TCP flows with RST: Fwd flags do not contain RST, Rev flags do not contain RST

   Some escaped TCP flows have RST flags set. These flows are reset by either their consumers or providers. They are unestablished connections without data exchange, but may be reported as ALLOWED because the agents see their handshaking packets. Since they do not have established connections to begin with, they will not be affected when currently analyzed policies are enforced. Filtering out TCP flows that have the RST flag on either side allows you to focus on more meaningful and important escaped flows whose established connection will be blocked by the currently analyzed policies.

4. If most traffic is using IPv4, focus only on IPv4 flows:

   Filter using address type = IPv4, address type != IPv6. It is also helpful to filter out link-local address.

5. Prioritize which flows to focus on in the next diagnostic step by identifying the most frequent hostnames, ports, addresses, scopes, and so on involved in the escaped traffic:

   Select Hostname, Ports, or Addresses from the TopN feature pane. You can usually combine these with other filters to drill down to a particular type of traffic when diagnosing policies.

6. Search flow data for the hostnames, ports, protocols, etc. identified in the previous step

   Once you have an idea about the top candidates based on the targeted flows' hostnames, port and and so on, you can choose to drill down into the flows by either applying drill-down filters directly from values given in the top N query window, or by manually entering relevant filters into the flow search filters bar. For example, Consumer Hostname contains {something}, Provider Hostname contains {something}, Provider Port = {some port number}, Protocol = TCP Protocol != ICMP

7. Check individual flows and quick analysis:

   Finally, you can focus on a specific flow to examine its policy result by clicking the table row corresponding to the flow. Pay attention to the policies matched to the flow and the scopes of both the consumer and the provider addresses. If the policy action does not match your intended action, you need to create appropriate policies in workspaces associated with the consumer’s and/or the provider’s scopes to change the policy action.

   The figure below shows an example workflow of narrowing down escaped flows using some of the filtering described above. The search input also supports “,” and “-” for Port, Consumer Address and Provider Address, by translating “-” into range queries.