Novell Home

AppNote: CISCO IOS 12.2(11) T with NBM 3.8 Server

Novell Cool Solutions: AppNote
By Upendra Gopu

Digg This - Slashdot This

Updated: 4 Oct 2006
 

Update: Chendil Kumar has made some additions and corrections to the AppNote.

Abstract: This document describes the basic design and interoperability of an IP VPN network on top of a public network infrastructure using a CISCO 2600 IOS 12.2 T with a Novell BorderManager (NBM) 3.8 VPN server (site-to-site mode).

Table of Contents:

1.0 Introduction
1.1 IPsec VPN Definition
2.0 Major Components
2.1 Internet Key Exchange (RFC 2409)
2.2 IPsec
2.3 Implementation
3.0 Configuration of the CISCO 2600 with IOS 12.2 (11) T
3.1 Miscellaneous Information on Maps
4.0 NBM 3.8 Configuration
4.1 To add Cisco as a member to this server
4.2 Adding 3rd Party Traffic Rules in NBM 3.8
5.0 Conclusion

1.0 Introduction

Corporate networks connected to the Internet can enable flexible and secure VPN access with IPsec. Connecting remote sites over the Internet provides a great cost saving opportunity when compared to the traditional Wide Area Network (WAN) access such as Frame Relay or ATM. With IPsec technology, customers can build Virtual Private Networks (VPNs) over the Internet with secure encryption protection against wire taping or intrusion into private communication.

This document describes the basic design and interoperability of an IP VPN network on top of a public network infrastructure using CISCO 2600 IOS 12.2 T with a NBM 3.8 VPN server. The document does not detail the general operation of the protocols associated with deployment, such as Internet Key Exchange (IKE) or Digital Encryption Standard (DES), nor does it discuss the management and automation aspect for service provisioning.

1.1 IPsec VPN Definition

IPsec VPN is an enterprise network deployed on a shared infrastructure using IPsec encryption technology. IPsec VPNs are used as an alternative to WAN infrastructure that replace or augment existing private networks that utilize leased-line or enterprise-owned Frame Relay and Asynchronous Transfer Mode (ATM) networks. IPsec VPNs do not inherently change WAN requirements, such as support for multiple protocols, high reliability, and extensive scalability. Instead, they meet these requirements with greater cost-effectiveness and flexibility.

An IPsec VPN utilizes the available transport technologies: public Internet, SP Internet Protocol (IP) backbones, SP Frame Relay and ATM networks. The equipment is deployed as the connecting point between the Internet and the enterprise network. Feature integration across the WAN primarily defines the functionality of an IPsec VPN.

IPsec VPNs are deployed to ensure secure connectivity between VPN sites. The VPN sites can be either a subnet or a host residing behind routers. The following are the key components of such an IPsec VPN design:

  • NBM 3.8 server acting as master.
  • Cisco high-end VPN routers serving as VPN head-end termination devices.

2.0 Major Components

This document is based on the interoperability tests between Cisco IOS and the NBM 3.8 VPN server. The tests used the following infrastructure:

  • CISCO 2600 with IOS 12.2(11) T.
  • NBM 3.8 Server on NetWare 6.5
  • Mode of Authentication : Pre-shared Key (PSK)
  • IP compress: disabled
  • IKE Lifetime: 480 minutes (4 hours)
  • IPsec lifetime: 120 minutes (1 hour)
  • IKE integrity: MD5
  • IKE mode: Main mode
  • IKE Group: MODP 1024 (group 2)
  • IPsec integrity: MD5
  • IPsec mode: tunnel (for all VPN connections)
  • PFS: disabled. (MODP 1024, group 2).

2.1 Internet Key Exchange (RFC 2409)

IPsec offers a standard way to establish authentication and encryption services between endpoints. This includes both standard algorithms and transforms, and standard key negotiation and management mechanisms (via ISAKMP/Oakley).

Internet Key Exchange (IKE) is a key management protocol standard used with the IPsec standard. It enhances IPSec by providing additional features, flexibility, and ease of configuration. It enables automatic negotiation of IPsec security associations, and enables IPsec secure communications without costly manual pre-configuration. It also facilitates a secure exchange of encryption keys.

