Monthly Archives: June 2012

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

Zone-based Firewall and Cisco Security Manager – basic concepts

The initial articles in the Zone-based Policy Firewall (ZFW) series concentrated on basic ZFW behavior and capabilities. The current post shift gears a little bit, by quickly discussing how the Cisco Security Manager (CSM) software can facilitate the operation and maintenance of a network protected by the Zone Firewall.

As depicted in Figure 1, if you are already acquainted with graphical configuration of firewall policies (for ASA and even other vendors’ products), you will notice that the philosophy is basically the same. The traditional logic for rule construction (involving sources, destinations and services) is still there… Yes, that’s it: benefit from the abstraction provided by CSM to build the logical rules and the software will take care of translating them to the CLI commands that materialize the ZFW functionality.

Figure 1 also illustrates another interesting possibility: you can create a ZFW policy on CSM and assign it to multiple devices. This is really relevant when you need, for instance, to deploy multiple branches that have similar rules.

Figure 1: Zone-based Firewall rule table on CSM

Figure 2 shows that you can import the active settings on a live Cisco IOS device and share it on CSM. It’s important to highlight that you can select the types of settings to be imported for later use (ZFW rules, AAA configuration, general platform information and much more).

Figure 2: Sharing device policies through CSMth

Figure 3 displays the CSM Configuration Archive feature, which allows you to keep track of configuration versions (a kind of information that is certainly useful for auditing and meeting compliance requirements). By selecting a saved configuration you can see the configuration commands delivered to the device (Transcript Viewer).

Figure 3: Configuration Archive and CLI Transcript

This was just a quick review of the CSM capabilities regarding the Zone Firewall. It’s naturally recommended that you review the previous ZFW posts and, if possible, that you navigate through the CSM GUI.

** Related Articles:

** Further Reading:

Leave a comment

Filed under English, Firewalls, Security