Policy Based Routing

This chapter describes how to configure Threat Defense to support policy based routing (PBR) through Management Center's Policy based Routing page. The following sections describe policy based routing, guidelines for PBR, and configuration for PBR.

About Policy Based Routing

In traditional routing, packets are routed based on the destination IP address. However, it is difficult to change the routing of specific traffic in a destination-based routing system. Policy Based Routing (PBR) gives you more control over routing by extending and complementing the existing mechanisms provided by routing protocols.

PBR allows you to set the IP precedence. It also allows you to specify a path for certain traffic, such as priority traffic over a high-cost link. With PBR, you can define routing that is based on criteria other than destination network such as source port, destination address, destination port, protocol, applications, or a combination of these objects.

You can use PBR to classify the network traffic based on applications. This routing method is applicable in scenarios where, numerous devices access applications and data in a large network deployment. Traditionally, large deployments have topologies that backhaul all the network traffic to a hub as encrypted traffic in a route-based VPN. These topologies often result in issues such as packet latency, reduced bandwidth, and packet drop. Overcoming these issues involves high-cost complex deployments and management.

PBR policy enables you to securely breakout traffic for specified applications. You can configure PBR policy in the Secure Firewall Management Center user interface to allow the applications to be directly accessed.

Why Use Policy Based Routing

Consider a company that has two links between locations: one a high-bandwidth, low-delay expensive link, and the other a low-bandwidth, higher-delay, less-expensive link. While using traditional routing protocols, the higher-bandwidth link gets most, if not all, of the traffic sent across it based on the metric savings obtained by the bandwidth, delay, or both (using EIGRP or OSPF) characteristics of the link. With PBR, you can route higher priority traffic over the high-bandwidth/low-delay link, while sending all other traffic over the low-bandwidth/high-delay link.

Following are a few scenarios where you can use Policy Based Routing:

Direct Internet Access

In this topology, application traffic from the branch office can be routed directly to the internet instead of through the VPN tunnel connecting to the headquarters. The branch threat defense is configured with an internet exit point and the PBR policy is applied on the ingress interface (Inside 1) to identify the traffic based on the applications defined in the ACL. Correspondingly, the traffic is forwarded through the egress interfaces directly to the internet or to the IPsec VPN tunnel.

DIA scenario

Equal-Access and Source-Sensitive Routing

In this topology, traffic from the HR and Mgmt networks can be configured to go through ISP1 and traffic from Eng network can be configured to go through ISP2. Thus, policy based routing enables the network administrators to provide equal-access and source-sensitive routing, as shown here.

Equal access scenario

Load Sharing

In addition to the dynamic load-sharing capabilities offered by ECMP load balancing, network administrators can now implement policies to distribute traffic among multiple paths based on the traffic characteristics.

As an example, in the topology depicted in the Equal-Access Source Sensitive Routing scenario, an administrator can configure policy based routing to route the traffic from HR network through ISP1 and traffic from Eng network through ISP2 and thus share the load.

Guidelines and Limitations for Policy Based Routing

Firewall Mode Guidelines

PBR is supported only on routed firewall mode.

Device Guidelines

  • PBR through management center's Policy Based Routing page is supported only on devices with Secure Firewall Threat Defense version 7.1 and higher. Though the Secure Firewall Management Center release 7.1 supports Threat Defense versions earlier than 7.1, you cannot enable PBR on such devices using the Policy Based Routing page.

  • FlexConfig was used to configure PBR in management center for Threat Defense versions earlier than 7.1. You can still use FlexConfig to configure PBR in all versions. However, for an ingress interface, you cannot configure PBR using both FlexConfig and management center's Policy Based Routing page.

  • Configuring application based PBR policy on cluster devices is not supported.

Interface Guidelines

  • Only routed interfaces and non management-only interfaces belonging to the Global virtual router can be configured as ingress or egress interface.

  • PBR is not supported on user-defined virtual routers.

  • Only interfaces that have a logical name can be defined in the policy.

  • Static VTIs can be configured only as egress interfaces.

  • Before proceeding with configuration, ensure that the ingress and egress traffic of each session flows through the same ISP-facing interface to avoid unexpected behavior caused by asymetirc routing, specifically when NAT and VPN are in use.

