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

IPsec VPN Configuration and Operation Using the SmartEdge OS CLI

© 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

SmartEdge is a registered trademark of Telefonaktiebolaget L M Ericsson.
NetOp is a trademark of Telefonaktiebolaget L M Ericsson.

Contents

1Introduction
1.1Scope
1.2Target Groups

2

IPsec VPN Introduction
2.1Prerequisites
2.2Site-to-Site Connections Examples
2.3IPsec VPN Setup and Activation Using IKE

3

IKE Configuration
3.1Configure IKE Proposals
3.2Enable and Disable IKE Keepalive
3.3IKE Policy Configuration

4

AAA Configuration

5

IPsec Configuration
5.1Configure IPsec Proposals
5.2Configure IPsec Policies
5.3Configure IPsec SAs
5.4Configure IPsec ACLs

6

IPsec Tunnel Configuration
6.1Prerequisites
6.2Configure an Auto Key IPsec Tunnel Endpoint
6.3Configure an On-Demand Auto Key IPsec Tunnel
6.4Configure a Manual Key IPsec Tunnel
6.5Configuration Examples

7

IPsec Monitoring Commands

8

Clear IPsec VPN SAs

9

Sample End-to-End Configurations

10

High Availability Configuration

11

Restoring an IPsec VPN Following Service Disruption

12

Log Messages Resulting from Rejected IKE Packets

13

Log Messages Resulting from Discarded ESP Packets

Glossary

Reference List


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:

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.

Figure 1   An IPsec VPN Between Two Managed SmartEdge Routers

Figure 2   An IPsec Tunnel Between a Managed SmartEdge Router and an Extranet Device

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.

Figure 3   An IPsec Tunnel That Protects Traffic Between Two SmartEdge Routers

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.

Figure 4   An IPsec Tunnel That Protects Traffic Between Customer Equipment and a SmartEdge Router

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.

Figure 5   Service Provider Data Requiring Encryption

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:

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:

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:

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:
  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:

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

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

Figure 6   IKE Policy Parameters

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:
  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

You can use AAA to obtain the preshared key for a specific remote peer from an external RADIUS server by configuring pre-shared-key use-aaa during IKE policy configuration. The preshared key can only be obtained using AAA for on-demand IPsec tunnels.

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:

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:
  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:

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

Figure 7   IPsec Policy Parameters

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:
  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:
  3. After entering any of these commands, configure the following in IPsec SA SPI configuration mode:
  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.

Figure 8   IPsec Policy Configuration

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:
  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.

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.

Figure 9   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:

6.2   Configure an Auto Key IPsec Tunnel Endpoint

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

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:

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:

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:

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.

Table 1    IPsec Monitoring Commands

To display the following information...

Enter this command...

IKE configuration in the current context or all contexts

show configuration ike [all-contexts] [verbose]

IPsec configuration in the current context or all contexts

show configuration ipsec [all-contexts] [verbose]

Tunnel configuration in the current context or all contexts

show configuration tunnel [all-contexts] [verbose]

One or more IKE policies configured in the IPsec VPN application for the specified ASP; context-specific

show ike [asp slot/asp-id] policy [policy-name]

One or more IKE proposals configured in the IPsec VPN application for the specified ASP

show ike [asp slot/asp-id] proposal [proposal-name]

IKE statistics associated with the given tunnel

show ike statistics tunnel tunnel-name

One or more IPsec ACLs configured in the IPsec VPN application for the specified ASP; context-specific

show ipsec [asp slot/asp-id] access-list [ipsec-acl-name]

One or more IPsec policies configured in the IPsec VPN application for the specified ASP

show ipsec [asp slot/asp-id] policy [policy-name]

One or more IPsec profiles configured in the IPsec VPN application for the specified ASP

show ipsec [asp slot/asp-id] profile [profile-name]

One or more IPsec proposals configured in the IPsec VPN application for the specified ASP

show ipsec [asp slot/asp-id] proposal [proposal-name]

One or more IPsec SAs configured in the IPsec VPN application for the specified ASP

show ipsec [slot/asp-id] security-association [sa-name]

One or more IPsec tunnels configured in the IPsec VPN application

show tunnel ipsec [name tunnel-name | remote ip-address] [detail]] | [[name tunnel-name] on-demand]

Statistics associated with the specified IPsec tunnel

