Word Count: 1,240
AWS Transit VPC
Welcome to a new edition of our blog series “AWS Transit VPC inside AWS using Juniper vSRX”.
This blog is part 3 of a series of 4 blog posts on the topic of AWS Transit VPCs. In this series, we cover the following topics:
- Introduction to AWS Transit VPCs
- The use cases of AWS Transit VPCs
- The way AWS Transit VPCs are configured
- Why we chose Juniper vSRX as our hub firewall
- How we pieced it all together
In the previous blog posts (parts 1 and 2), we talked about what is Transit VPC, and at a high level how it was pieced together using the automation aspects of the AWS Transit VPC solutions – the CloudFormation and Lambda services inside AWS. In this article, we discuss how we implemented the Juniper Transit VPC solution using CloudFormation and Lambda.
To create this customized solution, we started with three main components:
- A customized CloudFormation template to create all the AWS Transit VPC artifacts inside AWS
- A customized Lambda function to poll the Virtual Private Gateways (VGWs) at specific intervals checking for the desired tags
- A customized Lambda function to pull Junos configuration saved inside S3 buckets and push the configuration to the vSRX instances.
These three customized components were provided to us by Juniper Networks.
In summary, we implemented this solution using the modified JSON based CloudFormation template (shared with us by Juniper), along with the VGW Poller Lambda function and Juniper Configurator Lambda function, which are Python scripts modified to run using Boto3 inside the AWS Lambda construct. This implementation took place in three phases: Prerequisites, Deploying the AWS Transit VPC using CloudFormation, and the Spoke VPCs and Peripherals.
Let us start with the prerequisites – preparing the user’s AWS account to handle AWS Transit VPC solution using vSRX instances. This includes verifying and confirming service limits inside AWS. The minimum requirements for deploying an AWS Transit VPC in each region are:
- 1 VPC
- 4 subnets
- 4 Elastic IP addresses (2 each per vSRX instance)
- 2 c4.xlarge instances
- 3 Security Groups
- 1 Security Key Pair
- 4 Elastic Network Interfaces (2 each per vSRX instance)
- 1 Internet Gateway
- 1 Route Table
- 1 VPC Endpoint
- 1 VPC Network ACL
Also needed is verifying that the AWS Region in which you are planning to create the AWS Transit VPC supports creating and running Lambda functions. The list of Lambda supported AWS Regions can be found at right here.
Other prerequisites for this solution include accepting the terms and conditions inside AWS Marketplace for the vSRX Next-Generation Firewall Bundle 2 AMI. During our deployment and testing, we used the vSRX AMI with the version 15.1X49-D70. New versions are released regularly; it is likely that newer versions will support a majority or all of the functionalities needed for the scenario described.
IAM permissions are required to enable and deploy the solution using CloudFormation. Also required is creating and downloading a Security Key pair for the selected AWS Region in which to deploy the Transit VPC. This Security Key is used to log into the instances by the Configurator Lambda poller function to push configurations.
Before deploying the stack with CloudFormation, upload the Poller function Python script and the Configurator function ZIP archive to an S3 bucket inside your account. The paths to these two files will be referenced inside the CloudFormation JSON template under the subsection of Function under Mappings, in the containers called “Poller” and “Configurator” respectively.
Deploying the AWS Transit VPC using CloudFormation
Once the prerequisites are accomplished, the stack deployment process using the JSON-based CloudFormation template can be implemented. This is an easy process: upload the template using AWS Console, and then modify the parameters to start the stack deployment process.
Using CloudFormation for stack deployment starts the creation of the Resources (components for the AWS Transit VPC), viz. VPC CIDR, Subnets, Internet Gateway, Security Groups, vSRX instances, Lambda functions, CloudWatch logs, and CloudWatch trigger rule. Normally, these resources are created without errors.
Once the stack is created, upload the Security Key (.pem) file to the S3 bucket, and replace the Security Key with the existing prikey.pem file with the correct AWS KMS encryption. This step enables the Configurator function to log into the vSRX instances and commit configuration changes for the Spoke VPCs that shall be created by the scale testing script. The Security Groups created by the CloudFormation template need to be modified to allow all traffic inbound and outbound from everywhere. The policies built inside the vSRX instances are left to continue handling the permissions of those allowed to log in and issue operational mode commands or modify configuration on the instances.
Some manual configuration changes are necessary to prepare the vSRX instances to receive inbound connections via the Configurator. The Configurator would be used to push IPSec VPN and BGP configurations created and stored inside S3 buckets as a result of VGW Poller identifying the Virtual Private Gateway having the desired tags. These manual configuration changes are for:
- Getting the ge-0/0/0 interface ready with family inet with the IP address of eth1 of the vSRX instance found inside AWS Console
- Associating the ge-0/0/0 interface with a routing-instance of type virtual-router on the vSRX, creating some global inter-zone policies for enabling the Spoke VPCs to Spoke VPCs and Spoke VPCs to Data Center communication
After completing the configurations, the vSRX instance is ready to be used in conjunction with Spoke VPCs.
Spoke VPCs and Peripherals
Once the CloudFormation stack is deployed and the vSRX instances have been set up to accept configuration changes pushed by the Configuration Lambda function, set up the peripherals – Spoke VPCs, and GRE Tunnels towards the on-premise corporate data center.
For the Spoke VPCs, the VPC CIDR, Public and Private Subnets are created inside the VPC, Internet Gateway, Virtual Private Gateway, associate the Public and Private subnets of the VPC with Internet Gateways and Virtual Private Gateways. Once the Spoke VPC is created with the expected tag, as an example “transitvpc:spoke = true”, the cron job inside CloudWatch rule notes this change and triggers the VGW Poller Lambda function. The VGW Poller creates the VPN Connections towards the vSRX instance’s ge-0/0/0 interface and dumps the XML configuration from the VPN Connection parameters in the S3 bucket. Detecting the new configuration file in the S3 bucket, the Juniper Configurator Lambda function pushes the Junos configuration to the vSRX instances over an SSH connection and commits it.
The successful commit brings up IPSec VPN tunnels towards the VGW of the Spoke VPC and establishes BGP peering session for dynamic routing over the IPSec VPN tunnels. This enables using vSRX instances as the Hub for Spoke-to-Spoke communication.
The final step is configuring and bringing up GRE tunnels from each vSRX instance towards the on-premise data center router. Over these GRE tunnels, proceed to configure and establish BGP peering sessions for dynamic routing.
The procedures we described built artifacts inside AWS and accomplished the goal of making a successful Transit VPC solution using Juniper vSRX. For details, reach out to us at email@example.com.
In the next blog post, the conclusion of this four-part series, the following will be covered:
- Various use cases for AWS Transit VPC
- How we accomplished Scale Testing
To continue to Blog 4, click here.