For Part 2 of this series, click here.

The following questions will be added to the Core Knowledge Simulation engine.   Answers will be provided in the comments section.

Implement Identity Management

Refer to the diagram.   The software running on the PC performs what role? Read the rest of this entry »

Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. It is finally time to demonstrate the actual configuration

Normally, GET VPN requires a dedicated Key Server, which does not participate is user traffic encryption and only distributes keying information and encryption policies. All other routers – group members – register to the Key Server. A router could not register to itself when configured as a key server and group member simultaneously. However, there is a Key Server redundancy feature known as KOOP Key Servers that allows for two servers to synchronize the keying information and the group member to register to the redundant key servers.

Relying upon this feature, we may take two routers and configure them both in a KOOP key server pair. At the same time, every router is configured as a Group Member registering to another router. Since the keying information is being kept in sync, both routers will be able to properly exchange encrypted GET VPN traffic. Now, for the practical implementation we chose two directly connected routers: R4 and R5. GET VPN is supposed to encrypt traffic sent off respective VLAN4 and VLAN5 interfaces of these routers destined to the multicast groups in range 232.0.0.0/8. The IP addresses for VLAN4 and VLAN5 subnets are 173.X.4.0/24 and 173.X.5.0/24. Here is how we configure R4 for Key Server functionality. Notice the redundancy configuration using R5 as the peer.
Read the rest of this entry »

Bob turned up the volume on his MP3 player. It was difficult to hear his music over the whirring of the humidifiers.  He sat down in one of the small chairs in front of a computer with SecureCRT.  It was freezing in the data center, and a short sleeved Bob was hoping for a quick and working solution.   It all happened like this:

After his huge success implementing DMVPN and GET VPN overlay, (with a lot of help from his INE Blog Buddies), Bob was on a roll.   He decided to attempt VRF and IPSec integration as his next challenge.

Read the rest of this entry »

Hi Everyone,

We’ve just posted a number of new SC and RS VOL1 labs updates (VPN and BGP sections respectively). It’s obviously taking some time to update the existing IEWB-SC VOL1 labs, as we’re adding a lot of new topics and breakdown material. Therefore, we’re changing the update model by focusing primarily on the new topics, as an addition to the existing v3.0 labs. After the “host” stuff has been all covered, we’ll continue updating the existing material. As for the new labs posted under the IEWB-SC VPN section, here is the list:

IOS ezVPN Server
IOS ezVPN Server using VTI
IOS ezVPN Server: Group Lock
IOS ezVPN Server: RADIUS Authorization
IOS ezVPN Server: Per User AAA download with PKI
IOS ezVPN Remote: Client Mode
IOS ezVPN Remote: NEM
IOS ezVPN Remote: VTI
IOS ezVPN Remote: Digital Signatures
ASA ezVPN Server
ASA ezVPN Server: DHCP Address Allocation
ASA ezVPN Server: RADIUS Authorization
ASA ezVPN Server: Per User AAA download with PKI
ASA Clientless SSL VPN
ASA Clientless SSL VPN: Port Forwarding
ASA Clientless SSL VPN: Smart Tunnel

The next “scattered” update will probably focus on the (imho overrated GET VPN, ZFW, DAP, Virtual Sensors, IPs Anomaly Detection and some other “hot” topics. Also, VOL2 Lab3 is coming soon as well. Happy studying!

In this blog post we are going to review and compare the ways in which IOS and ASA Easy VPN servers perform ezVPN attribute authorization via RADIUS. The information on these procedure is scattered among the documentation and technology examples, so I thought it would be helpful to put the things together.

To begin with, let’s establish some sort of equivalence between the IOS and ASA terminology. Even though ASA inherited most of it’s VPN configuration concepts from the VPN3000 platform it is still possible to find similarities between the IOS and the ASA configurations. Recall that IOS ezVPN configuration defines local ezVPN group policy by means of the crypto isakmp client configuration group command. This could be viewed as a rough equivalent to the ASA’s group-policy type internal command, though the ASA’s command scope is much broader. IOS ISAKMP profiles could be viewed as an equivalent to the ASA’s tunnel-group command defining a connection profile.

Read the rest of this entry »

Hi everyone,

we have just uploaded the initial update of IEWB-SC VOL1 “VPN” section to all subscribed accounts. The update contains 15 new labs listed below:

LAN-to-LAN VPN between IOS and ASA
IPsec and NAT Interaction in ASA Firewall
Peer Authentication using Digital Signatures
ASA Tunnel Group Names
ASA Certificate Mapping Rules
Filtering traffic inside LAN-to-LAN tunnels
LAN-to-LAN tunnel between IOS Routers
IOS IPsec NAT Traversal
IOS IKE Aggressive Mode
VPN between Overlapping Subnets
IOS VPN with Digital Signatures Authentication
IOS Certificate Access Lists
Virtual Tunnel Interfaces
GRE over IPsec
DMVPN

The following labs are in process of being developed should be available soon. Notice that there might be more labs than currently are on the list.

IOS ezVPN Server
IOS ezVPN Server with RADIUS
IOS ezVPN Server with Digital Certificates
IOS ezVPN Remote
ASA ezVPN Server
ASA ezVPN Server with RADIUS
ASA ezVPN Server with Digital Certificates
IOS Clientless SSL VPN
IOS SSL VPN
ASA SSL VPN
ASA Clientless SSL VPN
IOS PPTP
ASA L2TP over IPsec
IPSec High Availability
GET VPN

The next thing you guys would see updated is the long-awaited IEWB-RS VOL1 v5.0 “BGP” section

Have fun!

General Logic Overview

When establishing a VPN tunnel, ASA firewall matches tunnel-group names based on the following criteria list:

1) Using the IKE ID presented by the remote peer. It may be an IP address (default) or hostname. In some cases this might be an ezVPN group name, for example when you are using Cisco ezVPN client or ezVPN Remote feature.
2) Using the OU (Organization Unit) field from the DN found in digital certificate presented by the peer OR by using the certificate mapping rules. This only works when ISAKMP phase uses digital signatures for authentication. Certificate mapping rules translate the DN (distinguished name) found in the certificate to the tunnel-group name.
3) Using the remote endpoint’s IP address. It’s the last resort rule, and this is the only way to match the identity with PSK (pre-shared keys) and IKE Main Mode.

Before we move any further, recall that IKE uses either of two modes of operation for Phase 1: Main Mode (default) and Aggressive Mode:

a) Main Mode (MM), which is mandatory per RFC, establishes encrypted channel before exchanging the identities.
b) Aggressive Mode (AM), which is quicker than Main Mode, exchanges IDs in “clear text”, while performing DH (Diffie Hellman) exchange and establishing the secure channel. AM is less secure than MM is thus should be less preferred.

IKE MM with PSK

There are some important consequences of MM behavior, when using authentication based on pre-shared keys (PSK). When pre-shared keys are used for authentication, they are also used to generate the shared encryption key for ISAKMP SA (along with the DH generated key). When the ISAKMP responder receives a MM proposal from initiator, and selects authentication based on pre-shared keys, it should start the shared-key generation. This procedure requires to know the PSK of the remote peer in advance. However, there is a problem here – the responder does NOT know the ID of the initiator yet, only its IP address. Therefore, the only way to select the proper pre-shared key in MM is by looking the key up based on the initiator’s IP address. Even if you configure the use of hostnames for IKE IDs with PSK authentication, the keys and tunnel-group names are still looked up based on the IP addresses. This is the unique “feature” of ISAKMP MM with PSK.

IKE MM with digital signatures

Now consider the case when you are using MM with digital signatures (RSA sigs). In this situation, session key is not derived using the pre-shared key configured in both routers. Thus, the responder that accepts the policy based on digital signatures may delay the proper tunnel-group selection until it learns the IKE ID of the initiator. More than that, it may use the information from the DN field of the digital certificate presented by the initiator. By default the subject’s OU field in the certificate is used to match the tunnel group names, but you may configure flexible mapping rules.

In ASA firewall, the following default commands enable tunnel-group name lookup based on the OU (first) than IKE-ID (if present) and finally the Peer IP address:

