Configure DIA AnyPath

When your SD-WAN direct internet access (DIA) links from an ISP experience a blackout or brownout, you need those links to fail over to another link to ensure business continuity. DIA links can fail over to an MPLS link, but you may not have an MPLS link. DIA links must be able to fail over to another link that has a direct path or indirect path (through a hub or branch) to the internet; the DIA traffic can take any path available to get to the internet and isn’t restricted to DIA. DIA AnyPath supports a DIA link failing over to a private VPN tunnel going to a hub firewall to then reach the internet. Furthermore, if your topology is full mesh (branch-to-branch) and there is no hub, the DIA traffic can fail over to a branch firewall to reach the internet.

DIA AnyPath requires PAN-OS 10.0.3 or a later 10.0 release and SD-WAN Plugin 2.0.1 or a later 2.0 release.

There are several use cases for wanting an internet link to fail over to a VPN tunnel (DIA AnyPath):

• You want to transition away from an expensive MPLS link to one or more public internet connections, usually from different vendors.
• You have multiple hubs in a VPN cluster to allow a waterfall-type of failover from the primary hub to a succession of backup hubs.
• In a split tunneling scenario, you want only a particular bandwidth-intensive application to go directly to the internet through the branch’s DIA link instead of going back to the data center hub through the VPN tunnel, thus saving WAN bandwidth costs. In the event of a DIA brownout or blackout, this application traffic fails over to the data center hub to reach the internet; and if necessary can subsequently fail over to a second hub to reach the internet.
• In a different split tunneling scenario, you want most of your internet traffic to go out the DIA link rather than backhaul the traffic to the data center for internet breakout. However, you want specific applications (that may need additional scanning or logging by another security device) to go back to the data center. You create an SD-WAN policy rule to direct those applications to a primary path to the hub, rather than the normal DIA link as determined by the default route in the firewall’s route table. In the event of a brownout or blackout, those applications fail over to take the branch’s DIA interface.

DIA AnyPath introduces the concept of a principal virtual interface, which can include both DIA links and nested hub virtual interfaces and branch virtual interfaces (VPN tunnels) that each include their own links. The principal virtual interface can have a maximum of nine DIA (Ethernet) interfaces, hub virtual interfaces, and branch virtual interfaces. You assign a Link Tag to a hub when you add the hub device to Panorama. Assuming you use the SD-WAN plugin, Auto VPN assigns that Link Tag to the hub virtual interface, which allows you to specify the tag in a Traffic Distribution profile to control the failover order among virtual interfaces.

A principal virtual interface is referred to as a DIA-VIF in CLI commands.

A principal virtual interface can have interface members that belong to different Security zones. However, the best practice is to have all member interfaces in the principal virtual interface belong to the same Security zone. Another best practice is to have at least one member interface in the principal virtual interface be of the link type Ethernet, Cable mode, ADSL, Fiber, LTE, or WiFi.

The following topology example shows Branch1 with two ISP connections and an MPLS link. Branch1 also has a Hub1 virtual interface with three VPN tunnels connecting to Hub1, and a Hub2 virtual interface of three VPN tunnels connecting to Hub2. Branch1 also has a branch2 virtual interface with three VPN tunnels connecting to Branch2 and a branch3 virtual interface with three VPN tunnels connecting to Branch3. The goal of DIA AnyPath is to configure the order in which DIA can fail over to VPN tunnels to reach the internet directly or indirectly and thus maintain business continuity.

When you configure a principal virtual interface, it automatically becomes the default route so that internet traffic is routed properly to any of the members of the principal virtual interface (both DIA links and VPN tunnels). The path selection is based on SD-WAN Path Quality profiles and Traffic Distribution profiles, which you would set to use the Top Down Priority distribution method to control the failover order. In the example topology, a Traffic Distribution profile can list the tag for the principal virtual interface first, then the tag for the Hub1 virtual interface, and then the tag for the Hub2 virtual interface.

Zooming in to a deeper level of failover priority, a hub virtual interface has multiple tunnel members, so you need a way to prioritize the failover order of the members, such as prioritizing that a broadband VPN tunnel be used before an LTE VPN tunnel. You specify the priority using the VPN Failover Metric in the SD-WAN Interface Profile that you apply to the Ethernet interface. The lower the metric value, the higher the priority for the tunnel to be selected upon failover. In the topology example, in the Hub1 virtual interface, a lower VPN Failover Metric for t11 than for t12 causes internet traffic to fail over to t11 before t12. If multiple tunnels in a virtual interface have the same metric, SD-WAN sends new session traffic to the tunnels in round-robin fashion.

1. Log in to the Panorama Web Interface.
2. Specify the failover priority for a VPN tunnel bundled in a hub virtual interface or branch virtual interface.

   1. Select or Configure an SD-WAN Interface Profile.

      Best Practice is to configure at least one interface with the link type of Ethernet, Cable modem, ADSL, Fiber, LTE, or WiFi.
   2. You must enable VPN Data Tunnel Support.
   3. Specify the VPN Failover Metric for a VPN tunnel; range is 1 to 65,535; default is 10. The lower the metric value, the higher the priority of VPN tunnel (link) where you apply this profile.

      For example, set the metric to a low value and apply the profile to a broadband interface; then create a different profile that sets a high metric to apply to an expensive LTE interface to ensure it is used only after broadband has failed over.

      If you have only one link at the hub, that link supports all of the virtual interfaces and DIA traffic. If you want to use the link types in a specific order, you must apply a Traffic Distribution profile to the hub that specifies Top Down Priority, and then order the Link Tags to specify the preferred order. If you apply a Traffic Distribution profile that instead specifies Best Available Path, the firewall will use the link, regardless of cost, to choose the best performing path to the branch. In summary, Link Tags in a Traffic Distribution profile. the Link Tag applied to a hub virtual interface (Step 6 in this task), and a VPN Failover Metric work only when the Traffic Distribution profile specifies Top Down Priority.

   4. Click OK.
