Configuring IKE Policies
An IKE policy defines a combination of security parameters (IKE proposals) to be used during IKE negotiation. It defines a peer address and the proposals needed for that connection. Depending on which authentication method is used, it defines the preshared key for the given peer or the local certificate. During the IKE negotiation, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation sends all its policies to the remote peer, and the remote peer tries to find a match.
A match is made when both policies from the two peers have a proposal that contains the same configured attributes. If the lifetimes are not identical, the shorter lifetime between the two policies (from the host and peer) is used. The configured preshared key must also match its peer.
Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. You can configure the specific IKE phase to be supported for the negotiation. However, if only IKEv1 is supported, the Junos OS rejects IKEv2 negotiations. Similarly, if only IKEv2 is supported, the Junos OS rejects all IKEv1 negotiations.
The key management process (kmd) daemon determines which version of IKE is used in a negotiation. If kmd is the IKE initiator, it uses IKEv1 by default and retains the configured version for negotiations. If kmd is the IKE responder, it accepts connections from both IKEv1 and IKEv2.
You can create multiple, prioritized proposals at each peer to ensure that at least one proposal matches a remote peer’s proposal.
First, you configure one or more IKE proposals; then you associate these proposals with an IKE policy. You can also prioritize a list of proposals used by IKE in the policy statement by listing the proposals you want to use, from first to last.
To configure an IKE policy, include the policy statement and specify a policy name at the [edit services ipsec-vpn ike] hierarchy level:
This section includes the following topics:
- Configuring the IKE Phase
- Configuring the Mode for an IKE Policy
- Configuring the Proposals in an IKE Policy
- Configuring the Preshared Key for an IKE Policy
- Configuring the Local Certificate for an IKE Policy
- Configuring the Description for an IKE Policy
- Configuring Local and Remote IDs for IKE Phase 1 Negotiation
- Example: Configuring an IKE Policy
For an example of an IKE policy configuration, see Example: Configuring an IKE Policy.
Configuring the IKE Phase
Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. You can configure the specific IKE phase to be supported for the negotiation. However, if only IKEv1 is supported, the Junos OS rejects IKEv2 negotiations. Similarly, if only IKEv2 is supported, the Junos OS rejects all IKEv1 negotiations.
To configure the IKE phase used, include the version statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
Configuring the Mode for an IKE Policy
IKE policy has two modes: aggressive and main. By default, main mode is enabled. Main mode uses six messages, in three exchanges, to establish the IKE SA. (These three steps are IKE SA negotiation, a Diffie-Hellman exchange, and authentication of the peer.) Main mode also allows a peer to hide its identity.
Aggressive mode also establishes an authenticated IKE SA and keys. However, aggressive mode uses half the number of messages, has less negotiation power, and does not provide identity protection. The peer can use the aggressive or main mode to start IKE negotiation; the remote peer accepts the mode sent by the peer.
![]() | Note: The mode configuration is required only if the version option is set to 1. |
To configure the mode for an IKE policy, include the mode statement and specify aggressive or main at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
Configuring the Proposals in an IKE Policy
The IKE policy includes a list of one or more proposals associated with an IKE policy.
To configure the proposals in an IKE policy, include the proposals statement and specify one or more proposal names at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
Configuring the Preshared Key for an IKE Policy
When you include the authentication-method pre-shared-keys statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level, IKE policy preshared keys authenticate peers; for more information, see Configuring the Authentication Method for an IKE Proposal. You must manually configure a preshared key, which must match that of its peer. The preshared key can be an ASCII text (alphanumeric) key or a hexadecimal key.
To configure the preshared key in an IKE policy, include the pre-shared-key statement and a key at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
The key can be one of the following:
- ascii-text—ASCII text key. With the des-cbc option, the key contains 8 ASCII characters. With the 3des-cbc option, the key contains 24 ASCII characters.
- hexadecimal—Hexadecimal key. With the des-cbc option, the key contains 16 hexadecimal characters. With the 3des-cbc option, the key contains 48 hexadecimal characters.
Configuring the Local Certificate for an IKE Policy
When you include the authentication-method rsa-signatures statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level, public key infrastructure (PKI) digital certificates authenticate peers; for more information, see Configuring the Authentication Method for an IKE Proposal. You must identify a local certificate that is sent to the peer during the IKE authentication phase.
To configure the local certificate for an IKE policy, include the local-certificate statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
The local-certificate statement specifies the identifier used to obtain the end entity’s certificate from the certification authority. Configuring it in an IKE policy allows you the flexibility of using a separate certificate with each remote peer if that is needed. You must also specify the identity of the certification authority by configuring the ca-profile statement at the [edit security pki] hierarchy level; for more information, see the Junos OS System Basics Configuration Guide. For complete examples of digital certificate configuration, see the Junos OS Feature Guides.
You can use the configured profiles to establish a set of trusted certification authorities for use with a particular service set. This enables you to configure separate service sets for individual clients to whom you are providing IP services; the distinct service sets provide logical separation of one set of IKE sessions from another, using different local gateway addresses, or virtualization. To configure the set of trusted certification authorities, include the trusted-ca statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level:
For more information, see Configuring IPsec Service Sets.
Configuring a Certificate Revocation List
A certificate revocation list (CRL) contains a list of digital certificates that have been cancelled before their expiration date. When a participating peer uses a digital certificate, it checks the certificate signature and validity. It also acquires the most recently issued CRL and checks that the certificate serial number is not on that CRL.
![]() | Note: By default, certificate revocation list verification is enabled. You can disable CRL verification by including the disable statement at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level. By default, if the router either cannot access the Lightweight Directory Access Protocol (LDAP) URL or retrieve a valid certificate revocation list, certificate verification fails and the IPsec tunnel is not established. To override this behavior and permit the authentication of the IPsec peer when the CRL is not downloaded, include the disable on-download-failure statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level. |
To use the CA certificate revocation list, you include statements at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level. For details, see the Junos OS System Basics Configuration Guide.
Configuring the Description for an IKE Policy
To specify an optional text description for an IKE policy, include the description statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
Configuring Local and Remote IDs for IKE Phase 1 Negotiation
You can optionally specify local identifiers for use in IKE phase 1 negotiation. If the local-id statement is omitted, the local gateway address is used.
To specify one or more local IDs, include the local-id statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
You can also specify remote gateway identifiers for which the IKE policy is used. The remote gateway address in which this policy is defined is added by default.
To specify one or more remote IDs, include the remote-id statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
The any-remote-id option allows any remote address to connect. This option is supported only in dynamic endpoints configurations and cannot be configured along with specific values. For more information about dynamic endpoint configurations, see Configuring Dynamic Endpoints for IPsec Tunnels.
Example: Configuring an IKE Policy
Define two IKE policies: policy 10.1.1.2 and policy 10.1.1.1. Each policy is associated with proposal-1 and proposal-2. The following configuration uses only IKEv1 for negotiation.
![]() | Note: Updates to the current IKE proposal and policy configuration are not applied to the current IKE SA; updates are applied to new IKE SAs. If you want the new updates to take immediate effect, you must clear the existing IKE security associations so that they will be reestablished with the changed configuration. For information about how to clear the current IKE security association, see the Junos OS Operational Mode Commands. |