show tunnel ipsec tunnel-name [on-demand] statistics

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:

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.

Example 1   Configuration of the SmartEdge Router at End A of an 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

Example 2   Configuration of the SmartEdge Router at End B of an 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 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.

Figure 10   Relationships of the Components of a High Availability Configuration

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.

Example 3   High Availability Configuration

! 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:

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.

Table 2    Log Messages Resulting from Rejected IKE Packets

Problem

Sample Message

Recommended Action

Mismatched preshared key

  • Payload Length(19136) is greater than the supported length(263)

  • Possibly Mismatching Keys detected in IKE phase-I 5th/6th messages

  • Sending phase-I notify of type UNEQUAL_PAYLOAD_LENGTHS

Check the IKE policies defined at each endpoint to ensure that the preshared keys match.

Mismatched Diffie-Hellman (DH) group

Mismatching DH Group(2) detected, configured is (5) in IKE phase-I 1st message

Check the IKE policies defined at each endpoint to ensure that the DH group values match.

Mismatched exchange type

  • Mismatching Xchange Type (MAIN_MODE) detected, configured is (AGGRESSIVE_MODE) in IKE phase-I 1st message

  • received unprotected message of notify type UNSUPPORTED_EXCHANGE_TYPE

Check the IKE policies defined at each endpoint to ensure that the exchange types match.

Mismatched authentication algorithm

Mismatching Authentication algorithm (IKE_MD5) detected, configured is (IKE_SHA) in IKE phase-I 1st message.

Check the IKE policies defined at each endpoint to ensure that the authentication algorithms match.

Mismatched encryption algorithm

Mismatching Encryption algorithm (DES_CBC) detected, configured is (TRIPLE_DES_CBC) in IKE phase-I 1st message.

Check the IKE policies defined at each endpoint to ensure that the encryption algorithms match.

Mismatched authentication method

Mismatching Authentication method (PRE_SHAREDKEY) detected, configured is (RSA_SIGN) in phase-I message agent=IKE.

Check the IKE policies defined at each endpoint to ensure that the authentication methods match.

Mismatched ID data in the IKE policy when the authentication method uses digital certificates

  • ID type (ID_DER_ASN1_DN) and ID data /CN=ours not matching with the configured IKE policies

  • ID type (ID_IPV4_ADDR) and ID data 172.16.5.72 not matching with the configured IKE policies

  • ID type (ID_USER_FQDN) and ID data xz@x.com not matching with the configured IKE policies

  • ID type (ID_FQDN) and ID data dkoop.ours.com not matching with the configured IKE policies

  • NO CERT found that matches with at least 1 remoteid configured in IKE policy

  • Sending phase-I notify of type INVALID_ID_INFORMATION

Check the IKE policies defined at each end to ensure that the ID data match when the authentication method uses digital certificates.

Mismatched ID data for dial-in users in the IKE policy when the authentication method uses digital certificates

  • ID type (ID_DER_ASN1_DN) and ID data /CN=ours not matching with any of the configured IKE policies

  • ID type (ID_IPV4_ADDR) and ID data 172.16.5.72 not matching with any of the configured IKE policies

  • ID type (ID_USER_FQDN) and ID data xz@x.com not matching with any of the configured IKE policies

  • ID type (ID_FQDN) and ID data dkoop.ours.com not matching with any of the configured IKE policies

  • NO CERT found that matches with at least 1 remoteid configured in IKE policy

  • Sending phase-I notify of type INVALID_ID_INFORMATION

Check the IKE policies defined at each end to ensure that the ID data for dial-in users match when the authentication method uses digital certificates.

Mismatched ID data in the IKE policy when the authentication method uses a preshared key

  • Mismatching ID type (ID_IPV4_ADDR) and ID: 172.16.5.72 with the configured IKE policy agent=IKE

  • Mismatching ID type (ID_FQDN) and ID: dkoop.com with the configured IKE policy

Check the IKE policies defined at each end to ensure that the ID data match when the authentication method uses a preshared key.

Mismatched ID payload with certificate identities

  • Mismatching ID type (ID_FQDN) and ID: dkoop.com with the configured IKE policy

  • ID type (ID_FQDN) and ID data: dkoop.com mismatching with matching Cert ID type(ID_FQDN) and Cert ID: dkoop.ours$

Check the IKE policies at both endpoints to ensure that the ID data match.

