The Virtual Private Gateway (VPG) is an important and useful solution of the AWS service suite. Using the VPG, however, is somewhat tricky and may require some specific expertise.
This short post is aimed at providing a quick overview of the AWS Virtual Private Gateway (VPG) solution. We will review the VPG concept, capabilities and limitations. In addition, you can download a step by step VPG configuration walkthrough with some verification on IPSec configuration.
We hope that this post will help AWS users to understand when they should use the VPG solution and how to make it work.
Additional information regarding AWS VPG can be found here
Introduction to VPG
AWS Virtual Private Gateway (VPG) is a solution offered as part of AWS VPC (Virtual Private Cloud) solution, The VPG provides AWS users with the capability to interconnect a VPC environment with an external remote non-VPC environment using IPSec tunneling. The most common use case for AWS VPG is connecting a private (and/or on-prem) datacenter with an AWS VPC.
An example for a simple VPG use-case is depicted in the following diagram
An organization wants to extend its private datacenter to an AWS VPC. The private datacenter’s network has CIDR block of 192.168.0.0/16 and the VPC was allocated with a 10.0.0.0/16 CIDR block.
VPG can be used to build and allocate two redundant IPSec tunnels connecting the VPC with an IPSec enabled device located on the private data-center. In the above example, the remote IPSec device has a public IP address, 188.8.131.52
VPG’s IPSec tunnels have the following characteristics:
- Protocol –IKEv1, IPSec (both ESP, IPsec/UDP are supported)
- Authentication method– only PSK (Pre Shared key) – the secret is automatically generated by AWS (can’t be provisioned into the VPG by the customer or changed). Refreshing the shared secret requires recreation of the VPG IPSec tunnels.
- Encryption and signing algorithms – only aes128-sha1 for both IKE and IPSec), PSK and DH group 2. No ability to change algorithms.
- Per connection AWS offers an option for an Active/Active setup based on two separated tunnels that also act as a redundant pair
- IKE lifetime – fixed and set to 24h
- IPSec lifetime – fixed and set to 1h
- Dead Pear Detection is enabled with timeout of 30 seconds
- Routing Protocols – Static or BGP
Although the VPG is a very useful tool, it has some significant limitations.
This section is aimed to help you decide whether or not the AWS VPG is the right solution for you.
Here are a few limitations of the current VPG solution:
- VPG cannot be used for interconnecting two VPCs – Technically, this is impossible since the PSK is dictated by AWS for each IPSec connection and can’t be provisioned.
- Multiple VPCs in the same region cannot be connected with the same remote IPSec device– Most of the VPG connections that are created within the same region will share the same VPG Public IP address (I believe that there are 2-3 pairs of public IP Addresses per region). Due to the way the connection is structured, AWS doesn’t allow two connections within the same region to be connected to the same “Customer Gateway” (even when using multiple accounts). Peering will not work here since peering is not transitive and doesn’t allow packets to be forwarded beyond the peered local network.
- EIP (Elastic IP) cannot be used with VPG connections – EIP is not part of the VPG implementation. There are few fixed IP addresses per region
- Per connection the number of SA (Security Association) is limited to 2 (this item is a bit technical)
- VPG implementation can only use one SA for IPSec. When using static routing, the IPSec connection offers the following subnets 0.0.0.0/0 çè0.0.0/0 as the local and remote subnets. This basically means IPSec will send/receive all traffic that is forward to/from the VPG.
- Many IPSec implementations are able to negotiate multiple subnets and use multiple SAs for each subnet permutation – this can’t be used with VPG. VPG becomes unstable if the peer device performs such negotiation with more than 1 subnet pair (the VPG will basically deploy only the last negotiated SA).
- Troubleshooting in the VPG environment is a bit challenging since an AWS user can’t access the AWS VPG and pull logs and must rely on AWS support to do so. You can try to deduct what’s wrong using your own logs from your remote IPSec device. The latter requires a certain level of expertise.
How can 40Cloud help?
One of the main goals we had when designing the 40Cloud solution was to provides a general-purpose IPSec connectivity solution for the Cloud, that will be flexible enough to cope with all foreseen connectivity scenarios as well as simple enough to install, configure and debug.
Using the 40Cloud software gateways (available for AWS as well as other clouds) can provide you with the following benefits:
- Flexible IPSec connectivity scenarios
- Interconnect multiple VPCs on single or multiple regions
- Connect any standard IPSec device, on-premise or in private cloud, to an AWS VPC
- Connect individual users via dynamic IPSec VPN to an AWS VPC.
- Use EIP for IPSec
- Control IPSec parameters like encryption algorithms and shared secret, and without limitations on the number of SAs.
- Deploy multiple 40Cloud Security Gateways in a single VPC for redundancy and/or load sharing
- Easily Troubleshoot the solution by yourself
- Associate Firewall policies with your IPSec tunnels, including both site to site and user based VPNs, and associate those policies with AWS Security Groups.
Hope this helps.
Please feel free to send us any comments or questions regarding this post, or VPG and IPSec in general. Of course, if you like to experiment with the 40Cloud solution feel free to do so. For quick and easy installation, use the 40Cloud AMIs available on the AWS Marketplace.