SYSTEM ADMINISTRATOR GUIDE     2/1543-CRA 119 1170/1-V1 Uen A

IPsec VPN Configuration and Operation Using the SmartEdge OS CLI

Copyright

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

Contents

1   Introduction

An Internet Protocol Security (IPsec) Virtual Private Network (VPN) consists of protected tunnels between pairs of gateways. A gateway, also referred to as a peer, is a node that functions as an endpoint for a protected tunnel that traverses an unsecured routing cloud. A gateway protects the traffic communicated by networks at each end of the tunnel that are outside the routing cloud; these networks are known as protected networks.

1.1   Scope

This document describes how to use the SmartEdge® OS to add and configure all of the elements required for an IPsec VPN tunnel to the configuration of a SmartEdge router, including Internet Key Exchange (IKE) and Internet Protocol Security (IPsec) configuration. This document also provides information on how to monitor IPsec, example configurations, and log messages.

1.2   Target Groups

This document is intended for network planners responsible for the design of advanced network services that use the SmartEdge router and for operators of the SmartEdge OS responsible for entering the configuration on individual SmartEdge routers.

2   IPsec VPN Introduction

An IPsec VPN is a set of IPsec tunnels that securely isolates the traffic between the participating peer devices from any other traffic traversing the same devices. An IPsec tunnel consists of two endpoints that successfully negotiate a secure connection using the IKE protocol.

IPsec tunnel endpoints are configured independently on each participating peer in an IPsec VPN. The simplest configuration, site-to-site IPsec VPN, is between two peers. On each peer, you configure a local IPsec tunnel endpoint that points to the remote endpoint on the other peer.

A hub-and-spoke configuration consists of many IPsec tunnel endpoints on one hub peer, each of which has the same local identity and points to a different spoke peer, and only one IPsec tunnel endpoint on each spoke peer that points back to the hub peer. By adding more tunnel endpoints to each of the peers, you can configure anything from a partial to a fully meshed IPsec VPN.

2.1   Prerequisites

The two peers of an IPsec tunnel must be logically connected. For each SmartEdge router that functions as a peer endpoint for an IPsec tunnel, you configure the local port or circuit termination by using the SmartEdge OS CLI or the NetOp client. Configuring the connectivity for unmanaged remote peers is a separate activity beyond the scope of this document.

To configure the connectivity on a SmartEdge router that functions as a peer endpoint for an IPsec tunnel, identify the context in which you are configuring the IPsec tunnel and define it, if it does not exist. In the context in which you are configuring the IPsec tunnel, you then:

• Configure the following IP interfaces and bind them appropriately:
  • Peer interface—An interface to bind to the link between the two peers.
  • Traffic interface—An interface to bind to the physical link between the SmartEdge router and the protected network.
  • Tunnel interface—An interface to statically bind to the logical IPsec tunnel. Create one interface for each lPsec tunnel.

  For information on how to configure an interface or bind a port or circuit to an interface by using the SmartEdge OS, see Reference [1], and by using the NetOp Element Management System (EMS), see Reference [2].

• Configure the gateway interface, a loopback interface whose IP address will be used as the local endpoint of the tunnel. This interface does not need to be configured in the same context as the peer, traffic, and tunnel interfaces.
• Configure IP routes to point to the IPsec tunnel interface (Dynamic routing protocols can be run over the tunnel instead.)

  For information on how to configure an IP route by using the SmartEdge OS, see Reference [3].

• Enable the context for Security Service; see Reference [4].

2.2   Site-to-Site Connections Examples

You can create IPsec tunnels between two SmartEdge routers or between one managed SmartEdge router and an unmanaged device (referred to as an extranet device), such as Customer Premises Equipment (CPE) or remote special-purpose server. Figure 1 shows the physical links for an IPsec VPN that must exist between two managed SmartEdge routers and between the two SmartEdge routers and the protected networks at each end of the IPsec tunnel. Figure 2 shows the physical links for an IPsec tunnel that must exist between the NetOp EMS host, a managed SmartEdge router, and an extranet device as well as the SmartEdge router and the protected network at its end of the IPsec tunnel.

You can use these two basic configurations to implement a variety of individual secure site-to-site IPsec tunnels.

2.2.1   Connecting Remote Protected Networks

An IPsec tunnel between two managed SmartEdge routers protects traffic across the untrusted network between the routers. This type of IPsec tunnel allows a service provider to offer protected traffic support between the endpoints that it manages.

For example, Figure 3 shows an IPsec VPN that connects two protected networks at each end of the tunnel for a multisite business customer (a total of four protected networks). The customer trusts the traffic between its premises and the SmartEdge routers, but does not trust the traffic between the SmartEdge routers managed by the service provider (also known as Provider Equipment [PE]).

To secure the traffic of the business customer between its SmartEdge routers, the service provider uses an IPsec tunnel. This ensures that all the traffic for the business customer between the two endpoints the service provider manages is protected.

In this scenario, the connections between the equipment on the premises of the customer and the SmartEdge routers of the service provider, as well as the connection between the SmartEdge routers, must already be configured. To protect the customer traffic between the two managed SmartEdge routers, the service provider must configure both endpoints of the secured IPsec tunnel.

2.2.2   Securing the Last Mile

An IPsec tunnel between a managed SmartEdge router and a CPE device protects traffic on the last mile. This type of IPsec tunnel allows a service provider to offer protected services between an endpoint it manages and one that it does not.

For example, Figure 4 shows four IPsec tunnels that connect the four protected networks to two SmartEdge routers for a multisite business customer. The customer expects the service provider to protect the traffic between its premises and the SmartEdge routers.

To secure this traffic, the service provider uses four IPsec tunnels to ensure all the traffic between each CPE device at the customer site and the SmartEdge router it manages is protected.

In this scenario, the connections between the equipment on the customer premises and the service provider SmartEdge routers, as well as the connection between the SmartEdge routers, must already be configured. To protect the customer traffic between its premises and the service provider SmartEdge router, on each IPsec tunnel the service provider must configure the endpoint on the SmartEdge router and identify the peer endpoint on the extranet device on the customer premises.

2.2.3   Encryption of Local Stack Packets

Service providers need to encrypt their own data to send to customers because the data has encryption requirements associated with it. Common requirements include organizational best practices, risk associated with the data, regulatory demands, and privacy concerns.

For example, Figure 5 shows three IPsec tunnels that protect the traffic of a service provider on connections between its own equipment in the network.

In this scenario, the service provider is protecting its own data, and the connections between all equipment involved in communicating the encrypted data must already be configured. To protect its own traffic, the service provider must also configure individual IPsec tunnels and identify the appropriate endpoints.

2.3   IPsec VPN Setup and Activation Using IKE

The minimal matching requirements for both endpoints of an IPsec tunnel to successfully complete all negotiations and the setup to become active are:

• IKE proposal—Each peer must have at least one configured matching IKE proposal.
• IKE policy:
  • At least one referenced IKE proposal on each peer must match.
  • The preshared key on each peer must match.
  • The key exchange mode on each peer must match.
  • The connection type on each peer must be compatible (at least one initiator and one responder).
• IPsec proposal—Each peer must have at least one configured matching IPsec proposal.
• IPsec policy:
  • At least one referenced IPsec proposal on each peer must match.
  • The Perfect Forward Secrecy (PFS) DH group setting must match.
• IPsec Access Control List (ACL)—The rules in the IPsec ACL referenced by each peer must match.
• Within each IPsec tunnel endpoint configuration:
  • The local and remote addresses or Fully Qualified Domain Names (FQDNs) and the local and remote IKE identities must match.
  • The referenced IKE policy must be consistent with the IKE policy referenced by the peer endpoint.
  • The endpoint of the logical IPsec tunnel must be statically bound to an interface.

3   IKE Configuration

The IPsec VPN application supports the dynamic negotiation and exchange of secure keys and Security Associations (SAs) using the IKE protocol. This technique is more secure and removes the potential for error compared with a manual technique, and allows the use of preshared keys to authenticate both parties. IKE configuration consists of:

• Configuring global IKE proposals, which define parameters used to negotiate and exchange the keys and SAs used to set up IKE SAs.
• Optionally enabling Dead Peer Detection (DPD) in each security-enabled context, which provides an efficient way to detect when remote peers become unavailable.
• Configuring IKE policies in each security-enabled context, which provide specific attributes to use when establishing IKE SAs.

3.1   Configure IKE Proposals

An IKE proposal defines the parameters used to negotiate an IKE SA: the algorithm used to encrypt the signalling traffic, the algorithm used to authenticate both parties to establish the VPN connection, and the Diffie-Hellman group to use.

A newly configured IKE proposal is automatically configured with the following default values:

• DH group: 1
• Authentication algorithm: hmac-sha1-96
• Encryption algorithm: aes-128-cbc
• SA lifetime: 86,400 seconds (one day)

3.1.1   Configuration Tasks

To configure an IKE proposal:

1. Configure the IKE proposal in global configuration mode:

   (config)#ike proposal name

2. In IKE proposal configuration mode:
   • Configure the description of the IKE proposal:

     (config-ike-proposal)#description string

   • Configure the Diffie-Hellman group for IKE key exchanges:

     (config-ike-proposal)#dh-group dh-group

   • Configure the authentication algorithm:

     (config-ike-proposal)#authentication algorithm algorithm

   • Configure the encryption algorithm:

     (config-ike-proposal)#encryption algorithm algorithm

   • Configure the lifetime for IKE SAs:

     (config-ike-proposal)#lifetime seconds seconds

3. Commit the transaction.

3.1.2   Configuration Examples

The following example shows how to configure the IKE_Prop1 IKE proposal:

[local]Redback(context)#ike proposal IKE_Prop1
[local]Redback(config-ike-proposal)#description IKE-Proposal-1
[local]Redback(config-ike-proposal)#dh-group 2
[local]Redback(config-ike-proposal)#authentication algorithm 
  hmac-md5-96
[local]Redback(config-ike-proposal)#encryption algorithm aes-192-cbc
[local]Redback(config-ike-proposal)#lifetime seconds 43200

3.2   Enable and Disable IKE Keepalive

In each security-enabled context, you can enable the sending of Dead Peer Detection (DPD) messages to IKE peers. By default, the sending of DPD messages is disabled.

3.2.1   Configuration Tasks

To enable the sending of DPD messages to IKE peers, enter the following command in context configuration mode:

(config-ctx)#ike keepalive

The no form of the command disables the sending of DPD messages to IKE peers.

3.2.2   Configuration Examples

The following example shows how to enable the sending of DPD messages to IKE peers:

[local]Redback(config-ctx)#ike keepalive

The following example shows how to disable the sending of DPD messages to IKE peers:

[local]Redback(config-ctx)#no ike keepalive

3.3   IKE Policy Configuration

In each security-enabled context, an IKE policy provides settings to apply to IPsec tunnels when negotiating an IKE SA with the remote peer:

• Connection type.
• Local identity.
• Type of key exchange to use:
  • Aggressive mode
  • Main mode
• Preshared key to use with the remote peers defined in the IKE policy.
• IKE proposals to use. An IKE policy can reference multiple IKE proposals.

A newly configured IKE policy is created with the following default values:

• Connection type: both
• Key exchange mode: main

Figure 6 illustrates the parameters that can be configured for an IKE policy, and that a policy can include multiple IKE proposals.

3.3.1   Configuration Tasks

To configure an IKE policy:

1. Configure the IKE policy in context configuration mode:

   (config-ctx)#ike policy name

2. In IKE policy configuration mode:
   • Configure the description of the IKE policy:

     (config-ike-policy)#description string

   • Configure the connection type group for IKE key exchanges:

     (config-ike-policy)#connection-type type

   • Specify the identity to use as the local IKE identity for all IPsec tunnels that use this policy. Enter the IP address or FQDN of the loopback interface configured on the local SmartEdge router as the identity:

     (config-ike-policy)#identity local fqdn fqdn-string value

   • Configure the mode to use for key exchange:

     (config-ike-policy)#mode mode

   • Configure the local preshared key:

     (config-ike-policy)#pre-shared-key hex hex-value | ASCII-value | use-aaa

   • Add up to 16 IKE proposals, each with a unique sequence number:

     (config-ike-policy)#seq sequence-number proposal name

3. Commit the transaction.

3.3.2   Configuration Examples

The following example shows how to configure the IKE_Pol1 IKE policy:

[local]Redback(config-ctx)#ike policy IKE_Pol1
[local]Redback(config-ipsec-proposal)#description IKE-Policy-1
[local]Redback(config-ike-policy)#connection-type initiator-only
[local]Redback(config-ike-policy)#identity local 30.0.1.3
[local]Redback(config-ike-policy)#preshared-key hex 0x4d794865785061353577307264
[local]Redback(config-ike-policy)#mode aggressive
[local]Redback(config-ike-policy)#seq 10 proposal IKE_Prop1
[local]Redback(config-ike-policy)#seq 20 proposal IKE_Prop2

4   AAA Configuration

If pre-shared-key use-aaa is specified, configure the preshared key on the AAA server.

The AAA server returns the preshared key to use. The format expected by the node is:

ike pre-shared-key {hex hex-value | ASCII-value}

VSA 203, Security-Service (string) is supported by the SmartEdge router and can appear in Account-Request and Access-Response messages. This VSA specifies an ASE security profile

5   IPsec Configuration

IPsec configuration involves configuring IPsec proposals, IPsec policies, IPsec SAs, and IPsec ACLs.

5.1   Configure IPsec Proposals

An IPsec proposal defines the security parameters to be used when establishing an IPsec SA using IKE mode: either or both the AH and ESP protocols, and the encryption and authentication algorithms to use.

A newly configured IPsec proposal is automatically configured with the following default values:

• ESP authentication algorithm: hmac-sha1-96
• ESP encryption algorithm: aes-128-cbc
• No IP compression
• SA lifetime of 86,400 seconds (one day) and no traffic limit

5.1.1   Configuration Tasks

To configure an IPsec proposal:

1. Configure the IPsec proposal in global configuration mode:

   (config)#ipsec proposal name

2. In IPsec proposal configuration mode:
   • Configure the description of the IPsec proposal:

     (config-ipsec-proposal)#description string

   • Enable (or disable) IP compression:

     (config-ipsec-proposal)#ip-comp

     The no form of the command disables IP compression.

   • Configure the AH authentication algorithm:

     (config-ipsec-proposal)#ah algorithm

     The no form of the command removes the AH configuration.

   • Configure the ESP authentication algorithm:

     (config-ipsec-proposal)#esp authentication algorithm

     The no form of the command sets the ESP authentication (and ESP encryption) to the default. If either ESP or AH authentication is configured, using the no form of the command removes the esp authentication configuration.

   • Configure the ESP encryption algorithm:

     (config-ipsec-proposal)#encryption encryption algorithm

     If ESP authentication is configured without ESP encryption, the ESP encryption is set to null.

     If AH authentication is configured, using the no form of the command removes the encryption. If neither ESP authentication or AH is specified, using the no form of the command resets the configuration to the default.

   • Configure the lifetime for IPsec SAs:

     (config-ipsec-proposal)#lifetime seconds seconds

     (config-ipsec-proposal)#lifetime kbytes kbytes

3. Commit the transaction.

5.1.2   Configuration Examples

The following example shows how to configure the ipsec_Prop1 IPsec proposal:

[local]Redback(context)#ipsec proposal ipsec_Prop1
[local]Redback(config-ipsec-proposal)#description IPsec-Proposal-1
[local]Redback(config-ipsec-proposal)#ip-comp
[local]Redback(config-ipsec-proposal)#ah hmac-aes-xcbc
[local]Redback(config-ipsec-proposal)#esp authentication hmac-aes-xcbc
[local]Redback(config-ipsec-proposal)#esp encryption aes-256-cbc
[local]Redback(config-ipsec-proposal)#lifetime seconds 43200 
[local]Redback(config-ipsec-proposal)#lifetime kbytes 500

5.2   Configure IPsec Policies

An IPsec policy provides settings to apply to dynamic-mode IPsec tunnels when establishing connections:

• The size of the antireplay window used to prevent the replay attack and potential Denial of Service (DoS) attack. A newly created IPsec policy is automatically configured with a default value of 64 packets.
• The Diffie-Hellman group used to provide perfect forward secrecy.
• IPsec proposals used. An IPsec policy can reference up to 16 IPsec proposals.

Figure 7 illustrates the parameters that can be configured for an IPsec policy, and that a policy can include multiple IPsec proposals.

5.2.1   Configuration Tasks

To configure an IPsec policy:

1. Configure the IPsec policy in context configuration mode:

   (config)#ipsec policy name

2. In IPsec policy configuration mode:
   • Configure the description of the IPsec policy:

     (config-ipsec-policy)#description string

   • Configure the antireplay window size:

     (config-ipsec-policy)#anti-replay-window window-size

   • Enable PFS and specify the DH group used to generate the secret value:

     (config-ipsec-policy)#perfect-forward-secrecy dh-group dh-group

   • Add up to 16 IPsec proposals, each with a unique sequence number:

     (config-ipsec-policy)#seq sequence-number proposal name

3. Commit the transaction.

5.2.2   Configuration Examples

The following example shows how to configure the ipsec_Pol1 IPsec policy:

[local]Redback(context)#ipsec policy ipsec_Pol1
[local]Redback(config-ipsec-policy)#description IPsec-Policy-1
[local]Redback(config-ipsec-policy)#anti-replay-window 128
[local]Redback(config-ipsec-policy)#seq 10 proposal ipsec_Prop1
[local]Redback(config-ipsec-policy)#seq 20 proposal ipsec_Prop2

5.3   Configure IPsec SAs

An IPsec SA defines parameters for protecting packets exchanged between each side of the connection of a manual-mode IPsec tunnel. Each SA is uniquely identified by the Security Parameter Index (SPI), destination IP address, and security protocol used by the connection. The security protocol can be either Authentication Header (AH) or Encapsulating Security Payload (ESP). Each SA is directional, and you can configure inbound and outbound SAs separately or together. When you configure bidirectional SAs, all the attributes of both SAs are identical. When you configure them separately, you must configure them in pairs, using the same security protocol for the inbound SA and outbound SA (although the other attributes can differ).

5.3.1   Configuration Tasks

To configure an IPsec SA:

1. Configure the IPsec SA in global configuration mode:

   (config)#ipsec security-association sa-name

2. In IPsec SA configuration mode:
   • Configure the description of the IPsec SA:

     (config-ipsec-sa)#description string

   • Configure the antireplay window size:

     (config-ipsec-sa)#anti-replay-window window-size

   • Optionally, enable IP compression:

     (config-ipsec-sa)#ip-comp

   • Configure the SA attributes for traffic by using the following commands:
     • For bidirectional traffic:

       (config-ipsec-sa)#both

     • For inbound traffic:

       (config-ipsec-sa)#in

     • For outbound traffic:

       (config-ipsec-sa)#out

     The both command cannot be used with either the in or out command.

3. After entering any of these commands, configure the following in IPsec SA SPI configuration mode:
   • If the SA is using the ESP protocol:
     • Specify the ESP SPI value for the inbound traffic, outbound traffic, or bidirectional traffic SAs.

       (config-ipsec-sa-spi)#esp spi spi-value

     • Configure the ESP authentication algorithm and the manual key for encrypting inbound, outbound, or bidirectional traffic SAs.

       (config-ipsec-sa-spi)#esp authentication [algorithm] key hex-argument|ASCII-value

     • Configure one of the following ESP encryption options:
       • The NULL encryption algorithm to indicate that encryption is not required.

         (config-ipsec-sa-spi)#esp encryption null

       • An optional encryption algorithm and the manual key for encrypting inbound, outbound, or bidirectional traffic SAs.

         (config-ipsec-sa-spi)#esp encryption [algorithm] key hex-argument|ASCII-value

   • If the SA is using the AH protocol:
     • Configure the AH SPI value for the inbound traffic, outbound traffic, or bidirectional traffic SAs.

       (config-ipsec-sa-spi)#ah spi spi-value

     • Configure an optional AH authentication algorithm and the manual key for authenticating inbound, outbound, or bidirectional traffic SAs:

       (config-ipsec-sa-spi)#ah [algorithm] key hex-argument|ASCII-value

4. Commit the transaction.

Figure 8 illustrates how separate IPsec policies can be configured for inbound and outbound traffic or a single policy can be configured for bidirectional traffic.

5.3.2   Configuration Examples

The following example shows how to configure the ipsec_sa_1 IPsec SA and the SAs for bidirectional traffic:

[local]Redback(context)#ipsec security-association ipsec_sa_1
[local]Redback(config-ipsec-sa-spi)#esp encryption des-cbc key 12345678
[local]Redback(config-ipsec-sa-spi)#esp spi 65535
[local]Redback(config-ipsec-sa-spi)#anti-replay-window 128
[local]Redback(config-ipsec-sa) #both
[local]Redback(config-ipsec-sa-spi)#ah hmac-md5-96 hex 0fa20fa20fa20fa2
[local]Redback(config-ipsec-sa-spi)#ah spi 2546
[local]Redback(config-ipsec-sa-spi)#esp encryption des-cbc key 12345678
[local]Redback(config-ipsec-sa-spi)#esp spi 65535

The following example, if applied to the ipsec_sa_1 IPsec SA, shows how to remove all encryption for traffic:

[local]Redback(config-ipsec-sa-spi)#esp encryption null

5.4   Configure IPsec ACLs

Use IPsec ACLs to identify the traffic to be secured in the IPSec tunnel. An IPsec ACL consists of an ordered list of rules, each of which defines a class of packets, that defines a traffic filter. To identify the traffic to be secured, an IPsec ACL rule specifies the source address, the source port, the protocol, the destination address, and the destination port. Wildcards, such as masks, can be used to broaden the scope of the filter. When a manual-mode IPsec tunnel is configured, you can associate an IPsec ACL with an IPsec SA to filter the traffic; however, only the first rule in the IPSec ACL is used to filter traffic. When a dynamic-mode IPsec tunnel is configured, you can associate an IPsec ACL with an IPsec policy to filter the traffic. In either case, if no IPsec ACL is specified all traffic routed to the tunnel is matched.

5.4.1   Configuration Tasks

To configure an IPsec policy:

1. Configure the IPsec ACL in context configuration mode:

   (config-ctx)#ipsec access-list acl-name

2. In IPsec ACL configuration mode:
   • Configure the description of the IPsec ACL:

     (config-ipsec-acl)#description string

   • Create IPsec ACL statements to identify packets that meet the specified criteria:

     (config-ipsec-acl)#seq sequence-number [protocol] [source-network-prefix/source-prefix-length | any] {eq source-port}[dest-network-prefix/dest-prefix-length | any] [cond dest-port]

3. Commit the transaction.

5.4.2   Configuration Examples

The following example shows how to configure the ipsec_ACL1 IPsec ACL with three rules:

[local]Redback(config-ctx)#ipsec access-list ipsec_ACL1
[local]Redback(config-ipsec-acl)#description IPsec-ACL-1
[local]Redback(config-ipsec-acl)#seq 10 tcp 1.1.1.0/24 eq 20000
[local]Redback(config-ipsec-acl)#seq 20 1.1.1.0/24 2.2.2.0/24
[local]Redback(config-ipsec-acl)#seq 30 any any

6   IPsec Tunnel Configuration

Before you can create an IPsec VPN, all the participating peers must be set up and connectivity between all the gateways must be established. You can configure three types of IPsec tunnels.

• Auto Key—SAs are established automatically using IKE protocol between the two parties on both sides of the tunnel.

  This technique is more secure and removes the potential for error compared to the manual technique. You can deploy IKE using preshared keys to authenticate both parties.

• On-Demand Auto Key—Same as Auto Key, except that the remote peer IP address is unknown at configuration, and IPsec tunnels are dynamically created on demand, based on signalling from the remote peer.
• Manual Key—network administrators on both sides of the connection define the SAs manually, and specify the SAs to be used when configuring a manual key IPsec tunnel.

  With manual keys, parties at both ends of a tunnel configure the security parameters. This technique is straightforward for small, static networks where management and distribution of keys is relatively simple. However, manual key-based configurations create potential for security breaches.

See Section 6.2 for configuration of auto key IPsec tunnels. See Section 6.3 or configuration of on-demand auto key tunnels. See Section 6.4 for configuration of manual key tunnels.

Figure 9 illustrates the components of an IPsec tunnel endpoint configuration.

6.1   Prerequisites

In addition to the context-level prerequisites listed in Section 2.1, the following items must be configured before they can be specified in an IPsec tunnel:

• For an auto key or on-demand auto key IPsec tunnel:
  • IKE proposal
  • IKE policy
  • IPsec proposal
  • IPsec policy
  • IPsec ACLs
• For a manual key IPsec tunnel:
  • IPsec SAs
  • IPsec ACLs

6.2   Configure an Auto Key IPsec Tunnel Endpoint

For a newly created auto key IPsec VPN endpoint, you must configure:

• The static binding between the tunnel and the interface configured for this IPsec tunnel
• The remote peer
• The identity of the tunnel endpoints
• An IKE policy to negotiate the connection with the remote peer
• Up to eight sequenced IPsec policies, each optionally with an IPsec ACL, to use when establishing connections with the remote peer
• Optionally, the setting for how the Don't Fragment (DF) bit for the outer header is treated. By default, the DF bit setting used in the inner IP heading is copied to the outer IP heading.

To configure the endpoints of an auto key IPsec tunnel:

1. Create an IPsec tunnel endpoint:

   (config)#tunnel ipsec name

   Specify only the tunnel name to create an IPsec tunnel using IKE.

2. Configure the static bind between the tunnel endpoint and the interface configured for this IPsec tunnel endpoint.

   (config-tunnel)#bind interface if-name [context-name]

3. Specify how the DF bit for the outer IP header should be treated.

   (config-tunnel)#df-bit {propagate | set | clear}

4. For an IPsec tunnel using IKE, specify the IKE policy used to negotiate the connection with the remote peer:

   (config-tunnel)#ike-policy ike-policy-name

5. Specify the tunnel endpoints:

   (config-tunnel)#peer-end-point local loc-ip-addr remote rem-ip-addr [context ctx-name]

   Use the IP address of the loopback interface defined to identify the local gateway for IPsec tunnels configured on this SmartEdge router as the value for the local loc-ip-addr construct. Similarly, use the IP address configured on the remote device as the value for the remote rem-ip-addr construct. This allows you to create multiple IPsec tunnels with the same local endpoint, each with a different remote endpoint that can be part of the same IPsec VPN.

6. Identify the remote peer:

   (config-tunnel)#remote-id remote_id

7. Assign up to eight sequenced IPsec policies, each optionally with an IPsec ACL:

   (config-tunnel)#seq id ipsec-policy ipsec-pol-name [access-group ipsec-acl-name]

   If no access group is specified, an implicit wildcard policy that matches all traffic is used.

6.3   Configure an On-Demand Auto Key IPsec Tunnel

During IPsec tunnel configuration, the IP address of the remote peer may not be known. For example, remote CPE devices may not have a static IP address, but may obtain it dynamically at bootup. In this situation, you can configure an on-demand auto key IPsec tunnel.

For on-demand IPsec tunnels, the remote peer is identified by its IKE ID; only one on-demand IPsec tunnel can be active for each remote IKE ID. The remote IKE ID can be a fully specified ID for IP address and FQDN formats, a wildcard for IP addresses, or a partial ID for FQDN in the format *.xxx.xxx, or *.*.xxx. If remote ID configurations for a tunnel overlap, the order of matching is:

1. exact ID match
2. partial ID match
3. wildcard match

The same remote IKE ID should not be used in more than one IKE policy; however, the same remote IKE ID can be used in configuring multiple on-demand IPsec tunnels and IKE policies.

The following routing protocols are supported over IPsec tunnels bound to IPsec multibind interfaces:

• OSPFv2
• RIPv2

For OSPF, each of the IPSec tunnels is treated as the Point-to-Multipoint (P2MP) unnumbered interface. All OSPF control packets are sent using the multicast address. If a routing protocol is enabled over an IPsec multibind interface, then all tunnels bound to a multibind interface run the same routing protocol. You must not exceed the maximum number of OSPF adjacencies.

Equal-Cost Multipath (ECMP) across IPsec tunnels is not supported.

The IPsec multibind interface must be unnumbered.

Tunnels that use different local IP addresses for a given context are load-balanced across the different ASPs of the ASP group that the context is associated with. If the number of tunnels per context exceeds the capacity of a single ASP, multiple local IP addresses must be used to achieve load-balancing across multiple ASPs.

If you configure pre-shared-key use-aaa, the context associated with on-demand tunnel interface is used for AAA authorization to obtain a preshared key from the RADIUS server. If the RADIUS server specified in the context is unreachable, and a fallback to global authentication is configured in that context, then the RADIUS server configured in the local context is used.

If you do not configure pre-shared-key use-aaa, or if RADIUS does not specify an IPsec profile name, the system attempts to find an IPsec profile with the same name as the on-demand IPsec tunnel. If no matching tunnel is found, an error occurs and the tunnel bringup fails.

RADIUS Change of Authorization (CoA) is not supported in the current release for dynamically updating preshared keys.

For an on-demand auto key IPsec VPN endpoint, you must configure:

• A multibind IPsec interface
• An IPsec tunnel
• An IPsec profile to specify how traffic in the IPsec tunnel should be handled

6.3.1   Configure an Interface for an On-demand IPsec Tunnel

In addition to completing the context-level prerequisites for IPsec tunnel configuration as specified in Section 2.1, enable an interface to have multiple IPsec tunnel circuits bound to it:

(config-ctx)#interface name ipsec multibind

This interface does not need to be configured in the same context as the loopback interface whose IP address is used as the local endpoint for IKE signaling.

6.3.2   Create On-demand IPsec tunnel

1. Create an IPsec tunnel endpoint:

   (config)#tunnel ipsec name on-demand

2. Specify the tunnel endpoint:

   (config-tunnel)#peer-end-point local loc-ip-addr [context ctx-name]

   Use the IP address of the loopback interface defined to identify the local endpoint for IPsec tunnels configured on this SmartEdge router as the value for the local loc-ip-addr construct. Using the IP address of a loopback interface allows the local IP address to remain up, providing a stable environment for routing.

3. Specify the IKE policy used to negotiate the connection with the remote peer:

   (config-tunnel)#ike-policy ike-policy-name

4. Specify the maximum number of tunnels per profile in this on-demand tunnel.

   (config-tunnel)#max-tunnels value

5. Configure the binding between the on-demand tunnel and the IPsec multibind interface configured for this on-demand IPsec tunnel in Section 6.3.1.

   (config-tunnel)#bind interface if-name [context-name]

6.3.3   Create an IPsec Profile

Configure the IPsec profile to specify how traffic in the on-demand IPsec tunnel should be handled. The IPsec profile must be created in the same context as the multibind interface configured in Section 6.3.1.

1. In context configuration mode, enter the following command:

   (config-ctx)#ipsec profile profile-name

   The name of the IPsec profile should match the name of the on-demand IPsec tunnel.

2. Specify how the DF bit for the IP header should be treated.

   (cfg-ipsec-profile)#df-bit {set | clear}

3. (cfg-ipsec-profile)#mtu size
4. Assign up to eight sequenced IPsec policies, each optionally with an IPsec ACL:

   (cfg-ipsec-profile)#seq id ipsec-policy ipsec-pol-name [access-group ipsec-acl-name]

   If an access group is specified, it must exist in the same context as the IPsec profile. If no access group is specified, an implicit wildcard policy that matches all traffic is used.

6.4   Configure a Manual Key IPsec Tunnel

For a manual key IPsec VPN endpoint, you must configure:

• The static binding between the tunnel and the interface configured for this IPsec tunnel
• The remote peer
• The identity of the tunnel endpoints
• Up to eight sequenced manual-keyed SAs
• Optionally, the setting for how the Don't Fragment (DF) bit for the outer header is treated. By default, DF bit setting used in the inner IP heading is copied to the outer IP heading.

To configure the endpoints of a manual key IPsec tunnel:

1. Create an IPsec tunnel endpoint:

   (config)#tunnel ipsec name manual

   Specify only the tunnel name to create an IPsec tunnel using IKE.

2. Configure the static bind between the tunnel endpoint and the interface configured for this IPsec tunnel endpoint.

   (config-tunnel)#bind interface if-name [context-name]

3. Specify how the DF bit for the outer IP header should be treated.

   (config-tunnel)#df-bit {propagate | set | clear}

4. For an IPsec tunnel using IKE, specify the IKE policy used to negotiate the connection with the remote peer:

   (config-tunnel)#ike-policy ike-policy-name

5. Specify the identity of the tunnel endpoints:

   (config-tunnel)#peer-end-point local loc-ip-addr remote rem-ip-addr [context ctx-name]

   Use the IP address of the loopback interface defined to identify the local gateway for IPsec tunnels on this SmartEdge router as the value for the local loc-ip-addr construct. Similarly, use the IP address configured on the remote device as the value for the remote rem-ip-addr construct. This allows you to create multiple IPsec tunnels with the same local endpoint, each with a different remote endpoint that can be part of the same IPsec VPN.

6. Identify the remote peer:

   (config-tunnel)#remote-id remote_id

7. Assign up to eight sequenced manual-keyed SAs, each optionally with an IPsec ACL:

   (config-tunnel)#seq id ipsec-policy name security-association sa-name [access-group ipsec-acl-name]

   If no access group is specified, an implicit wildcard policy that matches all traffic is used. For each manual SA with an associated ACL, only the traffic pattern identified in the first rule of the ACL is matched.

6.5   Configuration Examples

The following example shows how to create an IPsec tunnel, IPsec_tunnel_1 , using IKE. The IPsec tunnel includes two IPsec policies, each with an associated IPsec ACL:

[local]Redback(config)#tunnel ipsec IPsec_tunnel_1
[local]Redback(config-tunnel)#ike policy IKE_Pol1
[local]Redback(config-tunnel)#df-bit clear
[local]Redback(config-tunnel)#bind interface ipsec-if1
[local]Redback(config-tunnel)#peer-end-point local 172.16.1.1 remote 172.16.1.2
[local]Redback(config-tunnel)#remote-id 72.0.0.1
[local]Redback(config-tunnel)#seq 10 ipsec-policy ipsec_Pol1 access-group ipsec_ACL1
[local]Redback(config-tunnel)#seq 20 ipsec-policy ipsec_Pol2 access-group ipsec_ACL2

The following example shows how to create an on-demand IPsec tunnel, IPsec_tunnel_2.

[local]Redback(config)#context isp1
[local]Redback(config-ctx)#interface ipsec_mb_se_1 ipsec multibind
[local]Redback(config-if)#ip unnumbered peer_local_ip_1  
[local]Redback(config-if)#exit
[local]Redback(config-ctx)#exit
[local]Redback(config)#tunnel ipsec se_1 on-demand
[local]Redback(config-tunnel)#peer-end-point local 39.0.0.1 context isp1
[local]Redback(config-tunnel)#ike-policy ike_pol_se_1
[local]Redback(config-tunnel)#bind interface ipsec_mb_se_1 isp1
[local]Redback(config-tunnel)#max-tunnels 50
[local]Redback(config-tunnel)#exit
[local]Redback(config)#context isp1
[local]Redback(config-ctx)#ipsec profile profile_se_1
[local]Redback(cfg-ipsec-profile)#seq 1 ipsec-policy ipsec_pol access-group any-acl

The following example shows how to create an IPsec tunnel, IPsec_tunnel_1 , using IKE. The IPsec tunnel includes two IPsec policies, each with an associated IPsec ACL:

[local]Redback(config)#tunnel ipsec IPsec_tunnel_1
[local]Redback(config-tunnel)#ike policy IKE_Pol1
[local]Redback(config-tunnel)#df-bit clear
[local]Redback(config-tunnel)#bind interface ipsec-if1
[local]Redback(config-tunnel)#peer-end-point local
  172.16.1.1 remote 172.16.1.2
[local]Redback(config-tunnel)#remote-id 72.0.0.1
[local]Redback(config-tunnel)#seq 10 ipsec-policy ipsec_Pol1 access-group ipsec_ACL1
[local]Redback(config-tunnel)#seq 20 ipsec-policy ipsec_Pol2 access-group ipsec_ACL2

The following example shows how to create an IPsec tunnel, IPsec_tunnel_1 , using IKE. The IPsec tunnel includes two IPsec policies, each with an associated IPsec ACL:

[local]Redback(config)#tunnel ipsec IPsec_tunnel_1
[local]Redback(config-tunnel)#ike policy IKE_Pol1
[local]Redback(config-tunnel)#df-bit clear
[local]Redback(config-tunnel)#bind interface ipsec-if1
[local]Redback(config-tunnel)#peer-end-point local 172.16.1.1 remote 172.16.1.2
[local]Redback(config-tunnel)#remote-id 72.0.0.1
[local]Redback(config-tunnel)#seq 10 ipsec-policy ipsec_Pol1 access-group ipsec_ACL1
[local]Redback(config-tunnel)#seq 20 ipsec-policy ipsec_Pol2 access-group ipsec_ACL2

The following example shows how to create the manual key manualIPsec_tunnel_1 IPsec tunnel. The IPsec tunnel includes two manually-keyed SAs, each with an associated IPsec ACL:

[local]Redback(config)#tunnel ipsec manual_IPsec_tunnel_1 manual
[local]Redback(config-tunnel)#ike policy IKE_Pol1
[local]Redback(config-tunnel)#df-bit clear
[local]Redback(config-tunnel)#bind interface ipsec-if1
[local]Redback(config-tunnel)#peer-end-point local 172.16.1.1 remote 172.16.1.2
[local]Redback(config-tunnel)#remote-id 72.0.0.1
[local]Redback(config)#tunnel ipsec manualIPsec_tunnel_1
[local]Redback(config-tunnel)#seq 10 security association ipsec_sa_1 access-group ipsec_ACL1
[local]Redback(config-tunnel)#seq 20 security association ipsec_sa_2 access-group ipsec_ACL2

7   IPsec Monitoring Commands

Show commands display a variety of information for IPsec tunnel endpoints, as shown in Table 1. Enter show commands in any mode.

For more information about show commands see Reference [5].

8   Clear IPsec VPN SAs

Without clearing SAs, if you make any configuration changes to IPsec tunnels (except changes to IPsec ACLs) that affect SAs, the changes do not take effect until the current SA lifetime expires and new SAs are negotiated and established. Clear SAs when you want an updated IPsec configuration setup to take effect immediately after making the changes. These commands restart the SAs with the most current configuration settings. If the IPsec tunnel is in manual mode, new manual SAs are created immediately. If IPsec tunnel SAs are created using the IKE protocol, the SAs and attributes are renegotiated using IKE before new ones are established.

You can clear the SAs associated with specific policies and IPsec tunnels:

• To clear IKE SAs associated with a specific tunnel, enter the following command in exec mode:

  clear ike sa tunnel tunnel-name

• To clear IPsec SAs associated with a specific tunnel, enter the following command in exec mode:

  clear ipsec sa tunnel tunnel-name

9   Sample End-to-End Configurations

Example 15 and Example 16 provide excerpts from the configuration files from both SmartEdge routers at each end of the same IPsec tunnel.

!
asp pool pool1 service security
 asp 1/1
asp pool pool2 service security
 asp 1/2
asp group group1
 pool pool1
 asp-count 1
asp group group2
 pool pool2
 asp-count 1
!
context local
! 
 no ip domain-lookup
!
 interface mgmt
  ip address 10.192.16.250/23
 logging console
!
!
 administrator test encrypted 1 
     $1$........$kvQfdsjs0ACFMeDHQ7n/o.
   privilege start 15
   no timeout session idle
!
!
 ip route 0.0.0.0/0 10.192.17.254
!


!
context vpnEndA
! 
 no ip domain-lookup
!
 interface N2X-port1
  ip address 50.0.0.254/8
!
 interface ipsec_local_loopback1 loopback
  ip address 30.0.0.1/32
 !
 interface to_ipsec_peer
  ip address 40.0.0.1/16
!
 interface tunnel_ipsec_1
  ip address 55.0.1.1/30
 no logging console
!
 ip route 20.0.0.0/8 40.0.0.2
 ip route 60.1.0.1/32 tunnel_ipsec_1
 !
!
 security-mode circuit
 asp-group group1 service security
 ike policy ike-pol1
  mode aggressive
  identity local 30.0.0.1
  preshared-key 123456789123456
  identity remote 20.1.0.2
  seq 10 proposal ike-prop
!
ipsec access-list any-acl
 seq 10 any any
!
!
! ** End Context **
 logging tdm console
 logging active
 logging standby short
!
!
tunnel ipsec rec_1_1
 peer-end-point local 30.0.0.1 remote 20.1.0.2 context 
   vpnEndA
 bind interface tunnel_ipsec_1 vpn1
 remote-id 20.1.0.2
 ike-policy ike-pol1
 seq 10 ipsec-policy ipsec-pol access-group any-acl
!
!
!Ethernet connectivity fault management configuration
!
ike proposal ike-prop
 authentication algorithm hmac-md5-96
 encryption algorithm des-cbc
 dh-group 1
 !
ipsec proposal ipsec-prop
 esp encryption 3des-cbc
 esp authentication hmac-sha1-96
 !
ipsec policy ipsec-pol
 seq 10 proposal ipsec-prop
!
!
card ase 1
!
card ether-12-port 3
!
port ethernet 3/1
 no shutdown
 bind interface N2X-port1 vpnEndA
!
port ethernet 3/11
 no shutdown
 bind interface to_ipsec_peer vpnEndA
!
!
port ethernet 7/1
! XCRP management ports on slot 7 and 8 are
! configured through 7/1
 no shutdown
 bind interface mgmt local
! 
! 
 boot configuration ipsec-demo-15.cfg
!
no service console-break
!
service crash-dump-dram
!
no service auto-system-recovery
!
end

!
asp pool pool1 service security
 asp 1/1
asp pool pool2 service security
 asp 1/2
asp group group1
 pool pool1
 asp-count 1
asp group group2
 pool pool2
 asp-count 1
!
context local
! 
 no ip domain-lookup
!
 interface mgmt
  ip address 10.192.16.250/23
 logging console
!
!
 administrator test encrypted 1 
       $1$........$kvQfdsjs0ACFMeDHQ7n/o.
   privilege start 15
   no timeout session idle
!
!
 ip route 0.0.0.0/0 10.192.17.254
!


!
context vpnEndB
! 
 no ip domain-lookup
!
 interface N2X-port2
  ip address 60.0.0.254/8
!
 interface ipsec_local_loopback1 loopback
  ip address 20.1.0.2/32
!
 interface to_ipsec_peer
  ip address 40.0.0.2/30

 interface tunnel_ipsec_1
  ip address 55.0.1.2/30
!
 no logging console
!
 ip route 30.0.0.0/8 40.0.0.1
 ip route 50.1.0.1/32 tunnel_ipsec_1
!


!
 security-mode circuit
 asp-group group2 service security
 ike policy ike-pol1
  mode main
  identity local 20.1.0.2
  preshared-key 123456789123456
  identity remote 30.0.0.1
  seq 10 proposal ike-prop

!
ipsec access-list any-acl
 seq 10 any any
!
!
! ** End Context **
 logging tdm console
 logging active
 logging standby short
!
!
tunnel ipsec rec_2_1
 peer-end-point local 20.1.0.2 remote 30.0.0.1 context 
   vpnEndB
 bind interface tunnel_ipsec_1 vpn2
 remote-id 30.0.0.1
 ike-policy ike-pol1
 seq 10 ipsec-policy ipsec-pol access-group any-acl
!
!
!Ethernet connectivity fault management configuration
!
ike proposal ike-prop
 authentication algorithm hmac-md5-96
 encryption algorithm des-cbc
 dh-group 1
 !
ipsec proposal ipsec-prop
 esp encryption 3des-cbc
 esp authentication hmac-sha1-96
 !
ipsec policy ipsec-pol
 seq 10 proposal ipsec-prop
!
!
card ase 1
!
card ether-12-port 3
!
port ethernet 3/2
 no shutdown
 bind interface N2X-port2 vpnEndB
!
port ethernet 3/12
 no shutdown
 bind interface to_ipsec_peer vpnEndB
!
!
port ethernet 7/1
! XCRP management ports on slot 7 and 8
! are configured through 7/1
 no shutdown
 bind interface mgmt local
! 
! 
 boot configuration ipsec-demo-15.cfg
!
no service console-break
!
service crash-dump-dram
!
no service auto-system-recovery
!
end

10   High Availability Configuration

You can provide high availability for IPsec tunnels by setting up redundant connections between the local SmartEdge router and the remote security gateway. You configure two tunnels in different security-enabled contexts and configure routing to switch between tunnels. After the tunnels are up, traffic is routed over the preferred tunnel. If the ASP associated with the preferred tunnel fails, the tunnel goes down and its traffic is automatically rerouted over the second tunnel. When the preferred tunnel recovers, its traffic is automatically switched back to the preferred tunnel.

Figure 10 illustrates the relationships between the various components of the example high availability configuration presented in this section.

To configure redundant IPsec tunnel connectivity between context C1 on the SmartEdge router and a remote security gateway:

1. Create the required ASP pools and groups, and two ASP groups.
   1. Create two ASP pools, each with one ASP; for example, create ASP pool P1 and enroll the first ASP on the ASE card in slot 5, and ASP pool P2 and enroll the second ASP on the ASE card in slot 5:

      [local]Redback(config)#asp pool P1 service security
      [local]Redback(config-asp-pool-mode)#asp 5/1
      [local]Redback(config-asp-pool-mode))#commit
      [local]Redback(config)#asp pool P2 service security
      [local]Redback(config-asp-pool-mode)#asp 5/2
      [local]Redback(config-asp-pool-mode))#commit
      [local]Redback(config-asp-pool-mode))#exit

   2. Create two ASP groups, point one ASP group to one ASP pool, and the other group to the other pool; for example, create ASP group G1 and point it to ASP pool P1, and ASP group G2 and point it to ASP pool P2:

      [local]Redback(config)#asp group G1
      [local]Redback(config-asp-group-mode)#pool P1
      [local]Redback(config-asp-group-mode)#commit
      [local]Redback(config-asp-group-mode)#exit
      [local]Redback(config)#asp group G2
      [local]Redback(config-asp-group-mode)#pool P2
      [local]Redback(config-asp-group-mode)#commit
      [local]Redback(config-asp-group-mode)#exit

2. Configure the required IKE proposals, IPsec proposals, and IPsec policies. For example:

   [local]Redback(config)#ike proposal ike-proposal
   [local]Redback(config-ike-proposal)#authentication algorithm 
   hmac-md5-96
   [local]Redback(config-ike-proposal)#encryption algorithm 
   3des-cbc
   [local]Redback(config-ike-proposal)#commit
   [local]Redback(config-ike-proposal)#exit
   [local]Redback(config)#ipsec proposal ipsec-proposal
   [local]Redback(config-ipsec-proposal)#esp encryption 
   aes-128-cbc
   [local]Redback(config-ipsec-proposal)#esp authentication 
   hmac-sha1-96
   [local]Redback(config-ipsec-proposal)#commit
   [local]Redback(config-ipsec-proposal)#exit
   [local]Redback(config)#ipsec policy ipsec-policy
   [local]Redback(config-ipsec-policy)#seq 10 proposal ipsec-
   proposal
   [local]Redback(config-ipsec-policy)#commit
   [local]Redback(config-ipsec-policy)#exit
   

3. Create a context for the required interfaces, ACLs, and IP routes. For example, context C1:

   [local]Redback(config)#context C1
   [local]Redback(context)#commit

4. Create two contexts for the two IPsec tunnels. For example, contexts L1 and L2:

   [local]Redback(config)#context L1
   [local]Redback(config)#context L2
   [local]Redback(context)#commit