IPv6 Support

PBR supports IPv6.

Application-Based PBR and DNS Configuration

  • Application-based PBR uses DNS snooping for application detection. Application detection succeeds only if the DNS requests pass through threat defense in a clear-text format; the DNS traffic is not encrypted.

  • You must configure trusted DNS servers.

For more information on configuring DNS servers, see DNS.

PBR Policies Not Applied for Embryonic Traffic


Note

An embryonic connection is where the necessary handshake between source and destination has not been made.

When a new internal interface is added and a new VPN policy is created using a unique address pool, PBR is applied to the outside interface matching the source of the new client pool. Thus, PBR sends traffic from the client to the next hop on the new interface. However, PBR is not involved in the return traffic from a host that has not yet established a connection with the new internal interface routes to the client. Thus, the return traffic from the host to the VPN client, specifically, the VPN client response is dropped as there is no valid route. You must configure a weighted static route with a higher metric on the internal interface.

Additional Guidelines

  • All existing configuration restrictions and limitations of route map will be carried forward.

  • While defining the ACL for the policy match criteria, you can select multiple applications from a list of predefined applications to form an Access Control Entry (ACE). In threat defense, the predefined applications are stored as Network Service objects and the group of applications as Network Service Groups (NSG). You can create a maximum of 1024 such NSGs. The application or network service group is detected through first-packet classification. Currently, you cannot add to or modify the predefined applications list.

Path Monitoring

Path monitoring, when configured on interfaces, derive metrics such as round trip time (RTT), jitter, mean opinion score (MOS), and packet loss per interface. These metrics are used to determine the best path for routing PBR traffic.

The metrics on the interfaces are collected dynamically using ICMP probe messages to the interface's default gateway or a specified remote peer.

Default Monitoring Timers

For metric collection and monitoring, the following timers are used:

  • The interface monitor average interval is 30 seconds. This interval indicates the frequency to which the probes average.

  • The interface monitor update interval is 30 seconds. This interval indicates the frequency at which the average of the collected values are calculated and made available for PBR to determine the best routing path.

  • The interface monitor probe interval by ICMP is one second. This interval indicates the frequency at which an ICMP ping is sent.


Note

You cannot configure or modify the interval for any of these timers.

PBR and Path Monitoring

Typically, in PBR, traffic is forwarded through egress interfaces based on the priority value (interface cost) configured on them. From management center version 7.2, PBR uses IP-based path monitoring to collect the performance metrics (RTT, jitter, packet-lost, and MOS) of the egress interfaces. PBR uses the metrics to determine the best path (egress interface) for forwarding the traffic. Path monitoring periodically notifies PBR about the monitored interface whose metric got changed. PBR retrieves the latest metric values for the monitored interfaces from the path monitoring database and updates the data path.

You must enable path monitoring for the interface and configure the monitoring type. The PBR policy page allows you to specify the desired metric for path determination. See Configure Policy-Based Routing Policy.

Configure Path Monitoring Settings

The PBR policy relies on flexible metrics, such as round trip time (RTT), jitter, mean opinion score (MOS), and packet loss of the interfaces to identify the best routing path for its traffic. Path monitoring collects these metrics on the specified interfaces. On the Interfaces page, you can configure interfaces with settings for path monitoring to send the ICMP probes for metrics collection.

Threat Defense Feature History:

Procedure

Step 1

Select Devices > Device Management and click Edit (edit icon) for your threat defense device. The Interfaces page is selected by default.

Step 2

Click Edit (edit icon) for the interface you want to edit.

Step 3

Click the Path Monitoring tab.

Step 4

Click the Enable Path Monitoring check box.

Step 5