Mismatched ID data

received NOTIFY PAYLOAD of notify type INVALID_ID_INFORMATION.

Check the IKE policies at both endpoints to ensure that the ID data match.

First message in main mode contains an invalid next payload

  • Invalid Next Payload type(0x99) detected in IKE message

  • Sending phase-I notify of type INVALID_PAYLOAD_TYPE

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains an invalid Digital Object Identifier (DOI) value

  • Invalid DOI(0x4001) detected in IKE phase-I 1st message

  • Sending phase-I notify of type DOI_NOT_SUPPORTED

DOI used by IKE peer is invalid or not supported. Contact your support representative.

First message in main mode contains an invalid situation value

  • Situation(0x4001) is not supported

  • Sending phase-I notify of type INVALID_NOTIFY_TYPE

Contact your support representative.

First message in main mode contains an invalid initiator cookie value

Invalid Initiator Cookie detected in IKE message.

Reset the VPN connection. If the problem persists, contact your support representative.

First message in main mode contains an invalid major version value in the Internet Security Association and Key Management Protocol (ISAKMP) header (either malformed or noncompliant)

  • Invalid Major Version(0x20) detected in IKE message

  • Sending phase-I notify of type INVALID_MAJOR_VERSION

The version number is invalid. Contact your support representative.

First message in main mode contains an invalid minor version value in the ISAKMP header (either malformed or noncompliant)

  • Invalid Minor Version(0x2) detected in IKE message

  • Sending phase-I notify of type INVALID_MINOR_VERSION

Contact your support representative.

First message in main mode contains an invalid exchange type

Invalid Xchange Type(0x20) detected for non-existing IKE SA .

Reset the VPN connection. If the problem persists, contact your support representative.

First message in main mode contains invalid flags

  • Invalid Flags(0xf0) detected in IKE message

  • Sending phase-I notify of type INVALID_FLAGS

Reset the VPN connection. If the problem persists, contact your support representative.

First message in main mode contains an invalid message ID value

  • Invalid Message ID(0x100100) detected in IKE phase-I message

  • Sending phase-I notify of type INVALID_MESSAGE_ID

Contact your support representative.

First message in main mode contains an invalid protocol ID value

Invalid Protocol ID(0xff) detected.

Contact your support representative.

First message in main mode contains an invalid transform ID value

  • Invalid Xform ID(17) detected in IKE phase-I 1st message

  • Sending phase-I notify of type INVALID_TRANSFORM_ID

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains invalid attributes

  • Unsupported attribute(4099) detected in IKE phase-I 1st message

  • Sending phase-I notify of type ATTRIBUTES_NOT_SUPPORTED

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains a mismatching proposal

  • Mismatching Encryption algorithm (TRIPLE_DES_CBC) detected, configured is (DES_CBC) in IKE phase-I 1st message

  • Sending phase-I notify of type NO_PROPOSAL_CHOSEN

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains an invalid reserved field value in the transform payload

  • Invalid Reserved field value(0x11) detected

  • Sending phase-I notify of type BAD_PROPOSAL_SYNTAX

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains a malformed payload

  • Invalid Reserved field (0x11) detected in IKE phase-1 1st message

  • Sending phase-I notify of type PAYLOAD_MALFORMED

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains an unsupported exchange type

Unsupported XchgType detected.

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

First message in main mode contains a modified payload length in the SA payload

  • Payload Length(68) is greater than SA + Proposal + Xform + Attributes size(56)

  • Sending phase-I notify of type UNEQUAL_PAYLOAD_LENGTH

Check the IKE policies at both endpoints to ensure that the main mode attributes match.

Mismatched DH group in aggressive mode

Mismatching DH Group(2) detected, configured is(5) in IKE phase-II 1st message.

Check the IPsec policies defined at each endpoint to ensure that the DH group values match.

Mismatched authentication algorithm in aggressive mode

Mismatching Authentication algorithm (MD5) detected, configured is (SHA1), in IKE phase-II 1st message .

Check the IPsec policies defined at each endpoint to ensure that the authentication algorithms match.

Mismatched encryption algorithm in aggressive mode

Mismatching Encryption algorithm (ESP_DES) detected, configured is (ESP_AES) in IKE phase-II message.

Check the IPsec policies defined at each endpoint to ensure that the encryption algorithms match.

