Advanced Policy-Based Routing

Advanced Policy-Based Routing

The relentless growth of voice, data, and video traffic and applications traversing on the network requires that networks recognize traffic types to effectively prioritize, segregate, and route traffic without compromising performance or availability.

Starting with Junos OS Release 15.1X49-D60, SRX Series Firewalls support advanced policy-based routing (APBR) to address these challenges.

Advanced policy-based routing is a type of session-based, application-aware routing. This mechanism combines the policy-based routing and application-aware traffic management solution. APBR implies classifying the flows based on applications’ attributes and applying filters based on these attributes to redirect the traffic. The flow-classifying mechanism is based on packets representing the application in use.

APBR implements:

• Deep packet inspection and pattern-matching capabilities of AppID to identify application traffic or a user session within an application

• Lookup in ASC for application type and the corresponding destination IP address, destination port, protocol type, and service for a matching rule

If a matching rule is found, the traffic is directed to an appropriate route and the corresponding interface or device.

Benefits of APBR

• Enables you to define the routing behavior based on applications.

• Provides more flexible traffic-handling capabilities and offers granular control for forwarding packets based on application attributes.

Understanding How APBR Works

Lets understand about the APBR components before we discuss working of APBR:

• Create an APBR profile (also referred to as an application profile in this document). The profile includes multiple APBR rules. Each rule includes multiple applications or application groups as match criteria. If the traffic matches any of the application or application groups of a rule, the rule is considered as a match and the profile directs the application traffic to the associated routing-instance.

• APBR profile associates a routing instance with the APBR rule. When the traffic matches an application profile, the associated static route and next hop defined in the routing instance is used to route the traffic for the particular session.

• Associate the application profile to the ingress traffic. You can attach APBR profile to an APBR policy and apply as application services for the session.

Lets proceed with understanding about APBR workflow and then discuss about the APBR midstream support and then about the first packet classification in APBR.

APBR Workflow

Figure 1 summarizes APBR behavior prior to Junos OS Release 21.3R1.

Figure 1: APBR Behavior

Security device uses DPI to identify attributes of an application and uses APBR to route the traffic over the network. In a service chain, application traffic undergoes DPI before the device applies ABPR. The process of identifying an application using DPI requires analysis of multiple packets. In such cases, initial traffic traverses through a default route (non-APBR route) to reach the destination. The process continues still DPI identifies the application. Once DPI identifies the application, APBR applies rules for the rest of the session. Traffic traverse through the route according to the APBR profile rule.

When you use different NAT pools for source NAT and apply midstream APBR, the source IP address of the session remains same as the one with which the session was using before midstream APBR.

• APBR Midstream Support
• APBR with First Packet Classification
• Benefits of First Packet Classification
• Limitations

Starting in Junos OS Release 21.3R1, APBR uses first-packet classification to identify applications in network traffic. APBR identifies applications by examining the very first packet in the traffic flow and then applies application-specific rules to forward the traffic.

Figure 2 shows how APBR uses the first-packet classification to get application details.

Figure 2: APBR with First-Packet Classification

First-packet classification leverages on the repository that includes details such as static IP mapping and ports details of applications. The repository is part of the application signature package (JDPI).

For the first session of a cacheable application, APBR queries the ASC to get application details of the flow. If the entry of the application is not available in the ASC, APBR queries JDPI for the application details. APBR uses the IP address and the port details of the flow for the query. If the application mapping is available, then JDPI returns the details to APBR. After getting application details, APBR searches for the configured profile of the application and routes the packet through the assigned routing instance.

At the same time, JDPI continues to process the packets and updates the ASC (if enabled). For the subsequent flows, APBR performs routing of the traffic based on the application entry present in the ASC for the flow.

With first-packet classification, you can use different NAT pools for source NAT in your APBR configuration for cacheable application.

Advanced Policy-Based Routing Options

You can streamline the traffic handling with APBR by using the following options:

• Limit route change- Some sessions go through continuous classification in the middle of the session as application signatures identify the application. Whenever an application is identified by the application signatures, APBR is applied, and this results in a change in the route of the traffic. You can limit the number of times a route can change for a session by using the max-route-change option of the tunables statement.

  set security advance-policy-based-routing tunables max-route-change value

  Example:

  In this example, you want to limit the number of route changes per session to 5. When there is a change in the route in the middle of the session, this count is reduced to 4. This process continues until the count reaches 0. After that, APBR is not applied in the middle of the session.

  If an identified application has an entry in the ASC, then, the count is not reduced for that session, because the session started with the specified route according to the APBR configuration.

• Terminate session if APBR is bypassed–You can terminate the session if there is a mismatch between zones when APBR is being applied in the middle of the session. When you want to apply APBR in the middle of a session, both new egress interface and existing egress interface must be part of the same zone. If you change the zone for an interface in the middle of a session, then, by default, APBR is not applied, and the traffic continues to traverse through the existing interface. To change this default behavior, you can terminate the session entirely, instead of allowing traffic to traverse through the same route bypassing APBR, by using the drop-on-zone-mismatch option of the tunables statement.

  Example:

