Tunnel Orchestrator

The Overlay Tunnel Orchestrator (OTO) service architecture defines the working model of Tunnel Orchestrator service between Aruba Gateways and APs.

Aruba supports automated Tunnel Orchestrator for LAN Tunnels service for APs and Gateways deployed in campus WLAN. Based on the location of the devices, the tunnel orchestrator service establishes either GRE tunnels (at the branch site) or IPsec tunnels between Gateways and APs provisioned in an Aruba Central account (This has been described in greater detail in the following sections). The tunnel orchestrator service along with AP Tunnel Agent and Gateway Tunnel Agent creates and maintains the tunnels between APs and Gateways.

The Tunnel Orchestrator for LAN Tunnels service can be enabled either globally or on individual device groups. By default, the Tunnel Orchestrator for LAN Tunnels service is enabled for Gateways and AP devices provisioned in an Aruba Central account. The tunnel orchestrator automatically builds a tunnel mode network based on the tunnel endpoint preference that you configure in the WLAN SSID. The tunnel orchestrator selects the Gateway-AP pairs and decides the number of tunnels between the Gateway cluster and APs based on the virtual AP configuration.

Working

The Tunnel Orchestrator service leverages the Tunnel Orchestrator service of Aruba SD-WAN solution released in 2018. In ArubaOS 8, the tunnels between gateways and APs were built through the legacy IPsec process: Both end devices go through IKE phase 1 and phase 2 to authenticate each other, negotiate authentication method and timers, and generate encryption keys used for data traffic.

In ArubaOS 10, each gateway and AP pair does not directly go through IKE phase 1 and phase 2 to establish an IPsec tunnel between the gateway and the AP. Instead, the whole tunnel setup function is moved to the Tunnel Orchestrator service in Aruba Central which is responsible for generating the session keys and SPIs for the gateway and AP pair. These session keys are used to control traffic encryption between the AP and the gateway.

The different parts of the legacy IKE phase 1 process, such as authentication and encryption, timer negotiation, SPI pair generation, and encryption keys generation are skipped in the Tunnel Orchestrator service because all the gateways and APs are registered and subscribed in Aruba Central are treated as trusted entities. Secondly, the encryption policy and timers used by Aruba gateways and APs are hardcoded, there is no negotiation required. In ArubaOS 10, the tunnel orchestrator completely takes over the job of the IKE process and generates the keys and SPIs used for the IPsec tunnels. The Tunnel Orchestrator service not only simplifies the configuration model and device software, but also increases the performance and scalability of the whole network.

AP Tunnel Agent and Gateway Tunnel Agent

The AP Tunnel Agent (ATA) and Gateway Tunnel Agent are the tunnel management modules in APs and Gateways respectively. They are responsible for handling all GRE and IPsec tunnel configurations and maintaining the status in APs and Gateways. ATA and Gateway Tunnel Agent provide the following functions:

• Register the information of APs and Gateways with tunnel orchestrator service.

• Receive Gateway cluster and tunnel information and distribute to other processes.

• Create and maintain IPsec and GRE tunnel and survivability status.

Use Cases of Tunnel Orchestrator

In ArubaOS 10, there are two scenarios where the tunnel orchestrator orchestrates tunnels for a pair of end points:

APs and Gateways in a Campus Network

When a tunnel or mixed mode SSID is configured, tunnel orchestrator orchestrates an IPsec tunnel and a GRE tunnel between each AP in the AP group and each gateway member in the gateway cluster. For example, in a case of one AP and two gateways in a cluster as what is shown in the following diagram: the tunnel orchestrator orchestrates one IPsec tunnel and one GRE tunnel between the AP and the first gateway, and one IPsec tunnel and one GRE tunnel between the AP and the second gateway. The IPsec tunnel is used for control traffic between the AP and the gateway, such as bucketmap and nodelist updates. The GRE tunnel is used for user data traffic from all the configured SSIDs on the AP. The GRE tunnel is not encrypted by the IPsec tunnel to avoid double encryption and performance degradation. The security of user traffic is guaranteed by the encryption method used in the SSID.

Micro Branch APs and Gateways for Remote Offices and Teleworkers

In a Micro Branch deployment, the GRE tunnel is encrypted by the IPsec tunnel. Since the data traffic between the AP and gateway goes through the WAN network, extra encryption becomes necessary.

Tunnel Orchestrator Workflow for Creation of Tunnel or Mixed WLAN SSIDs