5. Configure contexts L1 and L2. Create a loopback interface to identify the gateway, configure an IKE policy, enable the Security service, and create a static route for signalling traffic. For example, in context L1 create a loopback interface, Tun-1-Local, an IKE policy, ike-policy1, associate ASP group G1 with this context to enable Security service, and specify an IP route for signalling traffic:

   [local]Redback(config)#context L1
   
   [local]Redback(config-ctx)#interface Tun-1-Local
     loopback
   [local]Redback(config-if)#ip address 1.1.1.1/32
   [local]Redback(config-if)#commit
   [local]Redback(config-if)#exit
   [local]Redback(config-ctx)#ike policy ike-policy1
   [local]Redback(config-ike-policy)#identity
     local 1.1.1.1
   [local]Redback(config-ike-policy)#pre-shared-key 
   TEST_SHARED_KEY
   [local]Redback(config-ike-policy)#seq 10 proposal 
   ike-proposal
   [local]Redback(config-ike-policy)#commit
   [local]Redback(config-ike-policy)#exit
   [local]Redback(config-ctx)#asp-group G1
     service security
   [local]Redback(config-ctx)#ip route 3.3.3.3/32 4.4.4.4
   [local]Redback(config-ctx)#commit
   [local]Redback(config-ctx)#exit
   

   Repeat these configuration steps in context L2, create a loopback interface, Tun-2-Local, an IKE policy, ike-policy2, associate ASP group G2 with this context to enable Security service, and specify an IP route for signalling traffic

6. Create the required tunnel and peer interfaces in context C1. For example, create two tunnel interfaces, TI-1 and TI-2, and an interface to the protected network, private-interface:

   [local]Redback(config)#context C1
   [local]Redback(config-ctx)#interface TI-1
   [local]Redback(config-if)#ip address 192.168.2.1/30
   [local]Redback(config-if)#commit
   [local]Redback(config-if)#exit
   [local]Redback(config-ctx)#interface TI-2
   [local]Redback(config-if)#ip address 192.168.3.1/30
   [local]Redback(config-if)#commit
   [local]Redback(config-if)#exit
   [local]Redback(config-ctx)#interface private-interface
   [local]Redback(config-if)#ip address 172.168.3.0/24
   [local]Redback(config-if)#commit
   [local]Redback(config-if)#exit

7. Create an IPsec ACL in context C1 to filter traffic between the two peers. For example, create the ACL acl-C1:

   [local]Redback(config)#context C1
   [local]Redback(config-ctx)#ipsec access-list acl-C1
   [local]Redback(config-ipsec-acl)#seq 10 172.168.2.0/24 
   172.168.3.0/24
   

8. Create two IPsec tunnels, one in each security-enabled context:. For example, create Tun-1 in context L1 and Tun-2 in context L2:

   [local]Redback(config)#tunnel ipsec Tun-1
   [local]Redback(config-tunnel)#peer-end-point local 1.1.1.1 
   remote 3.3.3.3 context L1
   [local]Redback(config-tunnel)#bind interface TI-1 C1
   [local]Redback(config-tunnel)#remote-id 3.3.3.3
   [local]Redback(config-tunnel)#ike-policy ike-policy1
   [local]Redback(config-tunnel)#seq 10 ipsec-policy 
   ipsec-policy access-group acl-C1
   

   Repeat this step to create the second tunnel Tun-2 in context L2, using appropriate values.

9. Create either static or dynamic IP routes between the remote protected network and each tunnel interface so that the traffic that flows over the tunnel is protected in context C1. Assign the IP routes over one tunnel a lower cost than the IP routes over the second tunnel. For example, create two static IP routes and assign a lower cost to IP routes on the tunnel interface TI-1 used by Tun-1 in context L1 and a higher cost to IP routes learned on the tunnel interface TI-2 used by Tun-2 in context L2:

   [local]Redback(config)#context C1
   [local]Redback(config-ctx)#ip route 172.168.3.0/24 TI-1 
   cost 5
   [local]Redback(config-ctx)#ip route 172.168.3.0/24 TI-2 
   cost 10
   [local]Redback(config-ctx)#commit
   [local]Redback(config-ctx)#exit
   

While both tunnels are up, traffic is routed over the lower cost tunnel Tun-1 in context L1. After the ASP associated with ASP group G1 fails, Tun-1 will go down and traffic will be automatically routed over Tun-2, until Tun-1 recovers. Example 17 provides a configuration that matches the above procedure.

! Global asp pool config

asp pool P1 service security
asp 2/1
asp group G1
pool P1
asp-count 1

asp pool P2 service security
asp 2/2
asp group G2
pool P2
asp-count 1



context C1
interface TI-1
ip address 192.168.2.1/30

interface TI-2
ip address 192.168.3.1/30

interface private-interface
ip address 172.168.2.1/24

ipsec access-list acl-C1
seq 10 172.168.2.0/24 172.168.3.0/24

ip route 172.168.3.0/24 TI-1 cost 5
ip route 172.168.3.0/24 TI-2 cost 10




context L1
interface Tun-1-Local loopback
ip address 1.1.1.1/32

ike policy ike-policy1
identity local 1.1.1.1
pre-shared-key TEST_SHARED_KEY
seq 10 proposal ike-proposal

asp-group G1 service security

ip route 3.3.3.3/32 4.4.4.4

context L2
interface Tun-2-Local loopback
ip address 2.2.2.2/32

ike policy ike-policy2
identity local 2.2.2.2
pre-shared-key TEST_SHARED_KEY
seq 10 proposal ike-proposal

asp-group G2 service security

ip route 3.3.3.3/32 5.5.5.5



! Global Configuration

ike proposal ike-proposal
authentication algorithm hmac-md5-96
encryption algorithm 3des-cbc

ipsec proposal ipsec-proposal
esp encryption aes-128-cbc
esp authentication hmac-sha1-96

ipsec policy ipsec-policy
seq 10 proposal ipsec-proposal

tunnel ipsec Tun-1
peer-end-point local 1.1.1.1 remote 3.3.3.3 context L1
bind interface TI-1 C1
remote-id 3.3.3.3
ike-policy ike-policy1
seq 10 ipsec-policy ipsec-policy access-group acl-C1

tunnel ipsec Tun-2
peer-end-point local 2.2.2.2 remote 3.3.3.3 context L2 
bind interface TI-2 C1 
remote-id 3.3.3.3 
ike-policy ike-policy2 
seq 10 ipsec-policy ipsec-policy access-group acl-C1

11   Restoring an IPsec VPN Following Service Disruption

IPsec VPN service is disrupted when a context associated with the Security service that is carrying IPsec VPN traffic or tunnels is missing or misconfigured.

Several scenarios can cause this type of service disruption:

• Following a catastrophic shutdown of the node, the node is restarted with an obsolete configuration.

  To resolve the situation, restore the latest backup of the configuration file for the SmartEdge router. If you regularly back up the configuration of the SmartEdge routers in your network to a secure location, the latest backup of the affected SmartEdge router may be more current than the latest version on the CompactFlash memory card.

• A context associated with Security Services has been disassociated or deleted.

  If restoring the most recent backup is unsuccessful, identify the missing or misconfigured context and recreate the context with the correct settings.

• The physical link providing the underlying connectivity for an IPsec tunnel has been incorrectly modified or deleted.

  If restoring the most recent backup is unsuccessful, identify the missing or misconfigured link, then delete and recreate each IPsec tunnel that uses the link; this action takes down and brings up the endpoints used by each IPsec tunnel.

12   Log Messages Resulting from Rejected IKE Packets

Table 2 lists the problems that can occur when processing IKE policies and the log messages that identify them.

13   Log Messages Resulting from Discarded ESP Packets

Table 3 lists the problems that can occur when processing IKE policies and the log messages that identify them.

Glossary

Reference List