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.
! Configuration on the East-1a CSR instance (csr-1a): ! vrf definition INET ! fvrf definition description FVRF - to Internet rd 1:1 ! Unique RD ! address-family ipv4 ! Not exporting or importing any communities exit-address-family ! vrf definition HUB ! Hub-to-hub route exchange VRF. description Hub-to-Hub VRF rd 65120:1 ! Arbitrary RD. Using BGP ASN:1 for CSR-1a. ! address-family ipv4 route-target export 65120:1 ! Export community for this VRF route-target import 172.16.8.0:1 ! Import Public-1a routes route-target import 172.16.9.0:1 ! Import the Private-1a routes route-target import 1:100 ! Import VPN routes exit-address-family ! vrf definition PUBLIC-1A ! Public-1a VRF description East-1a - Public subnet rd 172.16.8.0:1 ! Unique RD for this subnet. <Subnet:1> ! address-family ipv4 route-target export 172.16.8.0:1 ! Export community for this VRF route-target import 65120:1 ! Import routes from the HUB VRF route-target import 1:100 ! Import VPN routes exit-address-family ! vrf definition PRIVATE-1A ! Private-1a VRF description East-1a - Private subnet rd 172.16.9.0:1 ! Unique RD <Subnet:1> ! address-family ipv4 route-target export 172.16.9.0:1 ! Export community route-target import 65120:1 ! Import routes from the HUB VRF route-target import 1:100 ! Import VPN routes exit-address-family ! vrf definition VPN ! Our HQ and Customer routes reside here description East-1a - IPsec VRF rd 1:100 ! Unique RD ! address-family ipv4 route-target export 1:100 ! Export community route-target import 172.16.8.0:1 ! Import Public-1 Routes route-target import 172.16.9.0:1 ! Import Private-1 Routes route-target import 65120:1 ! Import routes from the HUB VRF exit-address-family !
And the configuration on CSR-1b (East-1b) will be similar except we’ll use different route distinguishers (RD):
vrf definition INET description FVRF - to Internet rd 1:1 ! address-family ipv4 exit-address-family ! vrf definition HUB description Hub-to-Hub VRF rd 65120:2 ! address-family ipv4 route-target export 65120:2 route-target import 172.16.10.0:1 route-target import 172.16.11.0:1 route-target import 2:100 exit-address-family ! vrf definition PUBLIC-1B description East-1b - Public subnet rd 172.16.10.0:1 ! address-family ipv4 route-target export 172.16.10:1 route-target import 65120:2 route-target import 2:100 exit-address-family ! vrf definition PRIVATE-1B description East-1b - Private subnet rd 172.16.11.0:1 ! address-family ipv4 route-target export 172.16.11.0:1 route-target import 65120:2 route-target import 2:100 exit-address-family ! vrf definition VPN description East-1b - IPsec VRF rd 2:100 ! address-family ipv4 route-target export 2:100 route-target import 172.16.10.0:1 route-target import 172.16.11.0:1 route-target import 65120:2 exit-address-family !
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):
event manager applet fvrf event none action 1.0 cli command “enable” action 1.1 cli command “conf t” action 1.2 cli command “interface gig1” action 1.3 cli command “vrf forwarding INET” action 1.4 cli command “ip address dhcp” action 2.0 cli command “end” event manager run fvrf
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.
!!!! CSR-1a Configuration: interface Gig1 description ** Gateway - VPC Edge-1a Subnet ** ! interface Gig2 vrf forwarding PUBLIC-1A description ** VPC Public-1A (East-1a) ** ip address dhcp no shutdown ! interface Gig3 vrf forwarding PRIVATE-1A description ** VPC Private-1A (East-1a) ** ip address dhcp no shutdown ! !!!! CSR-1b Configuration: interface Gig1 description ** Gateway - VPC Edge-1b Subnet ** ! interface Gig2 vrf forwarding PUBLIC-1B description ** VPC Public-1B (East-1b) ** ip address dhcp no shutdown ! interface Gig3 vrf forwarding PRIVATE-1B description ** VPC Private-1B (East-1b) ** ip address dhcp no shutdown !
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:
!!!! CSR-1a Configuration: interface Loopback1 description Tunnel endpoint address - Elastic IP vrf forwarding VPN ip address 10.3.3.32 255.255.255.255 ! !!!! CSR-1b Configuration: interface Loopback1 description Tunnel endpoint address - Elastic IP vrf forwarding VPN ip address 10.4.4.64 255.255.255.255 !
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!
crypto ikev2 proposal PROPOSAL-IKEv2 ! Customer-specified IKEv2 Crypto settings encryption aes-cbc-256 aes-cbc-192 integrity sha512 sha384 sha256 group 24 20 ! ! The IKEv2 Policy references the profile. We also must specify the FVRF which will ! use the policy: crypto ikev2 policy POLICY-IKEv2 match fvrf INET proposal PROPOSAL-IKEv2-CUST
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.
!!! csr-1a keyrings - the local and remote PSKs will be inverted on the remote endpoints ! !! Keyring for the hub connection crypto ikev2 keyring KEYRING-VPN-HUB peer csr-1b description Peer Hub - East-1b address 10.2.2.16 ! Elastic IP associated with csr-1b identity fqdn csr-1b.example.com pre-shared-key local str0ngL0calPSK pre-shared-key remote str0ngR3m0tePSK ! ! !! Keyring for our HQ routers and the customer endpoint: crypto ikev2 keyring KEYRING-VPN-CUST peer HQ-edge-1 description HQ Site - edge router 1 address a.b.c.d ! Public IP of edge endpoint pre-shared-key local Hq1Str0ngL0calPSK pre-shared-key remote Hq1Str0ngR3m0tePSK ! peer HQ-edge-2 description HQ Site - edge router 2 address e.f.g.h ! Public IP of edge endpoint pre-shared-key local Hq2Str0ngL0calPSK pre-shared-key remote Hq2Str0ngR3m0tePSK ! peer CUST-1 description Customer tunnel endpoint 1 address i.j.k.l ! Public IP of customer endpoint pre-shared-key local CustStr0ngL0calPSK pre-shared-key remote CustStr0ngR3m0tePSK ! !!!! csr-1b keyrings - only the hub keyring shown for brevity; the HQ and CUST-1 peers are configured with different PSKs but in the same manner as on csr-1a ! !! Keyring for the hub connection crypto ikev2 keyring KEYRING-VPN-HUB peer csr-1a description Peer Hub - East-1a address 10.1.1.8 ! Elastic IP associated with csr-1a identity fqdn csr-1a.example.com ! Note that the PSKs are inverse of those defined on csr-1a: pre-shared-key local str0ngR3m0tePSK pre-shared-key remote str0ngL0calPSK !
With the keyrings done, we’ll create two IKEv2 Profiles. These will be matched based on the remote identity and will be configured for the appropriate keychains:
!!!! Hub IKEv2 profile - csr-1b crypto ikev2 profile PROFILE-IKEv2-HUB description IKEv2 Profile - Hub-to-Hub match fvrf INET match identity remote fqdn csr-1b.example.com identity local fqdn csr-1a.example.com authentication remote pre-share authentication local pre-share keyring local KEYRING-VPN-HUB dpd 10 10 periodic ! !!!! Customer IKEv2 Profile - CSR-1a: crypto ikev2 profile PROFILE-IKEv2-CUST description IKEv2 Profile for External Customer VPN match fvrf INET match identity remote any identity local address 10.1.1.8 ! Elastic IP of our outside interface authentication remote pre-share authentication local pre-share keyring local KEYRING-VPN-CUST lifetime 28800 dpd 10 10 periodic virtual-template 1 ! ! !!!! Hub IKEv2 profile - csr-1b crypto ikev2 profile PROFILE-IKEv2-HUB description IKEv2 Profile - Hub-to-Hub match fvrf INET match identity remote fqdn csr-1a.example.com identity local fqdn csr-1b.example.com authentication remote pre-share authentication local pre-share keyring local KEYRING-VPN-HUB dpd 10 10 periodic ! !!!! Customer IKEv2 Profile - CSR-1b: crypto ikev2 profile PROFILE-IKEv2-CUST description IKEv2 Profile for External Customer VPN match fvrf INET match identity remote any identity local address 10.2.2.16 ! Elastic IP of our outside interface authentication remote pre-share authentication local pre-share keyring local KEYRING-VPN-CUST lifetime 28800 dpd 10 10 periodic virtual-template 1 !
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:
!!!! Config the same on both CSRs !! Define the transform-set: crypto ipsec transform-set XFORM-IPSEC esp-aes 256 esp-sha256-hmac mode tunnel ! ! And the two IPsec profiles - one for the HQ/Customer VPNs and one for the hub: ! crypto ipsec profile IPSEC-AWS-CUST description IPsec profile for External Tunnels set transform-set XFORM-IPSEC-STD set pfs group24 set ikev2-profile PROFILE-IKEv2-CUST responder-only ! crypto ipsec profile IPSEC-HUB description IPsec profile for Hub-to-Hub Tunnels set transform-set XFORM-IPSEC-STD set pfs group24 set ikev2-profile PROFILE-IKEv2-HUB !
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).
! Virtual-template configuration is the same on both CSR instances: interface Virtual-Template1 type tunnel description Tunnel Endpoint vrf forwarding VPN ip unnumbered Loopback1 ip nat outside tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel path-mtu-discovery tunnel vrf INET tunnel protection ipsec profile IPSEC-AWS-CUST ! ! Hub-to-hub tunnel interface on CSR-1a: interface Tunnel12 vrf forwarding HUB ip address 192.0.2.1 255.255.255.252 ip nat outside tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination 10.2.2.16 tunnel path-mtu-discovery tunnel vrf INET tunnel protection ipsec profile IPSEC-HUB ! ! And, finally, the hub-to-hub tunnel on CSR-1b: interface Tunnel12 vrf forwarding HUB ip address 192.0.2.2 255.255.255.252 ip nat outside tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination 10.1.1.8 tunnel path-mtu-discovery tunnel vrf INET tunnel protection ipsec profile IPSEC-HUB !
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!