tunnel-group-map enable ou
tunnel-group-map enable ike-id
tunnel-group-map enable peer-ip

IKE AM and names matching

Let’s see how AM affects the name matching procedure. When the responder receives an AM proposal, the proposal already contains the IKE ID of the initiator, even if the authentication method is PSK. The IKE ID might be and IP address or hostname or just any string (e.g. ezVPN group). The responder may use it to find the local tunnel-group and pre-shared key if needed. Thus, you may utilize tunnel-group names based on hostnames with IKE AM even with PSK authentication.

Activating IKE AM

IKE AM is automatically on with some VPN features, such as ezVPN remote. In order to initiate AM negotiation in ASA firewalls manually, use the command crypto map set phase1-mode aggressive. Enabling this feature in IOS is a bit convoluted. You should configure an ISAKMP profile first and then use it with a crypto map similar to the following:

crypto isakmp profile AGGRESSIVE
initiate mode aggressive
self-identity fqdn
keyring default
!
crypto map VPN isakmp-profile AGGRESSIVE
crypto map VPN 10 ipsec-isakmp

You may globally disable AM in Cisco IOS router using the command crypto isakmp aggressive-mode disable or using the command isakmp am-disable in ASA firewall. This will prevent the devices from accepting or initiaing any IKE AM connections.

Fallback Matching

What happens if none of the configured groups matches? If no specific group is found, the firewall would use the default group that is always present in the system: DefaultRAGroup. Thus, if you don’t have a specific group configured for the remote endpoint, but the authentication using the default group succeeds, the system will use the default policy for the new tunnel. In case you wonder, you may change the default tunnel-group name using the command tunnel-group-map default-group <NAME> and specify your own group.

Certificate Mapping Rules

When using digital signatures authentication, ASA firewall supports certificate mapping rules to translate the issuer and subject names in the certificate to the tunnel-group name. The rules are configured using the command crypto ca certificate map [<NAME>] <SEQ#>. If no name is specified, the default map named DefaultCertificateMap is used for this purpose. Every entry in this map matches either part of issuer or subject DN in the certificate. For example

crypto ca certificate map MYMAP 10
issuer-name attr cn eq IESERVER1
subject-name co R3

You may match the DN as a whole string, without specifying any particular attribute like the second line does. When you have the map configured, you need to perform the following two steps:

1) Enable the mapping rules using the command tunnel-group-map enable rules.
2) Configure certificate map to tunnel-group mapping using the global commands tunnel-group-map [<NAME>] <SEQ#> <Tunnel-Group-Name>.

You may repeat the second step how many times you want to map the particular entry to a tunnel group that exists in the sytem. If you don’t specify the name for the certificate map, the default is DefaultCertificateMap used. Notice that OR logic is implemented by mapping multiple certificate map entries to the same group. Thus, any of the matching entries will result in the incoming session being matched on the same group.

IOS Local AAA is one feature that is often overlooked for some reason. It allows turning your router into almost full-functional AAA server, allowing not only local authentication of remote VPN users but also local authorization for protocols like PPP (used with PPTP/PPPoE or dialup) or IKE (used with ezVPN). Best of all, you can use per-user attribute lists with PPP (alas, it does not seem to work with IKE). With per-user attribute-lists you can apply specific configuration policy with maximum granularity. First, here is the link from Cisco’s documentation site, just for your information:

IOS Local AAA

Next, the syntax for using per-user AAA is relatively straightforward. First, you create an AAA attribute list using the command aaa attribute list:

Read the rest of this entry »

There are two phases of installation to consider, installing the AnyConnect VPN client files on the Adaptive Security Appliance (ASA) for automated download and install to systems, and the actual install on the remote PCs themselves. This document provides an overview of both phases.

Read the rest of this entry »

A new topic for the CCIE Security 3.X blueprint is the Cisco AnyConnect VPN. This is an enhancement to an earlier technology that you are probably familiar with – the Clientless SSL VPN. The idea behind the Clientless SSL VPN is to provide basic VPN capabilities to a remote PC that does not possess a VPN client. The remote PC in this case just needs an SSL capable Web browser.

Read the rest of this entry »