Hello World: Simple LAN-to-LAN Flex VPN configuration

Having discussed the motivations behind FLEX VPN (http://wp.me/p1loe7-fJ) and presented information about positioning of Cisco IOS VPN solutions (http://wp.me/p1loe7-gy), it’s now time to jump to some practical scenarios.

Our site-to-site topology consists of two ISR G2 routers connected by a GRE interface, as depicted in Figures 1. The Integrated Services Routers rely on static routes to direct traffic to the tunnel and reach the protected networks (10.200.101.0/24 on the HUB1 site and 10.200.201.0/24 on SPOKE1 site). Authentication is performed by Pre-shared Keys (PSK) defined within a crypto ikev2 keyring. The main settings for this  environment are summarized for HUB1 and SPOKE1 on Figures 1 and 2, respectively.

This sample configuration is also useful to illustrate the overall structure of a FLEX VPN policy. The main building blocks are:

  • IKEv2 profile: basically defining how authentication is handled and what identities to consider. Settings such as the keyring (for PSK) and crypto trustpoint (for rsa-sig) are established here. The complete set of parameters contained in the IKEv2 profile are displayed with the show crypto ikev2 profile command.
  • IPSec Profile: determines the transform-set for IKE phase 2 (IPSec SA) and points to the IKEv2 profile. This type of profile is tied to the interface (similar to what we did for a crypto-map) by means of the tunnel protection ipsec profile command.

Other important entities (not shown in the configuration) are:

  • IKEv2 proposal: specifies the algorithms used to secure the IKE phase 1 SA. Take a look at Figure 3 and use the show crypto ikev2 proposal command to obtain more information about this policy component.
  • IKEv2 policy:  selects the IKEv2 proposal and VRFs where to place the VPN packets. Figure 4 registers the settings for the default IKEv2 policy.

Figure 1: Main Configs on router HUB1

It’s interesting to observe that FLEX provides extra flexibility with regards to the authentication process (that can even be asymmetric). Some possibilities are listed below:

  • The HUB can use a pre-shared key with all the spokes (which is not the ideal) but still have an individual key to authenticate each of the remotes. In previous models if the HUB had to share a key with all the spokes, that key would be known to all the routers involved. (And therefore it would be easy for spokes to spoof one another).
  • Digital certificates (rsa-sig method) can be used to authenticate both sides.
  • You can use digital certificates to authenticate the hub and PSK for the spokes.
  • There is also support for the Elliptic Curve Digital Signature Algorithm (ecdsa-sig) and for the Extensible Authentication Protocol (EAP).
  • Although you can configure only one local authentication method, multiple remote authentication methods are allowed, so that you can cope with different types of peers connecting to a certain router (normally the central element in your topology).

Figure 2: Main configs on router SPOKE1

Figure 3 provides visibility about the IKEv2 and IPSec SAs corresponding to our configuration. Notice that the show crypto session detail command is particularly useful to obtain summarized information about the Security Associations in place, interfaces in use for protected traffic and even encrypted/decrypted packets. The command also characterizes that the IPSec flow is protecting GRE packets (protocol 47) between HUB1 (172.20.20.11) and SPOKE1 (172.20.20.1).

Figure 3: Information about the IKEv2 and IPSec Security Associations

Figure 4 allows us to gain additional insight about this basic deployment. For instance, it reveals:

  • The default IKEv2 policy and how it binds to the default proposal (not shown in the configuration)
  • Some characteristics of the tunnel interface (source/destination, GRE-based, MTU and attached IPSec profile).
  • Another quick way of displaying encrypted and decrypted packets.

Figure 4: IKEv2 Policy, Tunnel Interface and Encrypted Packets

This is the very first article covering sample configurations… So stay tuned for more !

** Related Posts:

** Additional Reading:

Leave a comment

Filed under English, Security, VPN

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s