• Enable logging—You can enable logging to record events that occur on the device, for instance, when APBR is bypassed because of a change in the zones for interfaces. You can use the enable-logging option of the tunables statement to configure the logging.

  Example:

• Enable reverse reroute—For deployments that requires traffic symmetry for ECMP routes, and the incoming traffic needs to switch in the middle of session, the rerouting can be achieved using the option enable-reverse-reroute specific to a security zone as follows:

  Example:

  [edit]

  set security zones security-zone zone-name enable-reverse-reroute

  When the above configuration is enabled for a security zone, where an incoming packet arrives on an interface and has a different outgoing/return interface, a change in the interface is detected and triggers a reroute. A route lookup is performed for the reverse path, and the preference will be given to the interface on which the packet has arrived.

  Further processing stops for a particular session when a route lookup fails for the traffic on reverse path.

  Support for reverse rerouting is available starting in Junos OS Release 15.1X49-D130 and later releases.

• Support for Layer 3 and Layer 4 Applications—Starting in Junos OS Release 20.2R1, APBR supports Layer 3 and Layer 4 custom applications. You can manually disable Layer 3 and Layer 4 custom application lookup in APBR by using the following configuration-statement:
• Application Tracking—

  You can enable, AppTrack to inspect traffic and collect statistics for application flows in the specified zone. See Understanding Application Tracking for more details.

Use Case

• When multiple ISP links are used:

  • APBR can be used for selecting high-bandwidth, low-latency links for important applications, when more than one link is available.

  • APBR can be used for creating a fallback link for important traffic in case of link failure. When multiple links are available, and the main link carrying the important application traffic suffers an outage, then the other link configured as the fallback link can be used to carry traffic.

  • APBR can be used for segregating the traffic for deep inspection or analysis. With this feature, you can classify the traffic based on applications that are required to go through deep inspection and audit. If required, such traffic can be routed to a different device.

Limitations

APBR has the following limitations:

• Redirecting the route for the traffic depends on the presence of an entry in the application system cache (ASC). Routing will succeed only if the ASC lookup is successful. For the first session, when the ASC is not present for the traffic, the traffic traverses through a default route (non-APBR route) to the destination (this limitation is applicable only for the releases before Junos OS 15.1X49-D110).

• APBR does not work if an application signature package is not installed or application identification is not enabled.

APBR with midstream support has the following limitations:

• APBR works only for forward traffic.

• APBR does not work for data sessions initiated by an entity from the control session, such as active FTP.

• When using different NAT pools for source NAT and midstream APBR is applied, the source IP address of the session continues to be the same as the one with which the session has been using before applying the midstream APBR.

• APBR with midstream support works only when all egress interfaces are in the same zone. Because of this, only the forwarding and virtual routing and forwarding (VRF) routing instances can be used to avail APBR midstream support.

How APBR Policy Works?

APBR policies are defined for a security zone. If there is one or more APBR policy associated with a zone, the session that is initiated from the security zone goes through the policy match.

The following sequences are involved in matching the traffic by an APBR policy and applying advanced policy-based routing to forward the traffic, based on the defined parameters/rules:

• When traffic arrives at the ingress zone, it is matched by the APBR policy rules. The policy match condition include the source address, destination address and application.

• When the traffic matches the security policy rules, the action of the APBR policy is applied to the traffic. You can enable APBR as an application service in the APBR policy action by specifying the APBR profile name.

• The APBR profile configuration incudes the set of rules that contains set of dynamic applications and dyamic application groups as match condition. The action part of those rules contain the routing instance through which traffic needs to be forwarded. The routing instance can include configuration of static routs or dynamic learned routes.

• All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or interface.

APBR policy rules are terminal, which means that once the traffic is matched by a policy, it is not processed further by the other policies.

If an APBR policy has the matching traffic and APBR profile does not have any traffic matching the rule, then the traffic matching the APBR policy traverses through a default routing-instance [inet0] to the destination.

Legacy APBR Profile Support

Prior to the Junos OS Release 18.2R1, APBR profile was applied at security zone-level. With the support for APBR policy, APBR configuration at security-zone level is deprecated future, rather than being immediately removed in order to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.

However, if you have configured a zone-based APBR, and you attempt to add an APBR policy for the particular security zone, commit might fail. You must delete the zone-based configuration in order to configure the APBR policy for the zone. Similarly if an APBR policy is configured for a security zone, and you attempt to configure zone-based APBR, results in commit error.

Limitation

• When using specific address or address set in the APBR policy rule, we recommend to use the global address book. Because, zone specific rules might not be applicable for destination address, as the destination zone is not known at time of policy evaluation.

• Configuring APBR policy for the security zone junos-host zone is not supported.

Rule Processing in an APBR Profile

You can provide advanced policy-based routing by classifying the traffic based on applications’ attributes and applying policies based on these attributes to redirect the traffic. To do this, you must define the APBR profile and associate it to a APBR policy. You can create an APBR profile to include multiple rules with either dynamic applications, application groups or both, or a URL category as match criteria. The rules configured in the APBR profile can include either of the following:

• One or more applications, dynamic applications, or application groups

• URL category (IP destination address)—EWF or local Web filtering.

In an APBR profile, rule lookup is performed for both the match criteria. If only one match criteria is available, the rule lookup is done based on the available match criteria.

The APBR profile includes the rules to match the traffic with applications or URL categories and the action to redirect the matching traffic to the specified routing instance for the route lookup.

In Junos OS Release18.3R1, the URL category match is done based on the destination IP address; because of this, URL category-based rule match is terminated at the first packet of the session. As a dynamic application might be identified in the middle of the session, the matching process for the dynamic application rules continues until the process of application identification is complete.

Benefits of URL Category-Based Routing

• Using URL-based categories enables you to have granular control over Web traffic. The traffic belonging to specific categories of websites is redirected through different paths, and based on the category, it is subjected to further security processing, including SSL decryption for HTTPS traffic.

• Traffic-handling capabilities based on URL categories enable you to use different paths for selected websites. Using different paths results in better quality of experience (QoE) and also enables you to utilize the available bandwidth effectively.

• SD-WAN solutions can utilize URL category-based routing in addition to the dynamic application-based routing.

• URL category-based routing can be used for local Internet breakout solutions as it can work with source NAT configuration changes.

Limitations of URL Category-Based Routing

Using URL categories in an APBR profile has the following limitations:

• Only the destination IP address is used for the URL category identification in an APBR profile. URL categories based on the host, or on the URL or the SNI field are not supported.

• You can configure either a dynamic application or a URL category as the match condition in an APBR profile rule. Configuring a rule with both URL category and dynamic application results in a commit error.

Benefits

• Enables you to define the routing behavior at more granular levels to ensure safe enforcement of policy on the application traffic traversing the network.

• Provides more flexible traffic-handling capabilities and offers granular control for forwarding packets based on the roles and business requirements of users.

Introduction

Application identification techniques rely on deep packet inspection (DPI). There are some cases where DPI engine might not be able to identify the application, for example—encrypted traffic. If you apply APBR rules on such traffic, the traffic undergoes normal processing without APBR functionality applied on it.

Starting in Junos OS release 19.3R1, SRX Series Firewalls support configuring DSCP values in an APBR rule as match criteria to perform APBR functionality on the DSCP-tagged traffic.

You can configure DSCP value in addition to the other matching criteria of the APBR rule such as dynamic application, and dynamic application group.

By configuring the DSCP value in an APBR rule, you can extend the APBR service to the traffic with the DSCP markings.

Use Case

You can use APBR rules with DSCP as match criteria for the encrypted traffic.

Limitation

• Support not available for configuring rules with DSCP value and URL category in a single APBR profile.

APBR Rule Lookup When Using a DSCP Value as Match Criteria

In a APBR rule, you can configure a DSCP value or dynamic applications or combination of both.

If you have configured both DSCP and dynamic application in a APBR rule, the rule is considered as match if the traffic matches all the criteria specified in the rule. If there are multiple DSCP values present in the APBR rule, then if any one criteria matches, it is considered as match.

A APBR profile can contain multiple rules, each rule with a variety of match conditions.

In case of multiple APBR rules in a APBR profile, the rule lookup uses the following priority order:

1. Rule with DSCP + dynamic application

2. Rule with dynamic application

3. Rule with DSCP value

If a APBR profile contains multiple rules, the system performs rule lookup and applies the rule in the following order:

• System applies the DSCP-based rules for the first packet of the session.

• System continues to check if any application information available either from DPI classification or application system cache (ASC).

• In the middle of the session, if DPI identifies a new application, the system performs a rule lookup and applies new rule (application-based rule or DSCP-based rule or combination of both) as applicable.

• Identifying application and rule lookup continues till the DPI identifies an application as the final application or maximum reroute value is reached.

• If the rule lookup does not match any rule, no further action is taken.

Lets understand how APBR performs rule lookup and applies the rules with the following two examples:

• Example 1
• Example 2

Configuration

• CLI Quick Configuration
• Step-by-Step Procedure
• Results

Why Selectively Disabling the Midstream Routing is Required?

Some sessions go through continuous classification in the middle of the session as application signatures identify the application. Whenever an application is identified by the application signatures, APBR is applied, and this results in a change in the route of the traffic. You can limit the number of times a route can change for a session by using the max-route-change option. If you set this option to 0, the APBR is disabled for the particular session. However, this option also disables the APBR functionality globally on your device which might not be required.

Selectively Disabling APBR In Midstream

Starting in Junos OS Release 19.4R1, you can selectively turn-off the APBR service in the middle of a session for a specific APBR rule, while retaining the global APBR functionality for the remaining sessions. When you disable midstream routing for a specific APBR rule, the system does not apply midstream APBR for corresponding application traffic, and routes the traffic through a non-APBR route.

To selectively disable the midstream APBR, you can configure the APBR rule with disable midstream routing option (disable-midstream-routing) at [edit security advance-policy-based-routing profile apbr-profile-name rule apbr-rule-name] hierarchy level.

Table 7 shows the behavior of the selectively disabling midstream APBR option.

Disabling midstream routing for a specific APBR rule will reroute the application traffic back through a default non-APBR route.