IKE is a form of ISAKMP (Internet Security Association Key Management Protocol)/Oakley specifically for IPsec. ISAKMP describes the phase of negotiation; Oakley defines the method to establish an authenticated key exchange. This method may take various modes of operation and is also used to derive keying material via algorithms such as Diffie-Hellman.

ISAKMP Phase 1 is used when peers establish a secure, authenticated channel to communicate. Generally the Oakley main mode is used. The main mode provides the authenticated bi-directional IKE Security Association and its keying material.

ISAKMP Phase 2 is required to establish SAs on behalf of other services, including IPsec. This mode uses Oakley Quick Mode to generate key material and/or negotiate parameters. The Quick Mode provides two to four (depending on whether AH and/or ESP was used) uni-directional IPsec Security Associations and their keying material. Negotiation refers to establishing policies or Security Associations (SAs) between devices. An SA is a policy rule that maps to a specific peer, with each rule identified by a unique SPI (Security Parameter Index). A device may have many SAs stored in its Security Association Database (SADB). These SAs could be created in DRAM and indexed by SPI. As an IPsec datagram arrives, the Cisco device will use the enclosed SPI to reference the appropriate policy that needs to be applied to the datagram.

2.2 IPsec

IPsec combines the above mentioned security technologies into a complete system that provides confidentiality, integrity, and authenticity of IP datagrams. IPsec actually refers to several related protocols as defined in the new RFC 2401-2411 and 2451 (the original IPsec RFCs 1825-1829 are now obsolete). These standards include:

  • IP Security Protocol: This defines the information to add to an IP packet to enable confidentiality, integrity, and authenticity controls. It also defines how to encrypt the packet data.
  • Internet Key Exchange (IKE): This negotiates the security association between two entities and exchanges key material. Using IKE is not necessary, but manually configuring security associations is difficult and labor-intensive. IKE should be used in most real-world applications to enable large-scale secure communications.

2.3 Implementation

Important Points to note before configuration:

Keep the following in mind throughout the setup, and check these items if the setup fails:

  • PFS should be same on both the servers. They should be either ON or OFF.


  • Traffic rules should exactly match on both the servers. Either give all hosts or give the protected networks in the traffic rules on both the servers.


  • PHASE 2 (IPSEC) Encryption and Authentication Algorithms should match.

3.0 Configuration of the CISCO 2600 with IOS 12.2 (11) T

Enable these items to implement IPsec configuration. The general steps are as follows:

  1. Configure IKE policy
  2. Configure IPsec Transforms and protocol
  3. Create Access Lists for Encryption
  4. Configure Crypto Map
  5. Apply Crypto Map on the interface

Step 1: Configure IKE policy

IKE is a protocol used to automatically negotiates the security parameters, authenticate identified, secure and establish an agreement between IPsec routers. Multiple IKE policies can be defined between two IPsec peers; however there must be at least one matching IKE policy between them to establish the IPsec tunnels.

To configure an IKE policy, use the following commands at the Cisco terminal in global configuration mode:

crypto isakmp policy 1
encr 3des
authentication pre-share
lifetime 28800
crypto isakmp key border address 192.168.101.2 255.255.255.0

The pre-shared key is used to identify and authenticate the IPsec tunnel. The key can be any alphanumeric key up to 128 characters. The key is case-sensitive and must be entered identically on both servers. The previous configuration uses a unique pre-shared key that is tied to a specific IP address.

Step 2: Configure IPSec Transforms and Protocols

A transform set represents a certain combination of security protocols and algorithms. During IKE negotiation, the peers agree to use a particular transform set for protecting data flow.

During IKE negotiations, the peers search in multiple transform set for a transform that is the same at both peers. When such a transform set is found, it is selected and applied to the protected traffic as a part of the two peers' configurations.

To configure IPsec transforms and protocols, use the following commands at the Cisco terminal in global configuration mode:

crypto ipsec transform-set vpn-test esp-3des esp-sha1-hmac

With manually established security associations, there is no negotiation with the peer and both sides must specify the same transform set.

