Table of contents
- Virtual Gateway Deployment in Google Cloud
All Devices managed by Aruba Central authenticate and secure their communication by performing a certificate-based mutual authentication. Aruba Central presents it’s Server Certificate and, in exchange, the managed device (in this case, the vGW) present their own certificate to prove their identity. Hardware devices (APs, Switches and Gateways) come with a factory TPM that facilitates this, but virtual devices (such as the vGW) need to obtain their certificate (and their identity) by means of another mechanism.
The first step is therefore to generate a device identity in Aruba Central. This includes serial number, MAC address, Device Model, etc. It also includes a “one time password” to automatically retrieve their own certificate by doing an EST enrollment against Aruba’s Certificate Authority. Lastly, as part of this process, a Virtual Gateway subscription is applied to the vGW that’s being provisioned (automatically drawn from the license pool).
Generating this Device Identity (which will trigger the subscription assignment) can be done from Network Services > Virtual Gateways > Config > Unmanaged. Once the Device Identity has been generated, it can be downloaded in txt/iso file by simply clicking on the “Userdata Generated” string. This data will be necessary further along the process.
As described in the deployment section, vGWs in Google Cloud will have 4 interfaces; ; Management (MNG), Internet Access (INET), Cloud Interconnect (VPN) and LAN or Transit VPC (LAN). Each VPC should have at least one subnet, which is where the vGW will be attached.
Each one of those 4 interfaces must be connected to a different subnet, each one residing in different VPCs. When deploying vGWs across multiple regions it’s recommended that these connect to different subnets belonging to the same global VPCs (vgw-mgmt-vpc, vgw-inet-vpc, etc). The GCP NIC to vGW VLAN/port mapping should be the following:
|GCP Interface||vGW port||vGW VLAN ID||Function|
|nic1||Gigabit Ethernet 0/0/0||4094||Internet Access (INET)|
|nic2||Gigabit Ethernet 0/0/1||4093||Cloud Interconnect (VPN)|
|Nic3||Gigabit Ethernet 0/0/2||4092||LAN or Transit VPC (LAN)|
To create the different VPCs and subnets in GCP, simply follow these steps:
First, from your GCP Project, go to Networking > VPC Network > VPC Networks and click “Create VPC network”.
This will open a menu where the VPC and its subnets are defined. One characteristic of GCP is that VPCs are global elements that span across regions, and subnets are confined to a particular region. This means that, in a global deployment, it’s common to have a global VPC for the internet connectivity of all vGWs, with interconnect subnets in all regions where vGWs are deployed.
The VPCs associated to Internet, Management and Cloud Interconnect can be set to use “Regional” Dynamic Routing mode, as the subnets are only used by the vGWs as interconnections and don’t need to be routable across regions. The LAN (or Transit) VPC, however, should be set to use “Global” dynamic routing whenever NCC is used to establish branch to branch communications (more details in the NCC-specific section).
At this point, we should have 4 VPCs, each one of them with a subnet where the vGW will connected. GCP implements Firewall policies as part of the VPC configuration, as if it was the case of a traditional “Firewall Zone”. To allow communication to and from the vGWs (once deployed), the corresponding firewall rules will have to be created. Detailed information about how to create firewall rules is available in the GCP documentation. Below are the key steps that should be followed.
This can be done from the configuration pages of the VPCs themselves, by going to the “Firewall Rules” tab in the lower part of the screen:
Or it can also be done in a common location for all VPCs by going to Networking > VPC Network > Firewall. It’s important to note that these firewall policies always have to be tied to a VPC.
Regardless of whether these policies are configured in the VPC configuration page or globally, it’s important to ensure that inbound NAT-Transversal traffic (UDP 4500) is allowed in the Internet and VPN interfaces of the vGW, as that will be needed to establish the SD-WAN overlay between Branch Gateways and vGWs. Likewise, Aruba vGWs need to be able to communicate from their INET interface with Aruba Central, as well as other associated services. This is documented in detail as part of the documentation in Aruba Central.
The second step is to upload the vGW image to GCP. The vGW image can be downloaded from the Aruba Support Portal. For google cloud, the right format is the one ending in “.img.tar.gz”.
This image can then be uploaded to the right GCP project by going to Project > Storage > Cloud Storage and into the right bucket. To create a bucket, use the following parameters:
Step 1 Enter a name for the bucket.
Step 2 Set “Region” as the location type and provide a location.
Step 3 Set “Standard” as the Storage Class.
Step 4 Set the Access Control to “Fine Grained”
Step 5 Under “Advanced Settings”, set the Encryption to “Google-managed key”
Once a bucket with the right attributes is created, the vGW image can be uploaded. After doing so, it’s advisable to check the “source uri” for the image, as this will be needed shortly after. This can be obtained by clicking on the image itself and copying the “gsutil URI” field.
With the software loaded in Aruba Central, the next step is to bring up the Virtual Gateway Image in GCP. The key aspect about this is to enable “MULTI-IP-SUBNET” as an attribute of the virtual machine. As described, the vGW is a router that needs to be connected to multiple subnets in different VPCs.
This can be done from the GCP Cloud Shell directly from a web browser or using the any terminal application by making use of the GCP Cloud SDK. The specific commands are the same with either mechanism.
gcloud compute images create <image-name> --project=<project-name> --source-uri=<URL to tar.gz file> --storage-location=<location> --guest-os-features MULTI_IP_SUBNET
Issuing this command should result in the following:
Home$ gcloud compute images create vgw-ncc-europe-01 --project=sd-branch-ncc-testing --source-uri=gs://sd_branch_bucket/ArubaOS_VGW_220.127.116.11-18.104.22.168_79669.img.tar.gz --storage-location=us-west1 --guest-os-features MULTI_IP_SUBNET Created [https://www.googleapis.com/compute/v1/projects/sd-branch-ncc-testing/global/images/vgw-ncc-europe-01]. NAME PROJECT FAMILY DEPRECATED STATUS vgw-ncc-europe-01 sd-branch-ncc-testing READY Updates are available for some Cloud SDK components. To install them, please run: $ gcloud components update To take a quick anonymous survey, run: $ gcloud survey Home$
With the necessary networking components (VPC and Firewall rules) as well as the vGW image sorted out, the last step would be to configure (and start) the VM instance that will be the Aruba Virtual Gateway. This is done by creating an Instance under Compute > Compute Engine > VM Instances.
- In this page, the first step will be to select a name, region and zone for this VM.
- Then comes the Machine Configuration. An N2 General purpose VM should be used. For a vGW-500 we would select an “n2-standard-4” GCP Machine (sizing details can be found in the deploy section). For the boot disk we would use the recently created image, loaded on a new “Standard or persistent disk”:
Before clicking “Create”, a few additional parameters would have to be configured for this VM. In this same page, expand the “Networking, Disks, Security, Management, Sole-Tenancy” section:
- Under Networking, Mgmt, Internet, VPN and LAN interfaces have to be added (in this order). These interfaces must be connected to the previously created interconnect subnets. The Internet interface should be tied to ephemeral interfaces for the internal and external IP. The other three interfaces only need the ephemeral internal IP but not the external one.
- Under Disks, add a new disk with the following characteristics:
- Set the source type to Blank Disk
- Set the type to Standard Persistent Disk
- Set the size to 16GB
- All the other fields can be left with the default values
- If available, an ssh key can be provided in the Security section. This would allow the network administrator to log into the vGW via ssh before it has connected to Aruba Central. This is an optional step, as once the vGW is managed by Aruba Central, the remote access parameters can easily be modified.
- Finally, under Management, enter the User-Data information downloaded from Aruba Central. This is a key step, as it is what gives the vGW its identity and provides the information to retrieve its certificate to secure the communication with Aruba Central.
- Under Metadata, type “userdata” as the key and paste the information retrieved from central as the value.
- All other parameters can be left with their default configurations.
After following the steps outlined below, the vGW will be created in GCP. Once it boots up, it will automatically download its certificate from Aruba’s private CA using EST and will connect to Aruba Central automatically. From then on, all management, monitoring, etc. will be done from the Aruba Central UI:
As an advanced troubleshooting step, this process can be monitored by connecting to the device’s console through GCP. To do so, edit the virtual machine to “Enable connecting to serial ports”.
Once that has been enabled, you can click on “Connect to serial console” to see how the gateway automatically connects to Aruba Central. It’s important to note, however, that the provisioning process should not be interrupted.