From the Monitoring Type drop-down list, select the relevant option:

  • Auto—Sends ICMP probes to the IPv4 default gateway of the interface. If the IPv4 gateway does not exist, path monitoring sends the probes to the IPv6 default gateway of the interface.

  • Peer IPv4—Sends ICMP probes to the specified peer IPv4 address (next-hop IP) for monitoring. If you select this option, enter the IPv4 address in the Peer IP To Monitor field.

  • Peer IPv6—Sends ICMP probes to the specified peer IPv6 address (next-hop IP) for monitoring. If you select this option, enter the IPv6 address in the Peer IP To Monitor field.

  • Auto IPv4—Sends ICMP probes to the default IPv4 gateway of the interface.

  • Auto IPv6—Send ICMP probes to the default IPv6 gateway of the interface.

Note

 

  • The Auto options are not available for VTI interfaces. You must specify the peer address.

  • Only one next-hop is monitored to a destination. That is, you cannot specify more than one peer address to monitor for an interface.

Step 6

Click Ok, and to save the settings, click Save.

Configure Policy-Based Routing Policy

You can configure the PBR policy on the Policy Based Routing page by specifying the ingress interfaces, match criteria (Extended Access Control List), and egress interfaces.

Threat Defense Feature History:

  • 7.3—Configuring next-hops for the PBR route-map.

  • 7.2—PBR based on path monitoring.

  • 7.2—Policy Based Routing introduced.

Before you begin

To use the path monitoring metrics for configuring the traffic forwarding priority over egress interfaces, you must configure the path monitoring settings for the interfaces. See Configure Path Monitoring Settings.

Procedure

Step 1

Choose Devices > Device Management, and edit the threat defense device.

Step 2

Click Routing.

Step 3

Click Policy Based Routing.

The Policy Based Routing page displays the configured policy. The grid displays the list of ingress interfaces and a combination of the policy-based route access list, and egress interfaces.

Step 4

To configure the policy, click Add.

Step 5

In the Add Policy Based Route dialog box, select the Ingress Interface from the drop-down list.

Note

 

Only interfaces that have logical names and that belong to a global virtual router are listed in the drop-down.

Step 6

To specify the match criteria and the forward action in the policy, click Add.

Step 7

