Securing Your Cloud Connections

Our customers often have questions about the Megaport network, in relation to our level of routing stability, throughput, and isolation provided by our MPLS backbone. Recently our customers have been asking how to architect an IPSEC encrypted tunnel between a Megaport-enabled customer location, and one or more public cloud platforms. This post will cover some of the details on how to best configure this within your environment.

Microsoft Azure via ExpressRoute

Microsoft Azure uses the concept of a VPN Gateway construct, or the Azure Virtual Network Gateway (VNG). These gateways are used to send network traffic between virtual networks and on premise locations. To configure an Azure VNG it’s firstly a requirement to create a gateway subnet for your VNet with the name GatewaySubnet (in order to correctly route traffic). Subnet sizing varies and although it is possible to create a gateway subnet as small as a /29, it is generally recommended that a /28 or larger IP space is created to allow for future expansion and mapping.

Configuring an Azure VNG requires the gateway SKU type to be specified. There are three Azure VNG SKUs: Basic, Standard, and High Performance. Basic provides for 100 Mbps of VPN throughput or 500 Mbps of ExpressRoute throughput. Because it doesn’t allow for coexistence of the two connection methodologies, it is not recommended for anything other than a small non-IPSEC secured ExpressRoute connection or an Internet connected VPN circuit to Azure. The Standard SKU provides for 100Mbps of VPN throughput and 1000 Mbps of ExpressRoute throughput, allowing coexistence of the two connections, as does the High Performance SKU which provides for 200 Mbps of VPN throughput and 2000 Mbps of ExpressRoute throughput. The High Performance SKU also allows a maximum of 30 IPSEC tunnels where the Basic and Standard SKUs only allow for a maximum of 10 tunnels each.

Details on supported CPE devices and specific IKE Phase 1 and 2 technical setup details are available here. Note the Route-based Gateway IPSEC Security Association (SA) Offers table, which indicates the cypher suite lists that will be evaluated based on whether the Azure VNG is the initiator or the responder to the request. The most secure methodology is AES256-SHA, which is offered when the Azure VNG is the initiator. The actual cypher suite will be agreed based on path initiation direction and capability sets on both sides of the IPSEC tunnel connection.

Up to date pricing information on Azure VNG SKUs is available here. Azure VNG hourly costs are charged in addition to the port hourly costs on the Microsoft ExpressRoute connection itself, and are levied directly by Microsoft. Throughput for an IPSEC secured tunnel will be different to a non-IPSEC tunnel due to encryption overheads, the Azure VNG SKU selected, and the choice and implementation of CPE that performs the IPSEC encapsulation. Refer to vendor supplied information on the maximum number of tunnels that can be run simultaneously and the maximum throughput limitations and size accordingly based on your network requirements.

Amazon Web Services via Direct Connect

By using Amazon Web Services (AWS) Direct Connect and IPSEC VPN tunnels, connections delivered via Megaport can be combined with an Amazon VPC hardware VPN termination point. This combination provides an IPSEC-encrypted private connection that also reduces network costs, increase bandwidth throughput, and provide a more consistent network experience than an Internet-based VPN connection.

AWS Direct Connects via Megaport can be used to establish a dedicated network connection to public AWS resources, such as an Amazon VGW IPSEC endpoint. This solution combines the AWS-managed VPN solution with lower latency, increased bandwidth, and an end-to-end secure IPSEC tunnel connection.

Source: Amazon Web Services

Unlike the Azure IPSEC gateway, a VPN tunnel connection created with an AWS VGW IPSEC VPN will only become live when traffic is generated from the initiator’s side of the VPN connection. Creating a parallel pair of IPSEC connected tunnels is therefore recommended across a single AWS Direct Connect instance to allow for AWS routine maintenance which may disable one of the two tunnels of the VPN connection. A redundantly configured VPN connection will automatically enable a fail over to the second tunnel during maintenance.

AWS does not enforce any restrictions on VPN throughput based on selection of a Virtual Gateway (VGW) sizing construct, nor does it publish a given maximum supported figure for the IPSEC termination endpoint. A single per-hourly charge is levied on all VGW IPSEC terminations above and beyond the standard AWS Direct Connect port hourly rates, which are waived by Megaport in most markets worldwide. Limitations that might impact IPSEC VPN connectivity throughput include: the cryptographic capabilities of the selected CPE/cloud, the capacity of your AWS Direct Connect link, average packet size, the protocols in use (eg TCP vs. UDP), as well as any already in place session-based encryption (eg SSL for HTTPS). The AWS VGW IPSEC gateway limits a maximum of 10 VPN connections per VPC as standard. However this can be changed on request.

Google Cloud Platform via Google Carrier Interconnect

Google Cloud Platform (GCP) also supports IPSEC tunnels, however the way it delivers a direct connection to its GCP platform via Google Carrier Interconnect (GCI) differs from the methods used by AWS and Azure. Google only provides Border Gateway Protocol (BGP) sessions to the service provider (Megaport in this case), which runs an iBGP mesh to route the traffic between subscribers on the Megaport fabric and the Google network. Therefore, private IP addressing is not directly accessible via GCI.

Google Cloud VPN service is the generally available method of terminating IPSEC tunnels on the Google Cloud Platform. It offers a 99.9% availability target (SLA) and supports site-to-site VPN constructs using static routes only. It’s also possible to use Google Cloud VPN to connect two different Google Cloud Platform networks or regions.

Google Cloud Router is a service currently in beta that enables dynamic BGP routing updates between the Google Cloud Platform network and an on premise network. The Google Cloud Router beta offering works with both legacy networks and subnetworks. There are some hard-coded limits however the flexibility of automated route updates rather than requiring a restart of the VPN mesh will generally outweigh these in most environments.

Software VPN instances – generic public cloud option

There is another option that may be more appropriate for some customers based on in house technical capability, encryption demands, and scaling requirements. Default abilities of public cloud providers to run a virtual machine environment means there are various software VPN deployments available; both as pre-configured virtual instances via the respective public cloud market places, or as disk/hypervisor images from popular networking vendors. Setup and configuration of such a termination endpoint for cloud encryption gives more flexibility for end users seeking a tailored solution, and some of these instances can also provide flexible licensing models.

Advantages include the ability to scale vertically, as well as additional services such as NAT/Proxy functionality. Disadvantages include complexity to setup in a highly available configuration as these types of deployments require broadcast or multicast support not often available within public cloud environments. There is also extra overhead in monitoring management, vNet/VPC routing considerations, as well as extra support requirement overheads and system upgrades/patching. These are usually included in the pricing model provided by the public cloud hardware IPSEC VPN instances.

All of the above factors must be kept top of mind when weighing total cost of ownership for a self-managed solution vs a cloud provider managed IPSEC VPN termination solution.

If you have any questions about securing your cloud connections, please feel free to get in touch with one of our Solutions Architects using the form below: