This article outlines a solution for automating VPN failover using an AWS Lambda function, triggered by an Amazon CloudWatch event rule. The function monitors IPsec tunnel status changes for VPN connections to the Netskope Point of Presence (PoP). The automation ensures seamless failover to alternative PoPs in case of VPN failure, enhancing network resilience.

Overview

The solution deploys an AWS Lambda function that automatically responds to changes in VPN tunnel status for connections to the Netskope PoP. Triggered by an Amazon CloudWatch event rule, the function checks if both VPN tunnels to the Netskope PoP are down. If they are, the function scans all AWS Transit Gateway (TGW) route tables and replaces routes pointing to the downed VPN connections with static routes to a designated failover PoP.

This solution can be deployed in any AWS region and integrates with the AWS Global Network, utilizing Transit Gateway Network Manager to monitor and manage VPN connections.

Key Features:

• Per TGW Instance Deployment: One instance of this solution is required per TGW. The Lambda function can be customized to handle multiple TGWs or different groups of TGW attachments.
• Fallback Functionality: You can enable or disable a fallback feature. If enabled, the Lambda function will revert static routes back to the primary Netskope PoP when both IPsec tunnels are operational.
• Route Consistency Checks: In addition to reacting to tunnel status changes, the Lambda function is triggered every 10 minutes to ensure no routes are left pointing to a downed IPsec connection. This prevents potential race conditions caused by frequent tunnel bouncing.
• Concurrency Control: The solution ensures that only one Lambda function execution runs at a time to prevent inconsistent results. Concurrency is managed through a DynamoDB table created by the solution.
• IAM Role and Least Privilege Model: The CloudFormation template provisions an IAM role for the Lambda function, adhering to a least privilege access model. It limits access to only the TGW attachments and route tables associated with the specific TGW by using IAM policy conditions based on tags. All TGW attachments must be tagged with a "TGWName" key and corresponding TGW name value (e.g., Key="TGWName", Value="MyProdTGW-us-east-1").

Deployment and Configuration:

Step 1: Download the YAML Template

1. Download the yaml file from the github.
2. Do the required changes in the template and update all the below default parameters in the field according to your environment

Step 2: Update Parameters

• TGWRegion - The AWS region where your TGW is deployed
• TGWName - TGW name that will be used for access control. Your all TGW attachments must have an attribute "Key"="TGWName", "Value"="This parameter". For example, "MyProdTGW-us-east-1"
• TGWID - TGW ID. For example, tgw-01234567890123456
• TGWAttachmentID1 - TGW attachment ID for the first (primary) VPN. For example, tgw-attach-01234567890123456
• TGWAttachmentID2 - TGW attachment ID for the second (failover) VPN. For example, tgw-attach-01234567890123456
• TransitGatewayArn - TGW Arn which will be used while registering in the Network Manager with with Transit Gateway Network Manager
• Fallback - Yes/No for the route fallback support to the TGWAttachmentID1 if both of this IPsec tunnels became active.

Step 3: Prepare the S3 Bucket

Ensure you create an S3 bucket and folder to store the Lambda function in zip format, as downloaded from the GitHub link here.

Update the following fields in the CloudFormation template with your S3 bucket information:

• S3Bucket: Your S3 bucket name.
• S3Prefix: The folder path in your S3 bucket where the Lambda zip file is stored.

This automated solution simplifies the process of managing IPsec tunnel status changes for VPN connections to the Netskope PoP, providing automatic failover and route management. With AWS Lambda and Transit Gateway integration, your network remains resilient and operational even during tunnel failures.

For more details and to access the code, visit the GitHub repository.