3. Configure a Physical Ethernet Interface for SD-WAN and on the SD-WAN tab, apply the SD-WAN Interface Profile you created in the prior step.

   Best Practice is to have all interfaces in the principal virtual interface belong to the same Security zone.
4. Repeat Steps 2 and 3 to configure additional SD-WAN Interface Profiles with a different VPN failover metric and apply the profiles to different Ethernet interfaces to determine the order in which failover occurs to the links.
5. Create a Link Tag for a hub virtual interface.
6. Add the Link Tag to a hub that you want to participate in DIA AnyPath.

   1. In PanoramaSD-WANDevices, Add an SD-WAN Device to add a hub to be managed by Panorama.
   2. Select the hub.
   3. Select the Link Tag that you created in the prior step, which Auto VPN applies to the whole hub virtual interface, not an individual link. Thus, you can reference this Link Tag in the Traffic Distribution Profile to indicate the hub virtual interface for the failover order for DIA AnyPath. On the branch device, Auto VPN uses this tag to populate the Link Tag field on the SD-WAN virtual interface that terminates on the hub device.

   4. Click OK.
7. Repeat Steps 5 and 6 to create a Link Tag for each hub virtual interface and add the tag to each hub that will participate in DIA AnyPath. Do the same for any branch virtual interface.
8. Create a Traffic Distribution Profile to implement DIA AnyPath.

   1. Create a Traffic Distribution Profile.
   2. Select Top Down Priority.
   3. Add the Link Tags so they appear in the order that you want their associated links used for failover.

      For example, if your use case is for certain applications to use DIA first, list the DIA tag first, then a hub virtual interface tag, then a second hub virtual interface tag. If your use case is for certain applications to first go to the hub and then the internet, list a hub virtual interface first, then perhaps a second hub virtual interface, and list a DIA tag last. If you have full mesh with no hub, use the DIA tag and branch virtual interface tags in the order you want.
9. Create identically named SaaS Quality profiles for both the hub and branch firewalls.

   Two identically named SaaS Quality profiles must be configured on the hub and branch firewalls to successfully leverage the hub firewall as an alternative failover.

   The easiest way to configure failover to a hub firewall with the same SaaS application destination is to create a single SaaS Quality profile in the Shared device group. Alternatively, you can create two SaaS Quality profiles with identical names in different device groups and push them to your hub and branch firewalls.

   To failover to a hub firewall with different SaaS application destinations, create two SaaS Quality profiles with identical names each pointing to a different SaaS application destination in different device groups and push them to your hub and branch firewalls.

   You must also create an SD-WAN policy rule that references this SaaS Quality profile in order to allow the hub to advertise link quality statistics for the SaaS Quality profile to the branch. Doing so will provide end-to-end SaaS monitoring through the hub. Without this SD-WAN policy rule, you would have only the link measurements from the branch to the hub, but not from the hub to the SaaS application.
10. Allow the hubs to participate in DIA AnyPath.

    1. Create a VPN Cluster and select a hub.
    2. Select Allow DIA VPN for the hub. A maximum of four hubs in a VPN cluster can participate in DIA AnyPath. If they are HA hubs, a total of eight hubs are supported. If you Allow DIA VPN for one HA peer in a pair, you must also enable it for the other HA peer.

11. Create an SD-WAN policy rule for specific application(s) to use DIA AnyPath.

    1. Configure an SD-WAN Policy Rule.
    2. On the Application/Service tab, specify the applications and services for which you want to implement DIA AnyPath.
    3. Associate the SaaS Quality Profile you created in the previous step.

       If you are configuring a SaaS Quality profile with different SaaS application destination, you must associate the SaaS Quality profile with the SD-WAN policy rule in each branch and hub device group.
    4. On the Path Selection tab, select the Traffic Distribution Profile you created for the applications.
12. Route new sessions that don’t match any SD-WAN policy rule and sessions that arrive during a Panorama or firewall configuration change.

    1. Create an appropriate Path Quality profile and Traffic Distribution profile to handle such sessions.
    2. Configure an SD-WAN Policy Rule that is a catch-all rule for these sessions.
    3. Place the rule last in the list.
13. Commit and Push to Devices.
14. Create a Security Policy Rule to allow DIA traffic to the Destination Zones named zone-internet and zone-to-hub and specify the Applications subject to the rule. Commit and push to the branches.
15. Use the following CLI commands to monitor DIA information:

    1. show sdwan connection <dia-vif-name>
    2. show sdwan path-monitor stats dia-vif all
    3. show sdwan path-monitor dia-anypath
    4. show sdwan path-monitor dia-anypath packet-buffer all
    5. show sdwan path-monitor stats conn-idx <IDX>