The integration of Aruba SD-WAN and ZIA allows for a wide variety of scenarios. This section describes the most common ones, which are validated by Aruba. As called out above, both IPSec as well as GRE are supported integrations. Different scenarios are supported for IPSec/GRE.
Table of contents
Branch traffic is often aggregated at a local hub and then routed to the Internet or to other corporate resources. This case is especially common when using private WAN networks. In such scenarios, Aruba VPNCs can set up tunnels to the nearest ZIA Service Edge to have branch traffic go through additional security validations.
Aruba Branch Gateways (BGWs) can establish IPSec tunnels to one (or ideally two) ZIA Public Service Edges nodes from as many as four uplink interfaces to secure user traffic going to public cloud services or to the Internet, thus providing high availability. The solution supports manually setting destination ZIA Public Service Edge for each BGW. It also provides the possibility of having the SD-WAN Orchestrator learn the closest two nodes for each branch location and automatically establish tunnels to them.
An equivalent solution is also available for Microbranch, although in this case only with support for orchestrated tunnels, and with a smaller number of active uplink interefaces.
When redundancy is required inside the branch, Branch Gateways can share uplink interfaces with their HA pairs. This is done by establishing a virtual uplink through the LAN to share such interfaces. The result, as shown in the image below, is that each Branch Gateway would have “physical” uplinks as well as “virtual” uplinks.
In a scenario like this, each Branch Gateway establishes tunnels to the ZIA service through all uplink interfaces (physical and virtual). Both BGWs can be defined in ZIA as a single “Location” and use the same VPN credentials, or as two “Locations” with different credentials for each Gateway. Both operating modes are supported.
As shown in the Branch to ZIA reference drawings, load-balancing and Dynamic Path Selection mechanisms would take care of WAN circuit redundancy. However, that may not be sufficient in the unlikely event that a ZIA Public Service Edge would become unavailable. In order to address that, the SD-Branch or Microbranch integration with ZIA makes use of L7 probes sent to ZIA nod es as well as Dead Peer Detection (DPD) protocol to ensure traffic doesn’t get blackholed.
Moreover, when the orchestration is enabled, Aruba Central constantly monitors the availability of ZIA Service Edges to always have each Gateway or Microbranch connected to the closest nodes.
Note: Tunnels to redundant ZIA nodes are supported for all topologies displayed above; Branch Gateways to ZIA, Microbranch to ZIA, and Headend Gateways to ZIA.
As described above, gateways would establish GRE tunnels to two ZIA Public Service Edges (ideally, for redundancy purposes). GRE tunnels would then be grouped into a GRE Tunnel Group to handle failover automatically.
When a GRE Tunnel group is established, Gateways send traffic over the active tunnel. GRE Tunnel Keepalives are needed to provide failover. Once the GRE tunnels are grouped together, if the active tunnel were to go down, traffic would be seamlessly forwarded through the next tunnel in the group. Aruba Gateways support up to 4 GRE tunnels in a tunnel group, with only one being active at a given time.
When GRE tunnels are used to integrate with the ZIA service, tunnels would be created to two ZIA Public Service Edges from a maximum of 2 uplink interfaces. This would add up to a total of 4 GRE tunnels inside the Tunnel Group. Once the Tunnel-Group is created, traffic would be selectively redirected to it using PBR policies.
In the same sense that Branch Gateways can use GRE tunnels to integrate with the ZIA service, VPNCs can also do so. Branch traffic is often aggregated at a local hub before being sent to the Internet, this use-case becomes especially relevant when private WAN circuits are in use.
To provide redundancy in a given location (branch or hub), Tunnel Groups would have to be created from every gateway. As a recommended best-practice, upstream traffic should only come from a single gateway at a time.
Note: Uplink sharing would require that both BGWs would share the same public IP address, which is not something that can be supported with GRE tunnels. It is therefore mandatory that, when using GRE tunnels, each gateway must be connected to all Internet-facing uplinks, with a unique publicly routable IP address in every uplink.