![]() |
SYSTEM ADMINISTRATOR GUIDE 2/1543-CRA 119 1170/1-V1 Uen A | ![]() |
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
SmartEdge | is a registered trademark of Telefonaktiebolaget L M Ericsson. | |
NetOp | is a trademark of Telefonaktiebolaget L M Ericsson. |
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.
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.
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.
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.
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:
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].
For information on how to configure an IP route by using the SmartEdge OS, see Reference [3].
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.
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.
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.
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.
The minimal matching requirements for both endpoints of an IPsec tunnel to successfully complete all negotiations and the setup to become active are:
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:
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:
To configure an IKE proposal:
(config)#ike proposal name
(config-ike-proposal)#description string
(config-ike-proposal)#dh-group dh-group
(config-ike-proposal)#authentication algorithm algorithm
(config-ike-proposal)#encryption algorithm algorithm
(config-ike-proposal)#lifetime seconds seconds
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
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.
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.
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
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.
To configure an IKE policy:
(config-ctx)#ike policy name
(config-ike-policy)#description string
(config-ike-policy)#connection-type type
(config-ike-policy)#identity local fqdn fqdn-string value
(config-ike-policy)#mode mode
(config-ike-policy)#pre-shared-key hex hex-value | ASCII-value | use-aaa
(config-ike-policy)#seq sequence-number proposal name
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
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
IPsec configuration involves configuring IPsec proposals, IPsec policies, IPsec SAs, and IPsec ACLs.
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:
To configure an IPsec proposal:
(config)#ipsec proposal name
(config-ipsec-proposal)#description string
(config-ipsec-proposal)#ip-comp
The no form of the command disables IP compression.
(config-ipsec-proposal)#ah algorithm
The no form of the command removes the AH configuration.
(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.
(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.
(config-ipsec-proposal)#lifetime seconds seconds
(config-ipsec-proposal)#lifetime kbytes kbytes
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
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.
To configure an IPsec policy:
(config)#ipsec policy name
(config-ipsec-policy)#description string
(config-ipsec-policy)#anti-replay-window window-size
(config-ipsec-policy)#perfect-forward-secrecy dh-group dh-group
(config-ipsec-policy)#seq sequence-number proposal name
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
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).
To configure an IPsec SA:
(config)#ipsec security-association sa-name
(config-ipsec-sa)#description string
(config-ipsec-sa)#anti-replay-window window-size
(config-ipsec-sa)#ip-comp
(config-ipsec-sa)#both
(config-ipsec-sa)#in
(config-ipsec-sa)#out
The both command cannot be used with either the in or out command.
(config-ipsec-sa-spi)#esp spi spi-value
(config-ipsec-sa-spi)#esp authentication [algorithm] key hex-argument|ASCII-value
(config-ipsec-sa-spi)#esp encryption null
(config-ipsec-sa-spi)#esp encryption [algorithm] key hex-argument|ASCII-value
(config-ipsec-sa-spi)#ah spi spi-value
(config-ipsec-sa-spi)#ah [algorithm] key hex-argument|ASCII-value
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.
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
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.
To configure an IPsec policy:
(config-ctx)#ipsec access-list acl-name
(config-ipsec-acl)#description string
(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]
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
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.
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.
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.
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 a newly created auto key IPsec VPN endpoint, you must configure:
To configure the endpoints of an auto key IPsec tunnel:
(config)#tunnel ipsec name
Specify only the tunnel name to create an IPsec tunnel using IKE.
(config-tunnel)#bind interface if-name [context-name]
(config-tunnel)#df-bit {propagate | set | clear}
(config-tunnel)#ike-policy ike-policy-name
(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.
(config-tunnel)#remote-id remote_id
(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.
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:
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:
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.
(config)#tunnel ipsec name on-demand
(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.
(config-tunnel)#ike-policy ike-policy-name
(config-tunnel)#max-tunnels value
(config-tunnel)#bind interface if-name [context-name]
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.
(config-ctx)#ipsec profile profile-name
The name of the IPsec profile should match the name of the on-demand IPsec tunnel.
(cfg-ipsec-profile)#df-bit {set | clear}
(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.
For a manual key IPsec VPN endpoint, you must configure:
To configure the endpoints of a manual key IPsec tunnel:
(config)#tunnel ipsec name manual
Specify only the tunnel name to create an IPsec tunnel using IKE.
(config-tunnel)#bind interface if-name [context-name]
(config-tunnel)#df-bit {propagate | set | clear}
(config-tunnel)#ike-policy ike-policy-name
(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.
(config-tunnel)#remote-id remote_id
(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.
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
Show commands display a variety of information for IPsec tunnel endpoints, as shown in Table 1. Enter show commands in any mode.
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].
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:
clear ike sa tunnel tunnel-name
clear ipsec sa tunnel tunnel-name
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
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:
[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
[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
[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
[local]Redback(config)#context C1 [local]Redback(context)#commit
[local]Redback(config)#context L1 [local]Redback(config)#context L2 [local]Redback(context)#commit
[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
[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
[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
[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.
[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
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:
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.
If restoring the most recent backup is unsuccessful, identify the missing or misconfigured context and recreate the context with the correct settings.
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.
Table 2 lists the problems that can occur when processing IKE policies and the log messages that identify them.
Problem |
Sample Message |
Recommended Action |
---|---|---|
Mismatched preshared key |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
DOI used by IKE peer is invalid or not supported. Contact your support representative. |
First message in main mode contains an invalid situation value |
|
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) |
|
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) |
|
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 |
|
Reset the VPN connection. If the problem persists, contact your support representative. |
First message in main mode contains an invalid message ID value |
|
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 |
|
Check the IKE policies at both endpoints to ensure that the main mode attributes match. |
First message in main mode contains invalid attributes |
|
Check the IKE policies at both endpoints to ensure that the main mode attributes match. |
First message in main mode contains a mismatching proposal |
|
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 |
|
Check the IKE policies at both endpoints to ensure that the main mode attributes match. |
First message in main mode contains a malformed payload |
|
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 |
|
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 |
|
None. This is an informational log. |
Selectors information received in aggressive mode by responder |
|
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 |
|
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 |
|
None. This is an informational log. |
Lifetime value is in kilobytes for lifetime update |
|
None. This is an informational log. |
Reception of a delete payload request |
|
None. This is an informational log. |
Table 3 lists the problems that can occur when processing IKE policies and the log messages that identify them.
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. |
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 |
[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. |