Cross-VPC access is one of the difficult problems one faces when utilizing Virtual Private Clouds for segregation and separation of systems. Separating is a good thing, however often there is a need to cross these boundaries for control traffic, monitoring, and user convenience. In my case, the systems I work with are primarily cloud-based, and traditional options of adding a Hardware VPN Gateway were sub-optimal. Last month, Amazon announced VPC Peering as a way to break down the VPC boundary within a single region. This is great news for single-region deployments, but still does not address cross-region access needed for an high availability solution.
One solution to the lack of inter-region VPC peering is to use an in-cloud VPN hub, and to connect segregated application VPC’s via the use of a NAT+VPN gateway within each VPC. In the example below, the private network 203.0.113.0/24 is subdivided between two VPCs, each with a public and private subnet, and with the private network being re-routed by the VPC routing tables to either the VPN hub or the NAT+VPN client gateway.
Here is the configuration for the vpn-hub, which creates a VPC with a VPN-HUB IPsec gateway to pull together the client VPCs: example-hub.json
Here is the client configuration, which routes all private network traffic back to the VPN gatway: example-client.json
When using the cloudcaster tool, the routing tables of the VPC are modified to direct the private network to the NAT+VPN gateway. For the vpn-hub, one additional change is needed; the private network needs to be re-routed from the NAT+VPN gateway to the VPN-HUB gateway:
# instance-id is the ID of the VPN-HUB instance
# route-table-id is the ID of the public subnet 203.0.113.0/28
aws ec2 replace-route –region us-west-2 –destination-cidr-block 203.0.113.0/24 –route-table-id rtb-XXXXXXXX –instance-id i-XXXXXX
For this to work, you will need to build 3 AMI types based on the Amazon NAT/PAT instance:
- vpn-hub – the VPN concentrator
- nat-hub – a NAT/PAT gateway with an exclusion from NAT/PAT for the private network
- nat-vpn – a NAT/PAT gateway with IPsec that tunnels traffic destined to the private network via the VPN-HUB
Instructions for building the AMI types is located in the README. An ElasticIP is required for the VPN-HUB, which needs to be baked into the AMI image for the NAT-VPN. At boot, and each hour thereafter, the VPN-HUB will poll the EC2 API and construct a list of tunnels to build, allowing the VPN to extend to future VPCs and clean up after VPCs are deleted.
Some caveats: this is not a high-availability nor a high-traffic solution as presented. Each vpn-hub/nat-hub/nat-vpn is a single point of failure, and using t1.micro instances is not recommended for high-throughput networking. High-availability is not currently practically possible as VPC route tables do not support multipath routing to instances at this time.
This solution does perform admirably for command & control and monitoring traffic, especially when combined with either ssh bounce boxes or a client-vpn host to enable access to all hosts within your infrastructure.