By now, we know that the tunnels are created between gateways and APs as soon as a tunneled SSID or a mixed SSID is created. At the time of this type of SSID creation, the user needs to select the gateway cluster to which the APs will form a tunnel to. Eventually this will tunnel all the wireless client traffic to the gateway cluster.

The process is automated to the extent that when a new AP or a gateway is added to the existing groups, Tunnel Orchestrator service will automatically build all the relevant new tunnels between all the devices.

If we were to look at the step-by-step workflow of the entire orchestration process when a new tunnel or mixed mode SSID is to be configured, it would include the following:

1. Tunnel SSID or mixed mode SSID is configured, and the service configuration module notifies the Tunnel Orchestrator.

2. The Tunnel Orchestrator queries the device configuration module about all the gateway members in the cluster on which the SSID terminates.

3. The Tunnel Orchestrator queries the group management module about all the APs in the AP group.

4. The Tunnel Orchestrator generates SPI and encryption keys of the IPsec tunnels and the GRE tunnels for each pair of AP and gateway member in the gateway cluster.

5. All the tunnel details are pushed to the gateways and APs.

Key Considerations

To allow APs and Gateways to automatically establish tunnel modes, ensure that the following configuration tasks are completed:

• Aruba Gateways are onboarded to a group in Aruba Central.

• Aruba APs are provisioned in Aruba Central.

• Aruba Gateways and APs are upgraded to ArubaOS 10.0.0.0 or a later software version.

• A WLAN SSID with the tunnel forwarding mode is configured on the APs. When you create a new SSID, you must select the primary cluster name or Gateway where you want to establish tunnel traffic of the SSID. Optionally, you can select the backup cluster that can be used when the primary cluster goes down completely. The APs establish tunnel with the Gateways in a Gateway cluster.

• If the overlay IPsec tunnels initiated by APs to a VPN Concentrator use NAT traversal, the UDP 4500 port is enabled.

IPsec SA Rekeying

IPsec SA is created with a finite lifetime to ensure security. The AP-Gateway IPsec SA lifetime is 36 hours. The rekeying process ensures that there is no data loss during rekeying. Before the SA expires, the Tunnel Orchestrator performs rekeying for all the IPsec SAs of AP-Gateway pairs.

The following workflow explains the Tunnel Orchestrator IPsec SA rekeying process:

1. Twelve hours before the IPsec lifetime expires, the Tunnel Orchestrator starts IPsec SA rekeying and orchestrates new keys for AP-Gateway pairs.

2. New keys are pushed to the AP-Gateway pairs.

3. The gateway examines temporary ingress tunnels in learning mode.

4. The AP sends a probe encrypted with the new key.

5. Parallelly, all the control traffic is still exchanged between the AP and the gateway through the old IPsec tunnel.

6. After the gateway successfully decrypts the probe message with the new key, the gateway removes.

7. temporary learning mode tunnel and installs new ingress and egress tunnels with the new key.

8. The gateway sends a probe response to the AP.

9. The AP removes the temporary learning mode tunnel and installs new ingress and egress tunnels with the new keys.

10. The old tunnels remain active for 10 seconds for transient traffic.

11. All the control traffic is switched to the new tunnels.

12. Both the AP and the gateway age out the old tunnels.

Cloud Survivability for Tunnel Orchestrator

Survivability is a feature to mitigate the IPSec traffic between Aruba devices whose IPsec tunnels are orchestrated by Cloud and has a definite key expiration time when the cloud connectivity fails for any unknown reason and the devices have still connectivity between them. With survivability, the devices should be able to re-establish IPSec tunnels between them based on the tunnel config which they have already received from Tunnel Orchestrator using the legacy IKE/IPSec tunnel establishment.

During the rekey phase, if cloud connectivity is lost, the devices will seamlessly switch over to legacy IPSec tunnels. Survivability can be triggered during the following situations:

• Either side of the tunnel has no connectivity to Tunnel Orchestrator

• Tunnel Orchestrator pushes new keys to APs and gateways, but they are not received

• Tunnel Orchestrator does not push new key to APs or gateways

• The devices are not able to bring up tunnels using received keys

Cryptomaps for all the tunnel config received are created irrespective of Initiator/Responder. But on the initiator side, cryptomaps are in disabled state. After 9 retries to bring the rekey tunnel up, cryptoMap on the initiators side will be enabled for the survival tunnel to be triggered.

Once the survivability tunnel is up, the same process will be started again during rekey.