In the Add Forwarding Actions dialog box, do the following:

  1. From the Match ACL drop-down, choose the extended access control list object. You can predefine the ACL object (see Configure Extended ACL Objects) or click the Add (add icon) icon to create the object. In the New Extended Access List Object box, enter a name, click Add to open the Add Extended Access List Entry dialog box, where you can define the network, port, or application match criteria for the PBR policy.

    Note

     

    You cannot have both application and destination address defined in an ACE.

    To selectively apply PBR on the incoming interface, you can define Block criteria in the ACE. When the traffic matches the block rule of the ACE, the traffic is forwarded to the egress interface based on the routing table.

  2. From the Send To drop-down list:

    • To select the configured interfaces, choose Egress Interfaces.

    • To specify the IPv4/IPv6 next hop addresses, choose IP Address. Proceed to Step 7.e

  3. If you have selected Egress Interfaces, from the Interface Ordering drop-down, choose the relevant option:

    • By Interface Priority—The traffic is forwarded based on the priority of the interfaces. Traffic is routed to the interface with the least priority value first. When the interface is not available, the traffic is then forwarded to the interface with the next lowest priority value. For example, let us assume that Gig0/1, Gig0/2, and Gig0/3 are configured with priority values 0,1, and 2 respectively. The traffic is forwarded to Gig0/1. If Gig0/1 becomes unavailable, the traffic is then forwarded to Gig0/2.

      Note

       

      To configure the priority for the interfaces, click Configure Interface Priority on the Policy Based Routing page. In the dialog box, provide the priority number against the interfaces, and then click Save. You can also configure the priority for an interface in the Interface Settings.

      When the priority value is the same for all the interfaces, the traffic is balanced among the interfaces.

    • By Order—The traffic is forwarded based on the sequence of the interfaces specified here. For example, let us assume that Gig0/1, Gig0/2, and Gig0/3 are selected in the following order, Gig0/2, Gig0/3, Gig0/1. The traffic is forwarded to Gig0/2 first, then to Gig0/3, irrespective of their priority values.

    • By Minimal Jitter—The traffic is forwarded to the interface that has the lowest jitter value. You need to enable Path Monitoring on the interfaces for PBR to obtain the jitter values.

    • By Maximum Mean Opinion Score—The traffic is forwarded to the interface that has the maximum mean opinion score (MOS). You need to enable Path Monitoring on the interfaces for PBR to obtain the MOS values.

    • By Minimal Round Trip Time—The traffic is forwarded to the interface that has the minimal round trip time (RTT). You need to enable Path Monitoring on the interfaces for PBR to obtain the RTT values.

    • By Minimal Packet Loss—The traffic is forwarded to the interface that has the minimal packet loss. You need to enable Path Monitoring on the interfaces for PBR to obtain the packet loss values.

  4. In the Available Interfaces box, all the interfaces with their priority values are listed. From the list of interfaces, click the Add (add icon) button to add to the selected egress interfaces. Proceed to Step 7.k

  5. If you have selected IP Address, enter the IP addresses separated by commas in the IPv4 Addresses or IPv6 Addresses fields.

    Note

     

    When multiple next-hop IP addresses are provided, the traffic is forwarded as per the sequence of the specified IP addresses until a valid routable next-hop IP address is found. The configured next-hops should be directly connected.

  6. From the Don't Fragment drop-down list, select Yes, No, or None. If the DF (Don't Fragment) flag is set to Yes, the intermediate routers never perform fragmentation of a packet.

  7. To specify the current interface as the default for forwarding, check the Default Interface check box.

  8. The IPv4 Settings and IPv6 Settings tab enables you to specify the recursive and default settings:

    Note

     

    For a route-map, you can only specify either IPv4 or IPv6 next-hop settings.

    • Recursive—The route map configuration is applied only when the specified next-hop address and the default next-hop address are found on a directly connected subnet. However, you could use the recursive option, where the next-hop address need not be directly connected. Here, a recursive lookup is performed on the next-hop address, and matching traffic is forwarded to the next-hop used by that route entry according to the current routing path of the router.

    • Default—If the normal route lookup fails to match traffic, the traffic is forwarded to this specified next-hop IP address.

  9. Check the Peer Address check box to use the next-hop address as the peer address.

    Note

     

    You cannot configure a route map with both default next-hop address and peer address.

  10. For IPv4 settings, you can check whether the next IPv4 hops of a route map are available under Verify Availability—click the Add (add icon) button and add the next-hop IP address entries:

    • IP Address—Enter the next hop IP address.

    • Sequence—Entries are assessed in order using the sequence number. Ensure that no duplicate sequence numbers are entered. The valid range is 1 to 65535.

    • Track—Enter a valid ID. The valid range is 1 to 255.

  11. Click Save.

Step 8

To save the policy, click Save and Deploy.

The threat defense uses ACLs to match traffic and perform routing actions on the traffic. Typically, you configure a route map that specifies an ACL against which traffic is matched, and then you specify one or more actions for that traffic. With the use of path monitoring, PBR can now select the best egress interface for routing the traffic. Finally, you associate the route map with an interface on which you want to apply PBR on all incoming traffic.

Add Path Monitoring Dashboard

To view the path monitoring metrics, you must add the path monitoring dashboard to the Health Monitoring page of the device.

Procedure

Step 1

Choose System > Health > Monitor.

Step 2

Select the device, and click Add New Dashboard.

Step 3

In the Correlate Metrics dialog box, from the drop-down list, select Interface - Path Metrics.

Step 4

Click the Show Details link, where you can enter a custom name for the dashboard. By default, all the four metrics are selected for displaying as portlets in the dashboard. You can exclude any of them by clicking Delete (delete icon).

Step 5

Click Save.

Configuration Example for Policy Based Routing

Consider a typical corporate network scenario where all the branch network traffic passes through a route-based VPN of the corporate network and diverges to the extranet, when required. Accessing the web-based applications that address day-to-day operations through the corporate network results in huge network expansion and maintenance costs. This example illustrates the PBR configuration procedure for direct internet access.