Step 3: Create Access Lists for Encryption

Access lists define what IP traffic will be protected by crypto. Extended access list are used to specify further source and destination addresses and packet type.

The access list entries must mirror each other on the IPsec peers. If access list entries include ranges of ports, then a mirror image of those same ranges must be included on the remote peer access lists.

To configure access lists, use the following commands at the Cisco terminal in global configuration mode:

ip access-list extended vpn-static1

permit ip 172.16.1.0 0.0.0.255 10.10.0.0 0.0.255.255

The address range in the access list represents the traffic on the local segment at each router. Any unprotected inbound traffic that matches a permit entry in the access list will be dropped, because it was expected that IPsec would protect this traffic.

Note: The same kind of traffic rule should be provided in third party traffic rules (iManager) on NBM 3.8.

Step 4: Configure Crypto Map

A crypto map entry ties together the IPsec peers, the transform set used and the access list used to define the traffic to be encrypted. The crypto map entries are evaluated sequentially.

In the example below, the crypto map name static-map and crypto map numbers are locally significant. The first statement sets the IP address used by this peer to identify itself to other IPsec peers in this crypto map. This address must match the set peer statement in the remote IPsec peer crypto map entries. This address also needs to match the address used with any pre-shared keys the remote peers might have configured. The IPsec mode defaults to tunnel mode.

crypto map static-map local-address FastEthernet1/0
crypto map static-map 1 ipsec-isakmp
set peer 192.168.101.2
set transform-set vpn-test
set security-association lifetime seconds 7200
match address vpn-static1

Step 5: Add the route to the protected network

A route must be added to the protected network so that CISCO IOS can forward the protected network trafic to Novell BorderManager. To add a route to the protected network:

ip route 10.10.0.0 0.0.255.255 192.168.101.2

Note: Make sure that IP routing is enabled in the routes. If it is not, enter the following command to enable it:

ip routing

Step 6: Apply the Crypto Map on the interface

The crypto maps must be applied to each interface through which IPsec traffic will flow.

To apply crypto map on an interface, use the following commands at the Cisco terminal in global configuration mode:

interface FastEthernet1/0
ip address 192.168.101.1 255.255.255.0
crypto map static-map

Applying the crypto map to the physical interface instructs the router to evaluate all the traffic against the Security Associations Database. With the default configurations, the router is providing secure connectivity by encrypting the traffic sent between the remote sites. However, the public interface still allows the rest of the traffic to pass and provide connectivity to the Internet.

3.1 Miscellaneous Information on Maps

1. What are Crypto Map Functions?

Crypto maps provide two functions:

  1. Filtering and classifying traffic to be protected and


  2. Defining the policy to be applied to that traffic.

The first use affects the flow of traffic on an interface; the second affects the negotiation performed (via IKE) on behalf of that traffic. IPsec crypto maps link together definitions of the following:

2. What Traffic Should be Protected?

To which IPsec peers can the protected traffic be forwarded - these are the peers with which a security association can be established.

3. Which Transform Sets are Acceptable for Use with the Protected Traffic?

How keys and security associations should be used or managed (or what the keys are, if IKE is not used).

4. What if Multiple Crypto Map Entries with the Same map-name Form a Crypto Map Set?

A crypto map set is a collection of crypto map entries, each with a different seq-num but the same map-name. Therefore, for a given interface, you could have certain traffic forwarded to one IPsec peer with specified security applied to that traffic, and other traffic forwarded to the same or a different IPsec peer with different IPsec security applied. To accomplish this you would create two crypto maps, each with the same map-name, but each with a different seq-num.

5. What is a seq-num Argument?

The number you assign to the seq-num argument should not be arbitrary. This number is used to rank multiple crypto map entries within a crypto map set. Within a crypto map set, a crypto map entry with a lower seq-num is evaluated before a map entry with a higher seq-num; that is, the map entry with the lower number has a higher priority.

