Traffic change/recertification requests validation
This topic gives a closer look into traffic change/recertification requests validation results.
Change validation results
Note: If traffic is not routed through the device, validation will pass.
Traffic change/recertification requests validation results are presented in the following sections:
General for all traffic lines
General validation status
The general validation status appears at the top right of the sub request screen. It summarizes the validation results of all traffic lines in the sub request:
- ü Validation succeeded for validation success of all traffic lines.
- X Validation Failed for validation failure on any traffic line.
Objects validation
The objects validation section validates that every network object/group and service object/group, that were recommended to be created in the work order recommendation were created correctly.
-
ü New object validation successful.
ü New objects were created successfully.
-
X New objects validation failed.
X There are objects that have not been defined correctly.
In order to see details per object, click Show details.
If there is a failure, hover your mouse over the X icon in the table to see a tool tip explaining the failure reason.
Per traffic line:
Query results
FireFlow runs a Traffic Simulation Query on the traffic requested to be allowed/blocked on each traffic line and presents the results, whether traffic is allowed or blocked.
You can click Find out why to see details of the Traffic Simulation Query results .
Work order/ policy comparison
The Work order/ policy comparison section describes the work order recommendation and the policy comparison result.
In order to see the rule(s) comparison details, click Show details.
The table displayed shows the most relevant rule(s) found for the current traffic line. These rules are compared to the work order recommendation and are displayed according to their match level:
Rule matching levels | Work order recommendation and the actual policy rule: |
Perfectly matched | Match perfectly. |
Wider matched | Policy rule added/modified is more permissive (in one or more of the fields) than rule. |
Partially matched | Policy rule added/modified is less permissive. |
Matched by comment | No relevant rule is found by the common logic. The rule is matched by its comment. |
In addition, a Recommendation Compatibility Check table appears, if relevant, providing details regarding rule fields comparison.
If there is a failure, hover your mouse over the X icon in the table to see a tool tip explaining the failure reason.
Note: By default, a discrepancy in object names will not cause validation to fail. For more details, see Change validation parameters.
Common validation results
Result | explanation |
Allow"/”Drop” traffic. Validation succeeds if the traffic simulation query indicates the planned traffic for the line is allowed/blocked, and the change on the device perfectly matches the work order recommendation. Recertify traffic. Validation succeeds if the traffic simulation query indicates the planned traffic for the line is blocked, and no rule exists on the device with the relevant ID. Custom Field Validation Result Details will contain SUCCESS. Custom Field Change Validation Result will contain The change was implemented as planned. |
|
Allow/Drop traffic. Validation fails if the traffic simulation indicates the planned traffic for the line is partially or fully blocked/allowed accordingly. Custom Field Validation Result Details will contain FAIL. Custom Field Change Validation Result will contain The change is not fully implemented on the device. |
|
Allow/Drop traffic.. Validation fails if the traffic simulation query indicates the planned traffic for the line is allowed/blocked as expected, but the work order comparison indicates that the change was not implemented as recommended. This may happen when traffic is more permissive or covered by several rules. Custom Field Validation Result Details will contain QUERY_ONLY_SUCCESS. Custom Field Change Validation Result will contain The change is not fully implemented on the device. |
Why validation fails even when implementation is correct
It may occur that change validation fails even when the work order was implemented as specified.
The following are possible reasons for change validation failure:
- The traffic is partially blocked by a rule that exists above the allowing rule. The partially blocking rule is not displayed in the validation details.
- Part of the traffic was already allowed by another rule that is located lower in the policy.
- The rule was added in incorrect zones/ interfaces.
- Both a perfectly matched rule and a wider rule exist, but only one of them is being matched.
For Palo Alto Networks Panorama devices, FireFlow will always recommend changing the lowest device group. If a higher level device group blocks the traffic the change request is attempting to allow, the traffic will still not be allowed after the work order is implemented, and validation will fail. To allow the traffic you must manually change the higher level device group.