The following figure depicts the topology of a corporate network. The branch network is connected to the corporate network through a route-based VPN. Traditionally, the corporate threat defense is configured to handle both the internal and external traffic of the branch office. With the PBR policy, the branch threat defense is configured with a policy that routes specific traffic to the WAN network instead of the virtual tunnels. The rest of the traffic flows through the route-based VPN, as usual.

This example also illustrates the configuring of the WAN and the VTI interfaces with ECMP zones to achieve load balancing.

Figure 1. Configuring Policy Based Routing on Branch Threat Defense in Management Center
Policy based routing configuration - an example

Before you begin

This example assumes that you have already configured WAN and VTI interfaces for the branch threat defense in management center.

Procedure

Step 1

Configure policy based routing for the branch threat defense, select the ingress interfaces:

  1. Choose Devices > Device Management, and edit the threat defense device.

  2. Choose Routing > Policy Based Routing, and on the Policy Based Routing page, click Add.

  3. In the Add Policy Based Route dialog box, select Inside 1, and Inside 2 from the Ingress Interface drop-down list.

Step 2

Specify the match criteria:

  1. Click Add.

  2. To define the match criteria, click the Add (add icon) button.

  3. In New Extended Access List Object, enter the name for the ACL (say, DIA-FTD-Branch), and click Add.

  4. In the Add Extended Access List Entry dialog box, choose the required web-based applications from the Application tab:

    Figure 2. Applications Tab
    Applications tab

    On the threat defense, the application group in an ACL is configured as a network service group and each of the applications as a network service object.

    Figure 3. Extended ACL
    Extended acl for policy based routing

  5. Click Save.

  6. Select DIA-FTD-Branch from the Match ACL drop-down list.

Step 3

Specify the egress interfaces:

  1. From the Send To and Interface Ordering drop-down lists, choose Egress Interfaces, and By Priority respectively.

  2. Under Available Interfaces, click the button against the respective interface names to add WAN1 and WAN2:

    Figure 4. Configuring Policy Based Routing
    pbr

  3. Click Save.

Step 4

Interface priority configuration:

You can set the priority value for the interfaces either in the Edit Physical Interface page, or in the Policy Based Routing page (Configure Interface Priority). In this example, the Edit Physical Interface method is described.

  1. Choose Devices > Device Management, and edit the branch threat defense.

  2. Set the priority for the interfaces. Click Edit against the interface and enter the priority value:

    Figure 5. Setting Interface Priority
    Setting interface priority

  3. Click Ok and Save.

Step 5

Create ECMP zones for load balancing:

  1. In the Routing page, click ECMP.

  2. To associate interfaces to the ECMP zone, click Add.

  3. Select WAN1 and WAN 2 and create an ECMP zone—ECMP-WAN. Similarly, add VTI01 and VTI02 and create an ECMP zone—ECMP-VTI:

    Figure 6. Associating Interfaces with ECMP Zone
    ECMP zone and interfaces

Step 6

Configure static routes for the zone interfaces for load balancing:

  1. In the Routing page, click Static Route.

  2. Click Add and specify the static routes for WAN1, WAN2, VTI01, and VTI02. Ensure that you specify the same metric value for the interfaces belonging to the same ECMP zones (Step 5):

    Figure 7. Configuring Static Routes for ECMP Zone Interfaces
    Configuring static routes - ECMP zones

    Note

     

    Ensure that the zone interfaces have the same destination address and metric, but different gateway addresses.

Step 7

Configure trusted DNS on the WAN objects of the branch threat defense to ensure secured flow of traffic to the internet:

  1. Choose Devices > Platform Settings, and create a DNS policy on the branch threat defense.

  2. To specify the trusted DNS, Edit the policy and click DNS.

  3. To specify the DNS servers for the DNS resolution to be used by WAN objects, in the DNS Settings tab, provide the DNS server group details and select WAN from the interface objects.

  4. Use the Trusted DNS Servers tab to provide specific DNS servers that you trust for the DNS resolution.

Step 8

Save and Deploy.

Any YouTube related access requests from the branch inside network INSIDE1 or INSIDE2 are routed to WAN1 or WAN2 as they would match the DIA-FTD-Branch ACL. Any other request, say google.com, are routed through VTI01 or VTI02 as configured in the Site to Site VPN Settings:

Figure 8. Site to Site VPN Settings
Example s2s vpn

With the ECMP configured, the network traffic is seamlessly balanced.

Configuration Example for PBR with Path Monitoring

This example details the configuration of PBR with path monitoring for the following applications with flexible metrics:

  • Audio or video sensitive applications (example, WebEx Meetings) with Jitter.

  • Cloud-based application (example, Office365) with RTT.

  • Network-based access control (with a specific source and destination) with Packet Loss.

Before you begin

  1. This example assumes that you are aware of the basic configuration steps for PBR.

  2. You have configured ingress and egress interfaces with logical names. In this example, the ingress interface is named Inside1, and egress interfaces are named ISP01, ISP02, and ISP03.

Procedure

Step 1

Path monitoring configuration on interfaces ISP01, ISP02, and ISP03:

For the metrics collection on the egress interfaces, you must enable and configure path monitoring on them.

  1. Choose Devices > Device Management, and edit threat defense.

  2. Under the Interfaces tab, edit the interface (in our example, ISP01)

  3. Click the Path Monitoring tab, select the Enable Path Monitoring check box, and then specify the monitoring type (see Configure Path Monitoring Settings).

  4. Click Ok and Save.

  5. Repeat the same steps and configure the path monitoring settings for ISP02 and ISP03.

Step 2

Configure policy-based routing for a branch in an organization threat defense, select the ingress interfaces:

  1. Choose Devices > Device Management, and edit the threat defense device.

  2. Choose Routing > Policy Based Routing, and on the Policy Based Routing page, click Add.

  3. In the Add Policy Based Route dialog box, select Inside 1 from the Ingress Interface drop-down list.

Step 3

Specify the match criteria:

  1. Click Add.

  2. To define the match criteria, click the Add (add icon) button.

  3. In New Extended Access List Object, enter the name for the ACL (example, PBR-WebEx), and click Add.

  4. In the Add Extended Access List Entry dialog box, choose the required web-based applications (example, WebEx Meetings) from the Application tab.

    Remember

     

    On threat defense, the application group in an ACL is configured as a network service group and each of the applications as a network service object.

  5. Click Save.

  6. Select PBR-WebEx from the Match ACL drop-down list.

Step 4

Specify the egress interfaces:

  1. From the Send To drop-down list, choose Egress Interfaces.

  2. From the Interface Ordering drop-down list, choose By Minimal Jitter.

  3. Under Available Interfaces, click the Right Arrow (right arrow icon)button against the respective interface names to add ISP01, ISP02, and ISP03.

  4. Click Save.

Step 5

Repeat Step 2 and Step 3 to create PBRs for the same interface (Inside1) to route Office365 and network-based access control traffic:

  1. Create a match criteria object, example PBR-Office365, and select the Office365 application from the Application tab.

  2. From the Interface Ordering drop-down list, choose By Minimal Round Trip Time.

  3. Specify the egress interfaces ISP01, ISP02, and ISP03, and click Save.

  4. Now, create a match criteria object, example PBR-networks, and specify the source and destination interface in the Network tab.

  5. From the Interface Ordering drop-down list, choose By Minimal Packet Loss.

  6. Specify the egress interfaces ISP01, ISP02, and ISP03, and click Save.

Step 6

Save and Deploy.

Step 7

To view path monitoring metrics, choose Devices > Device Management, and from More (more icon) click Health Monitor. To view the metric details for the interfaces of the device, you must add the path metrics dashboard. For details, see Add Path Monitoring Dashboard.

The WebEx, Office365, and networks-based ACL traffic are forwarded through the best route derived from the the metrics value collected on ISP01, ISP02, and ISP03.