For example, imagine that there is a crypto map set that contains three crypto map entries: mymap 10, mymap 20, and mymap 30. The crypto map set named mymap is applied to interface Serial 0. When traffic passes through the Serial 0 interface, the traffic is evaluated first for mymap 10. If the traffic matches a permit entry in the extended access list in mymap 10, the traffic will be processed according to the information defined in mymap 10 (including establishing IPsec security associations when necessary). If the traffic does not match the mymap 10 access list, the traffic will be evaluated for mymap 20, and then mymap 30, until the traffic matches a permit entry in a map entry. (If the traffic does not match a permit entry in any crypto map entry, it will be forwarded without any IPsec security.)

A more complete description can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software
/fsecur_r/fipsencr/srfipsec.htm#xtocid5">/ios122/122cgcr/fsecur_r/fipsencr/srfipsec.htm#xtocid5

4.0 NBM 3.8 Configuration

Configure the server using iManager.

  • 192.168.101.2 / 255.255.255.0 and also give the Tunnel IP Address as 12.12.12.2 / 255.0.0.0 (Actually you can give one IP Address from the tunnel address you were using for the server.)
  • The Key life time specified here will be negotiated with the CISCO peer so specify the lifetime in seconds. In our case it is 480 minutes.
  • If you want to enable PFS, check the Perfect Forward Secrecy Check box. (The Cisco configuration is not enabled. Enable it in the Cisco box, if needed.) Remember to either enable or disable PFS on both Cisco and NBM at the same time.

Click OK after completing the server configuration.

Select server configuration, then check site-to-site Check box, and select the Master Radio button.

Click Details. It will show the Issuer Certificate (created automatically). Check the Subject Name and the browse for the server certificate, click it. The Certificate subject Name will appear in the text box.

Provide the Protected network of the NBM 3.8 server in the Protected Networks list (in this case it would be 10.10.0.0 / 255.255.0.0)

4.1 To add Cisco as a member to this server:

Go to the Member Lists tab and then click the Add button.

  1. Provide the IP Address and the subnet mask of the Cisco IOS server and provide one tunnel IP Address to the Cisco server in the same network as the NBM 3.8 server (in our case 12.12.12.1 / 255.0.0.0)
  2. Check the Non-Border Manager Check box.
  3. Check the Pre-shared-key radio button. Enter the Pre-shared Key. In our case it is "border" (Provide the same pre-shared key you have specified in the Cisco server. The keys are case sensitive).
  4. In the Protected Network list provide 172.16.1.0 / 255.255.255.0 (Protected Networks list of the Cisco Server).
  5. Click OK.

4.2 Adding 3rd Party Traffic Rules in NBM 3.8

  1. Go to Third Party Traffic Rules and click ADD.
  2. Provide a name to the rule.
  3. Expand the 3rd Party Server Configuration.
  4. Select the Cisco's IP Address in the 3rd Party Server Gateway Address in the drop down box.
  5. Select the Only Use IP List radio button under Rule Applies To
  6. Click Add and then provide the network IP Address as given in the Cisco Server (Third Party Server). In our case, the network IP Address is 172.16.1.0 / 255.255.255.0
  7. Expand the NBM Server Protected Network list.
  8. Select the Only Use IP List radio button under Rule Applies To
  9. Click Add and provide the network IP Address as how it is given in the Cisco Server (Third Party Server). In our case, network is 10.10.0.0 / 255.255.0.0
  10. Expand Action.
  11. Select Encrypt in the VPN Mode
  12. In the Encryption key lifetime by time enter the Phase 2 SAs lifetime value. In our case it is 120 minutes.
  13. In our case the Encryption Algorithm should be 3DES and Authentication Algorithm should be HMAC- SHA1. This should exactly match with the Transform set given in the Cisco.
  14. Click Apply and then OK.

Now Initiate a connection from a client in the protected network of NBM to a client in the Cisco Server they should be able to ping with the packets going encrypted.

5.0 Conclusion

This interoperability has been tested for the 3DES and DES encryption algorithms and HMAC-MD5, HMAC-SHA1 authentication algorithms, perfect forward secrecy off/on (PFS) and with the pre-shared key. Novell recommends that you verify the interoperability of the Cisco IOS server and the NBM 3.8 server on a simulated test network before you deploy them directly in a production environment.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell