--- title: "Configure Classification Control policies" canonical: "https://docs.aryaka.com/space/KNOW/776994932/Configure%20Classification%20Control%20policies" format: markdown --- The Classification Control Policies page allows you to create rules that control whether applications are classified for network traffic. This allows the traffic to be properly routed and permitted or denied, as necessary, by subsequent security engines.  Classification Control policies Because applications and application groups can be used as match criteria in your routing and security rules, traffic must undergo application classification to identify the application associated with a traffic flow. Classification Control policies allow you to specify whether or not Aryaka should inspect network traffic to identify the application associated with the traffic. For example, if you want application classification to occur for traffic from certain ports but not from others, you can create Classification Control policies for each of these situations. Classification Control policies can only be created at the customer level, which means each rule you configure is applied to all of your sites. The Classification Control Policies page displays a table of configured rules and the action associated with each rule. For each rule you configure, you can assign one of the following actions to take on traffic that matches the rule: Skip Classification  Do Deterministic Classification (default) Do Conditional Classification Rule matches can be based on the following match criteria: Source IPs Source ports Destination IPs Destination ports Protocols These match criteria can be specified individually when you create a rule or as part of a named asset, defined on the  Asset Management  page. Assets can be reused in your security rules, but must be configured  before  you create the rule in which you want to use it.  After the application is classified, the security engines use the classification information to route traffic and to enforce security rules on your network traffic. See the FWaaS and  NGFW-SWG topics for details about the other security engines that are used to inspect network traffic.  The Rules table displays a list of configured Classification Control policies. Each table row includes the following details: Rule ID—Identification number for the rule, used in security logs. Name—User-defined name for the rule. Source—Match criteria related to the source of the traffic (for example, source IP address or user). Destination—Match criteria related to the destination of the traffic (for example, destination IP address or domain). Services—Match criteria related to traffic protocol and destination port. Action—Action applied to matched traffic (Skip Classification Do Deterministic Classification, or Do Conditional Classification). Note the following when interacting with the rule table: If a single match criteria has more than four entires, click Show More to view all entires. If an asset is used as match criteria, click the asset name to display an in-page view of what the asset includes. The Rules table also includes the following components: Detailed View toggle—Turn this toggle on to display details on the type of match criteria (for example, IP or URL) and the required condition (for example, is or is not) included in a rule. When this toggle is turned off, only the specific match criteria are displayed. Download icon—Download the Rules table as a CSV file. Configure icon—Select whether to display the columns related to match criteria (source, destination, and services) in the table. Follow the procedures later in this topic to add Classification Control policies or to view and edit existing Classification Control policies. Skip Classification When a Classification Control policy is configured with the Skip Classification action, matched traffic skips application classification. During subsequent routing and security rule enforcement, there is no application associated with the traffic that can be used in a rule match. Do Deterministic Classification When a Classification Control policy is configured with the Do Deterministic Classification action, traffic is inspected by the Aryaka application classification engine, which determines which application the traffic is associated with. To deterministically classify an application, the ANAP or POP must act as the server the client is trying to connect to. Intercepted TCP connections are therefore locally acknowledged by the ANAP or POP instead of by the destination server, allowing the ANAP or POP to use the application classification during subsequent routing and security rule enforcement. Note that the ANAP or POP responds to the connection regardless of whether the destination server would have acknowledged the connection. For example, if a client is trying to reach a specific port on a server, the ANAP or POP responds to the connection even if the port is not open on the server. Therefore, if you are using a port scanner, you should review your Classification Control policies and use the Do Conditional Classification action when possible.  Default action If you do not configure any Classification Control policies, the default is that the Do Deterministic Classification action is applied to all traffic. This default behavior means that the ANAP or POP acts as the destination server and locally acknowledges the connection. If you do not want this to occur, use the procedure in this topic to create a Classification Control policy that matches all traffic and applies the Do Conditional Classification action to it. Do Conditional Classification When a Classification Control policy is configured with the Do Conditional Classification action, the ANAP or POP verifies that the destination server is reachable before locally acknowledging the TCP connection. If the destination server responds, the ANAP or POP starts building a cache entry associated with the server’s IP address and port. When this cache entry exists, any new flows are locally acknowledged by the ANAP or POP. If the destination server does not respond, the ANAP or POP does not respond to the client and a cache entry is not created. If you are using a network device that does port scanning, configuring a rule with the Do Conditional Classification action allows these devices to function as expected. Application reclassification Based on the first few packets of a connection, the application classification engine determines which application the traffic is associated with. However, as additional packets are inspected, this initial application classification can be revised. Application reclassification occurs if the initial classification, based on the first packet, is different from classifications on subsequent packets. The initial and revised classification are both used when enforcing routing and security rules. Consider a scenario where a flow is classified as Application A during the initial classification and then receives a revised classification of Application B during further inspection. Rule evaluation during routing and and security enforcement is generally based on the initial classification. This means that if you have a rule, which is configured to permit matched traffic, that uses Application A as a match criteria, the flow is considered a rule match and the rule action is enforced (the traffic is permitted). However, the Next Generation Firewall rule table is an exception to this behavior. For this rule table, a revised classification results in a revised rule match and revised rule action, if different from the rule action associated with any rule match from the initial classification. This means that if you have a Next Generation Firewall rule with Application A as a match criteria that is configured to permit matched traffic and you have a Next Generation Firewall rule with  Application B as a match criteria that is configured to deny traffic, a flow with an initial classification of Application A and a revised classification of Application B  is ultimately denied by the Next Generation Firewall security engine.  To add a Classification Control policy Open the Classification Control Policies page if it is not already open: Log in to MyAryaka. The Home page appears. Click  Global Settings in the left navigation pane. The Global Settings page appears and displays a series of tiles. Click Manage in the Classification Engine Settings tile. The Classification Engine Settings page appears. Click the Classification Control Policies tile. The Classification Control Policies page appears and displays a list of your configured Classification Control policies. Click the  Edit icon. The page displays in edit mode. Click  Add  on the Rules table. The Add a Policy page appears and displays the Details pane and the Match Criteria pane. In the Details pane, enter a name for your rule, then click the  Actions  drop-down list and select one of the following actions to take when a condition of the rule is met: Skip Classification—Traffic skips application classification. Do Deterministic Classification—Traffic is inspected to determine which application the traffic is associated with. This action is recommended when identifying the application is critical for subsequent routing decisions or security rule enforcement. Do Conditional Classification—Traffic is only inspected to determine which application the traffic is associated with if a successful flow has previously been established to the destination IP address and port. This action is recommended when using port scanners or when identifying the application is not critical to subsequent routing decisions or security rule enforcement.  In the Match Criteria pane, complete the following procedure for each of the criterion you want to include in the rule:  Click the  Condition  drop-down list and select a condition for the criterion. Complete one of the following procedures to add match criteria: Type a criterion into the appropriate field and hit Enter. The criterion is added. Click the  Add icon. The Add < criterion > dialog appears. Depending on the type of match criteria selected, do one of the following: Click one or more entities you want to include as match criteria for the rule. The selected entities are highlighted in green and display a check. Click  Add Selected . The page displays the selected entities for each criterion.  Enter one or more entities you want to include as match criteria for the rule. Click  Add Selected . The page displays the selected entities for each criterion.  Click  Continue . The Classification Control Policies page appears with the rule you added included in the Rules table. (Optional) Repeat steps 3–6 to add additional rules. (Optional) Reorder the Rules table. Click the  Reposition icon next to the rule you want to move and drag it to a new position in the table. Note:  Rules are evaluated in a top-down manner based on the Rules table. The first rule that matches the traffic is executed and the rest are ignored.  Do one of the following: Click  Save as Draft  to save a draft of the rule. Click Submit  to save the rule. You are prompted to select one of the following options: Activate Later or Activate Now . See Activate configuration updates for details. When your update is activated, the Classification Control Policy page displays your new rule in the list of Classification Control policies. To edit Classification Control policies Open the Classification Control Policies page if it is not already open: Log in to MyAryaka. The Home page appears. Click  Global Settings in the left navigation pane. The Global Settings page appears and displays a series of tiles. Click Manage in the Classification Engine Settings tile. The Classification Engine Settings page appears. Click the Classification Control Policies tile. The Classification Control Policies page appears and displays a list of configured Classification Control policies. Click the Edit icon. The page displays in edit mode. Use the following options to modify a rule as needed: Edit—Displays the match criteria in edit mode. Add, edit, or remove entities from any of the match criteria. Complete step 5 of the  Add a Classification Control policy  procedure to add or edit the entities included in a criterion, then click Continue . Add Below—Adds a new blank rule below the selected rule. More Options > Clone—Adds a new rule with the same match criteria as the cloned rule. The new rule is added to the Rules table directly after the rule it was cloned from. More Options > Disable—Renders the rule inactive, but does not remove it from the Rules table. The rule can be reenabled later.  More Options > Delete—Removes the rule from the Rules table.  Reorder the Rules table—Click the  Reposition icon next to the rule you want to move and drag it to a new position in the Rules table.  Do one of the following: Click  Save as Draft  to save a draft of the rule changes. Click Submit  to save the rule changes. You are prompted to select one of the following options: Activate Later or Activate Now . See Activate configuration updates for details. When your update is activated, the changes to the Classification Control policy are saved. Example rule configuration The following example describes the configuration of a Classification Control policy for each of the three possible actions.  The rules included in this example are for instructional purposes only. You should configure your Classification Control policies based on your organization's needs. Consider a situation where you want applications to be identified, but are using a port scanner and do not want all traffic to have the default Do Deterministic Classification action applied to it. You can configure a rule that matches all network traffic and applies the Do Conditional Classification to it. The following graphic displays the configuration of this rule, named Match all - conditional : This rule does not contain any match criteria because it is designed to match all traffic. Then, if there was a specific type of traffic for which you did not need to identify the application, you could configure a rule that matches the traffic and applies the Skip Classification action to it. The following graphic displays an example configuration for this type of rule, named skip app classification - IP asset 1 : This rule matches traffic from any of the IP addresses included in the IP asset named IP_Asset_1  and applies the Skip Classification action to it. This traffic cannot subsequently be routed, permitted, or denied by security engines by using application or application group match criteria. Similarly, if there were specific types of traffic for which an application classification were required, you could configure a rule that matches the specific type of traffic and applies the Do Deterministic Classification to it. The following graphic displays an example configuration for this type of rule, named ports 80, 443 - deterministic : This rule matches traffic from ports 80 and 443 an applies the Do Deterministic Classification to it. This means that this traffic is sent to the Aryaka application classification engine and the application associated with the traffic is determined.  After these rules are configured, they can be reordered if needed. Classification Control policies are evaluated in the order in which they are listed—the first rule that matches the traffic is evaluated and the rest of the rules are ignored. Therefore, if the match all - conditional rule were listed first, it would match all incoming traffic and the other rules would never be evaluated.  The following graphic displays the Classification Control Rules table with the three example rules enabled and with the match all - conditional rule placed below the other rules so that it applies to all unmatched traffic: In this topic Related topics Security engine rulesets Configure Classification Engine settings Configure Unknown Traffic Control