Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring an IKE Policy

Configuring an IKE Policy for Preshared Keys

An IKE policy defines a combination of security parameters (IKE proposals) to be used during IKE negotiation. It defines a peer address, the preshared key for the given peer, and the proposals needed for that connection. 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.

To ensure that at least one proposal will match a remote peer’s proposal, you can create multiple, prioritized proposals at each peer. Do this by configuring the proposal(s) and associating them with an IKE policy, and, optionally, prioritizing the list in the policy statement, where they are evaluated in list order.

Include the policy statement at the [edit security ike] hierarchy level and specify an IPsec tunnel destination as the peer address:

Tasks for configuring an IKE policy are:

Configuring the Description for an IKE Policy

To specify a description for an IKE policy, include the description statement at the [edit security ike policy ike-peer-address] 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 key 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.

To configure IKE policy mode, include the mode statement and specify aggressive or main at the [edit security ike policy ike-peer-address] hierarchy level:

For Junos OS in FIPS mode, the aggressive option for IKEv1 is not supported with the mode statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level.

Configuring the Preshared Key for an IKE Policy

IKE policy preshared keys authenticate peers. 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.

A local certificate is an alternative to the preshared key. A commit operation fails if either a preshared key or a local certificate is not configured.

To configure an IKE policy preshared key, include the pre-shared-key statement at the [edit security ike policy ike-peer-address] hierarchy level:

Associating Proposals with an IKE Policy

The IKE policy proposal is a list of one or more proposals associated with an IKE policy.

To configure an IKE policy proposal, include the proposals statement at the [edit security ike policy ike-peer-address] hierarchy level and specify one or more proposal names:

See Also

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.

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 CLI Explorer.

Note:

When configuring multiple IPSec tunnels between IPSec peers, the IPSec tunnels can terminate on multiple local addresses on a physical interface of an IPSec peer and vice-versa.

See Also