When beginning the configuration phase of implementation, it helps to break the task down into components. Based on the problem statement and objectives of the deployment, we can identify the core focus areas:

VRF definitions and initial interface configuration

Base crypto configuration

Connectivity between the CSR instances

Connectivity between the CSRs in AWS and our HQ network / the customer network

NAT configuration

Routing

Of course, these don’t have to be accomplished in this order, but it’s close enough. Once the basics are working, we can work out the finer points such as security, routing policies, and redundancy. Let’s get started with VRF definitions and initial interface configurations. This document will assume some familiarity with AWS, so I won’t go into the details of that. One task that will be required in AWS is to disable the Source/Destination check on the interfaces attached to the CSR1000.

For this deployment, we decided to break up the routing tables into Virtual Routing and Forwarding (VRF) instances. There will be 5 VRFs per router:

INET (we’ll use this for the front-door VRF or fvrf)

HUB (routes exchanged between the CSR instances)

VPN (IPsec tunnel routes to our corporate HQ and the customer site)

PRIVATE (private VPC subnet)

PUBLIC (public VPC subnet)

This article will cover the VRF / interface configuration as well as the base crypto configuration.

VRF definitions and initial interface configuration

Remember that attaching a VRF to an interface will clear the address configuration, so it makes sense to complete this task first. Time to dive in! Note that we will be using 65120 as our BGP ASN. No MPLS in place, so the HUB VRF will import everything and be used to exchange routes between the CSRs.

OK, step 1 almost complete. Next, we need to assign the VRFs to the interfaces. Remember that in AWS, there is no console – so it’s easy to get burned by applying the VRF config on the outside (Edge-1a/1b) interface. To make sure this doesn’t happen, create and execute an EEM applet which will apply the VRF configuration and set the interface for DHCP (more info from Cisco is available here):

Connectivity will be lost briefly and then be restored. On to configure the remaining interfaces. We’re attached the AWS interfaces to the CSRs such that interface GigabitEthernet2 is the Public subnet and GigabitEthernet3 is the Private subnet.

We should now have IP addressing on the interfaces and each is happy in its own VRF world. Wait, I’ve forgotten something – our Loopback addresses will be used for BGP peering to the corporate HQ. This is the beginning of the “Elastic IP hack,” so let’s create the Loopbacks and assign the correct VRF and IP:

Looks like a good start. There’s probably more to do, but I’m excited to get the crypto going! Let’s go…

Base crypto configuration

I mentioned earlier that we’ll use FlexVPN (DVTI) for our connectivity. This means IKEv2, so we need to configure a few things:

An IKEv2 Proposal which will be associated with an

IKEv2 Policy

Also, an IKEv2 keyring (or two), which will be attached to an

IKEv2 Profile, which will reference a

Virtual Template – but that requires an

IPsec Profile, which needs an

IPsec Transform Set

That should get us close! Our customer sent us some specific crypto requirements, so we’ll base the design on those. I prefer to leave any default policies in place and to create my own. To start, we need an IKEv2 Proposal. This defines the initial encryption and integrity requirements for the Key Exchange Security Association (SA). Unless otherwise specified, configuration items below are applied on BOTH routers!

We will have two IKEv2 profiles – one for the remote site VPNs and one for the hub-to-hub connectivity (more on that later). To simplify this deployment, we’ll create two keyrings – one for each profile.

Virtual-template. What’s that? Well, we can configure our FlexVPN hubs up with something called a Dynamic Virtual Tunnel Interface, or DVTI. We’ll define a template which contains all the parameters of the tunnel, similar to when we create a GRE Tunnel. With DVTI, though, each new connection will create a Virtual-Access interface which inherits the properties of the Virtual-Template. It may sound daunting, but it’s really not.

Before we configure out template, though, we need to configure the IPsec parameters. This involves a transform-set which defines the crypto settings and an IPsec profile which associates the transform-set and IKEv2 profile, as well as setting other crypto features such as PFS. This part is simple:

OK, the last set of configuration should wrap up this post. We need to create the Virtual-Template for incoming VPN connections, and I’ll create the hub-to-hub tunnel interface which will be used to exchange routes and for failover (covered later).

So, any new remote VPN connection will build a Virtual-Access interface which inherits all the configuration of Virtual-Template1. This includes the VRF, the IPsec profile, and NAT parameters. Of interest here is that the Virtual-Templates are configured for ip unnumbered with the Loopback1 interface – remember, this is an allocated but non-associated Elastic IP in the public address space. This is compliant with the customer requirements.

The hub-to-hub tunnels are configured statically with bogus IP addresses in the documentation range; they could be ip unnumbered based on a Loopback or any other method, as long as IP is enabled.

That’s about enough for me to write on this beautiful Saturday morning. In the next post(s), we’ll configure NAT, routing, and VPN connectivity from our HQ sites to the CSRs to begin testing. Have a great day and keep networking!