Configuring, & Verifying a Site-to-Site FlexVPN using Smart Defaults

“The What?” - I am going to walkthrough deploying, & verifying a site-to-site (S2S) FlexVPN using asymmetric authentication & the IKEv2 smart defaults.

To see more about FlexVPN Smart Defaults see post: FlexVPN Smart Defaults Tidbit

“The Why?” - FlexVPN offers a scalable framework that has unique features such as Smart Defaults that aides in minimizing configuration, and securing communications. FlexVPN also supports a variety of VPN types.

See more about FlexVPN building blocks: FlexVPN Configuration Blocks Tidbit

“The How?” - Using IKEv2 Smart Defaults, & asymmetric authentication to establish a S2S FlexVPN

So in this demo we will be building a simple S2S FlexVPN using asymmetric encryption via pre-share-keys within an IKEv2 keyring & via some of the IKEv2 smart defaults. In our lab topology we have two CSRs directly connected to each other. Remember that for a simple implementation via smart defaults that you may only use a couple of the FlexVPN building blocks. Another thing to note is that you always have to define a unique IKEv2 Profile. Why? Because this allows us to define the authentication for the remote peer. So in our lab we will build out a unique IKEv2 keyring, IKEv2 Profile, IPsec Profile, tunnel interfaces on each respective router & successfully establish & verify our setup.

Since we are using Cisco IOS we won't be using crypto maps. Instead we will use tunnel interfaces with tunnel protection. We will create static virtual tunnel interfaces (sVTI); these interfaces represent the source and destination for our tunnel. Our tunnel allows us to generate our overlay network.

Note that in this scenario we will be using (Generic Routing Encapsulation) GRE over IPsec. Real quick on GRE: GRE uses IP protocol type 47, and provides us the ability to encapsulate packets over another protocol. GRE has a nice feature that allows us to carry routing protocol information across the VPN tunnel. Lastly, note that GRE does add an additional 24-byte header of overhead. This overhead contains a new 20-byte IP header, which indicates the source and destination IP addresses of the GRE tunnel. The remaining 4 bytes are the GRE header itself.

Simple Lab Topology:

An overview of the process in regard to configuration includes:

  • Configure IKEv2 keyring

  • Configure IKEv2 Profile

  • Configure IPsec Profile

  • Configure tunnel interfaces & static routes

CSR13 Configuration: Omitting S2S underlay connectivity

  • We start with creating a local keyring to define our pre-share-keys that will be used for asymmetric authentication.

Next we configure our IKEv2 Profile that ties together the keyring, and our remote peer (nonnegotiable items):

Quick look at IKEv2 smart default proposal:

Quick look at IKEv2 smart default policy:

Now we will configure our unique IPsec Profile to bind our unique IKEv2 Policy that will later get assigned to our tunnel interface:

Quick look at IPsec default transform-set:

Lastly, we will create our tunnel interface that will be used in our overlay, assign the IPsec profile, along with a loopback interface, & a static route.

Tunnel interface:

Local loopback interface:

Static route to CSR14 loopback:

At this point CSR13 is configured, & ready to establish a S2S FlexVPN using smart defaults.

Now we repeat the same steps on CSR14:

Ok so now that both devices are configured let's generate some traffic so we can verify the configuration:

Initiating pings to the CSR14 loopback from CSR13 OR shutting/no shutting the tunnel interface allows us to begin the process of establishing our FlexVPN.

Viewing & understanding the IKEv2 SA details:

A few important things to note: in the SA details include:

  • Auth Sign = How CSR13 authenticates itself to CSR14 = Pre-shared-key

  • Auth Verify = How CSR14 authenticates itself to CSR13 = Pre-shared-key

  • Local/Remote id = The ISAKMP identities exchanged

  • Security Association initiator

Viewing and understanding IPsec Security Associations:

So below we can see that both IPSec peers (CSRs) agrees to set up security associations (SA). Security associations are unidirectional and are established per security protocol (AH or ESP). Other notable information includes: local/remote identities, protocol, packet encryption/decryption.

Inbound SA:

Outbound SA verification:

In later posts we will walkthrough the IKEv2 & IPsec SA debugs to better understand the transactions.

Blog overview: We walked through configuring a S2S FlexVPN using Smart Defaults with asymmetric authentication via pre-share-keys, how to establish the VPN, & how to verify our SAs. Cheers!


Recent Posts

See All

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when att

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2