Cisco Compatible Micro Router Series

Document ID: 17697

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Transitioning from STEP to IKE IntraPort Client Software and Upgrading from 4.x to 5.x IntraPort VPN Access Server Code
      Adding the IKE Policy Section
      Updating the VPN Group
      Updating the IntraPort's Internal User Database
      Updating a RADIUS User Database
      Client Changes
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

itioning VPN users from STEP to IKE is not as bad as you might expect. There are very few changes which need to be made, the exact number of which depend on how your authentication is currently being performed. Users in any given group can migrate as they get the 3.x Client installed, meaning that 2.x and 3.x users can use the same group configuration concurrently. This eases upgrading considerably.

Two of the existing IntraPort server configuration sections have been renamed. The [ STEP Client <name> ] is now the [ VPN Group <name> ], and the [ STEP Users ] is now the [ VPN Users ].

Note: If you are not upgrading any of your users to the 3.x Clients, no configuration changes are needed.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Transitioning from STEP to IKE IntraPort Client Software and Upgrading from 4.x to 5.x IntraPort VPN Access Server Code

Adding the IKE Policy Section

There is a new configuration section, [ IKE Policy ]. You will need to either add that section manually (using the command line) or use CompatiView 5.3 or greater. The command line will prompt you to use the new section names (overwriting the old), and CompatiView will automatically change the section names from the old to the new. If, after upgrading the IntraPort server, CompatiView does not display the "IKE Policy" section in the "Global" section, delete the IntraPort server's entry from the CompatiView Device View database and then re-add it. This resets the attribute bits and lets CompatiView know that the IntraPort server is now IKE capable.

There is only one keyword availabe in the [ IKE Policy ] section, Protection. The Protection keyword specifies a protection suite for the ISAKMP/IKE negotiation between the IntraPort server and client. This keyword may appear multiple times within this section, in which case the IntraPort server will propose all of the specified protection suites. The IntraPort client will accept one of the options for the negotiation. There are four possible protections: MD5_DES_G1 | MD5_DES_G2 | SHA_DES_G1 | SHA_DES_G2

The first piece of each option is the authentication algorithm to be used for the negotiation. MD5 is the message-digest 5 hash algorithm. SHA is the Secure Hash Algorithm, which is considered to be somewhat more secure than MD5.

The second piece is the encryption algorithm. DES (Data Encryption Standard) uses a 56-bit key to scramble the data.

The third piece is the Diffie-Hellman group to be used for key exchange. Because larger numbers are used by the Group 2 (G2) algorithm, it is more secure than Group 1 (G1).

Updating the VPN Group

The server software provides backward compatibility in a very smooth manner allowing the same user ID to use either the 3.x or the 2.x Client. You will need to add the Transform = x keyword/value pair in the IntraPort's [ VPN Group <name> ] in addition to adding the [ IKE Policy ] section. The 2.x Client will ignore these attributes and the 3.x Client will use them, so both will work. For example, if your entry looks like this:

[ VPN Group ]
BindTo            = Ethernet 0
MaxConnections    = 45
KeepAliveInterval = 60
InactivityTimeout = 0
EncryptMethod     = fixed
StartIPAddress    = 200.200.200.50
Ipnet             = 200.200.200.0/24

To change it so that you could use IKE clients as well, it would need to be changed to look like this:

[ VPN Group ]
BindTo            = Ethernet 0
MaxConnections    = 45
KeepAliveInterval = 60
InactivityTimeout = 0
EncryptMethod     = fixed
StartIPAddress    = 200.200.200.50
Ipnet             = 200.200.200.0/24
Transform         = ESP(SHA,DES)

Updating the IntraPort's Internal User Database

IKE users can be migrated as they get the client installed. If you were using the internal server database, a Sharedkey= attribute would need to be added to each user's [ VPN Users ] entry. For example, let's say your entry looked like this:

[ VPN Users ]
loren Config="VPN1" Auth="letmein" Encrypt="letmein"

To change your entry so that you could use an IKE client as well (perhaps you have two machines and one you upgrade but the other you don't), it would need to be changed to look like this:

[ VPN Users ]
loren Config="VPN1" SharedKey="letmein" Auth="letmein" Encrypt="letmein"

Updating a RADIUS User Database

The server software provides backward compatibility in a very smooth manner allowing the same user ID to use either the 3.x or the 2.x Client. It requires no modification to the RADIUS user profile. The RADIUS attributes that you entered are still going to be used with IKE. Here's a Funk RADIUS entry for a VPN account:

loren User Type:Set password = Unix-PW

Compatible-VPN-Password = "letmein"

Compatible-VPN-GroupInfo = "VPN1"

Looking at the defined attributes above, the Compatible-VPN-Password is the shared secret. The shared secret is used to create the keys for packet authentication and encryption. It is not meant as a replacement for the RADIUS authentication. As before, if RADIUS is being used, a RADIUS password must be entered by the user. The Compatible-GroupInfo is the [ VPN Group <name> ]. There should be no difference compared to what you do with the 2.x Client now, aside from the shared secret. Here's a Merit RADIUS entry for a VPN account:

loren Authentication-Type = "letmein"

Tunnel-Password = "letmein"

Connect-Info = "VPN1"

Looking at the defined attributes above, the Tunnel-Password is the shared secret and the Connect-Info is the [ VPN Group <name> ]. Since Authentication-Type is Unix-PW, the RADIUS password is the same you would use when you log into your hosts as loren. There should be no difference compared to what you do with the 2.x Client now, aside from the shared secret.

Client Changes

There are no fields for authentication/encryption information in the 3.x Clients. Instead of entering authentication and encryption information in the Connection Configuration screen, the user will be prompted for the shared secret when attempting to establish a connection. This improves security, by removing the storage of the secrets from the PC. Storage of secrets can be enabled on the server (by the administrator), but is off by default. This is done with the SaveSecrets keyword, which is located in the [ VPN Group <name> ] section.

The one thing that may feel odd to users is that they will be prompted for the shared secret first. Then, if the server determines that the user is a RADIUS user (it does this by looking in its internal user database and not finding a user entry), it will prompt the user for her RADIUS password. The RADIUS transaction takes place, with the RADIUS server sending the Tunnel-Password back to the IntraPort, which validates it against the shared secret. If you are not using RADIUS, the user will only be prompted for the SharedKey. The IntraPort server then uses that value to generate authentication and encryption keys for the data stream.

NetPro Discussion Forums - Featured Conversations

Related Information

• Technical Support & Documentation - Cisco Systems