AWS: DX Public VIF w/ VPN Failover



Here I'll provide a quick glimpse on how to setup a physical DirectConnect cross-connect to your AWS VPC with seamless VPN resiliency of VPN failover.

First, you'll need to provision at least one DirectConnect (DX) connection to AWS. After you've done that, use the AWS portal create a new Public VIF on that connection(s):
Click for full-size

In reality, a VIF is really just a separate dot1q VLAN and BGP peering session within the physical link between you and AWS at the exchange facility. The difference between a Public and Private VIF is what addresses are received/announced by both ends. For instance, using a private VIF is similar to a VPN connection where you will receive private VPC subnet(s) and announce your remote network's local IP space toward it.

With a public VIF however you'll instead receive all of AWS' public service endpoint prefixes, including EC2, S3, Dynamo DB, and VPN terminators. Side note: Depending on optional BGP communities that you might've specified in your router's BGP policy, the space you receive can be limited regionally.

Important Note: To use a public VIF you will need a public IPv4 block to announce and likely (depending on failover requirements) your own registered, public ASN.

You can further enhance the quickness (sub-second) and resiliency of link failure detection by enabling BFD on the DX circuit. With this you can quickly detect if there's ever a problem with the link and re-establish the VPN to the gateway over the Internet path. AWS enables asynchronous mode BFD by default on their end and there's no extra cost associated, so if your router supports it it'd be quite silly not to enable BFD!

Once the public VIF peering session is up, you then should create a regular, VPC VPN and use the same (or even different) customer router as what's being used to terminate the DX public VIF to also terminate the VPNs. Note that the customer VPN router IPv4 address(es) must be within the block being announced to AWS via the public VIF BGP session.

This way, if for some reason this DX circuit goes down, your VPN will still be able to connect to the public IP addresses (now via the Internet) responsible for VGW VPN termination. Since the VPN peer IP addresses doesn't change, the VPN connection should automatically be re-established without even needing to re-key.

Need High-Availability?

Provision two physical DX connections/public VIFs to utilize a Active/Active (BGP multi-path.) Otherwise, use the [less-recommended] Active/Passive model, where the designated standby link performs outward AS prepending. Note that prepending to AWS over DX links requires a public, registered ASN.

Image Src: https://docs.aws.amazon.com/en_us/directconnect/latest/UserGuide/getting_started.html

Considerations

This solution implies that your upstream Internet capacity is equal to or greater than the link speed in which you're connected on your DirectConnect link(s). For example, if you are heavily utilizing a public VIF on a 2x10Gb Active/Active DX circuit, you'll need to make sure that your Internet capacity from the box performing VPN termination has this same or more capacity, otherwise saturation will occur during a failover. No good.

Similarly, anytime you're using an Active/Active model like this, be sure to actively monitor and add capacity (via LAG) if you're ever using more than 45% of the bandwidth on any link.

Popular posts from this blog

Configuring Cisco ASA for Route-Based VPN

Up and Rawring with TRex: Cisco's Open Traffic Generator

Running ASA on Firepower 2100: An End-to-End Guide