Selectors information sent in aggressive mode by the initiator

  • Initiator SPD selectors sent: IPADDR, 172.16.5.153, proto 1, port 0

  • Responder SPD selectors sent: IPADDR, 172.16.5.72, proto 1, port 0

None. This is an informational log.

Selectors information received in aggressive mode by responder

  • Initiator SPD selectors received: IPADDR, 172.16.5.72, proto 1, port 0

  • Responder SPD selectors received: IPADDR, 172.16.5.153, proto 1, port 0

None. This is an informational log.

Mismatched selectors in aggressive mode

No matching SPD policy for the selectors received in IKE phase-II message.

Check the IPsec policies defined at each endpoint to ensure that the attributes match.

Mismatched security protocol in aggressive mode

  • Mismatching number of AH protocols recevied(1), configured number of AH protocols: 0 in IKE phase-II 1st message$

  • Mismatching number of ESP protocols recevied(0), configured number of ESP protocols: 1 in IKE phase-II 1st messa$

Check the IPsec policies defined at each endpoint for ESP and AH values, as appropriate, to ensure that the attributes match

Lifetime value is in seconds for lifetime update

  • Notify payload of notify type RESPONDER_LIFETIME with protocol ESP or AH received

  • Received Notify Type RESPOND_NOTIFY with 300 seconds

None. This is an informational log.

Lifetime value is in kilobytes for lifetime update

  • Notify payload of notify type RESPONDER_LIFETIME with protocol ESP or AH received

  • Received Notify Type RESPOND_NOTIFY with 5 Kilo Bytes

None. This is an informational log.

Reception of a delete payload request

  • Received DELETE PAYLOAD of protocol AH detected with SPI : 0x93a8d49d agent=IKE

  • Received DELETE PAYLOAD of protocol ESP detected with SPI : 0x9dd321d6

None. This is an informational log.

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.

Table 3    Log Messages Resulting from Rejected ESP Packets

Cause

Sample Messages

Recommended Action

Mismatched integrity check value in AH header

Authentication failure. Possibly mis-matching keys.

Check the IPsec policies defined at each endpoint to ensure that the attributes match

Mismatched authentication algorithm

Authentication failure. Possibly mis-matching keys agent=IPSEC.

Check the IPsec policies defined at each endpoint to ensure that the authentication algorithms match.

Mismatched integrity check value in ESP header

Authentication failure. Possibly mis-matching keys.

Check the IPsec policies defined at each endpoint to ensure that the attributes match.

Mismatched encapsulation mode

Encapsulation mode differs. Received in Transport mode, where expected in Tunnel mode.

Check the IPsec policies defined at each endpoint to ensure that the encapsulation modes (which must be Tunnel and not Transport) match.

ESP packet resent with the previous SPI

No Inbound SA Found.

None. This is an information log.

Late packet received with an offset greater the antireplay window size

Late Packet falling out of window.

None. This is an information log.

Repeated packet received

Repeated/duplicate packet.

None. This is an information log.


Glossary

ACL
Access Control List
 
AH
Authentication Header
 
CPE
Customer Premises Equipment
 
DF
Don't Fragment
 
DH
Diffie-Hellman
 
DOI
Digital Object Identifier
 
DoS
Denial of Service
 
DPD
Dead Peer Detection
 
ECMP
Equal-Cost Multipath
 
EMS
Element Management System
 
ESP
Encapsulating Security Payload
 
FQDNs
Fully Qualified Domain Names
 
IKE
Internet Key Exchange
 
IPsec
Internet Protocol Security
 
ISAKMP
Internet Security Association and Key Management Protocol
 
MD5
Mismatching Authentication algorithm
 
P2MP
Point-to-Multipoint
 
PFS
Perfect Forward Secrecy
 
SAs
Security Associations
 
SPI
Security Parameter Index
 
VPN
Virtual Private Network

Reference List

[1] Configuring Contexts and Interfaces, 3/1543-CRA 119 1170/1.
[2] Node Configuration Guide, 1543-CRA 119 1171/1.
[3] Configuring Basic IP Routing, 16/1543-CRA 119 1170/1.
[4] Advanced Services Configuration and Operation Using the SmartEdge OS CLI, 1/1543-CRA 119 1170/1.
[5] IPsec VPN Command Reference, 2/190 80-CRA 119 1170/1.