IKE Access Profiles

An Internet Key Exchange (IKE) access profile is used to negotiate IKE and IPsec security associations with dynamic peers. You can configure only one tunnel profile per service set for all dynamic peers. The configured preshared key in the profile is used for IKE authentication of all dynamic peers terminating in that service set. You can also use the digital certificate method for IKE authentication with dynamic peers. Include the ike-policy policy-name statement at the [edit access profile profile-name client * ike] hierarchy level. policy-name is the name of the IKE policy you define at the [edit services ipsec-vpn ike policy policy-name] hierarchy level.

The IKE tunnel profile specifies all the information you need to complete the IKE negotiation. Each protocol has its own statement hierarchy within the client statement to configure protocol-specific attribute value pairs, but only one client configuration is allowed for each profile. The following is the configuration hierarchy.

For dynamic peers, the Junos OS supports only IKE main mode with both the preshared key and digital certificate methods. In this mode, an IPv6 or IPv4 address is used to identify a tunnel peer to obtain the preshared key or digital certificate information. The client value * (wildcard) means that configuration within this profile is valid for all dynamic peers terminating within the service set accessing this profile.

The following statement makes up the IKE profile:

• allowed-proxy-pair—During phase 2 IKE negotiation, the remote peer supplies its network address (remote) and its peer’s network address (local). Since multiple dynamic tunnels are authenticated through the same mechanism, this statement must include the list of possible combinations. If the dynamic peer does not present a valid combination, the phase 2 IKE negotiation fails.

By default, remote 0.0.0.0/0 local 0.0.0.0/0 is used if no values are configured.

• dead-peer-detection—Enable the device to use dead peer detection (DPD). DPD is a method used by devices to verify the current existence and availability of IPsec peer devices. A device performs this verification by sending encrypted IKE Phase 1 notification payloads (R-U-THERE) to peers and waiting for DPD acknowledgements (R-U-THERE-ACK).Use the option interval to specify the seconds between which messages should be sent. Use the threshold option to specify the maximum number of messages (1-10) to be sent.

• ike-policy—Name of the IKE policy that defines either the local digital certificate or the preshared key used to authenticate the dynamic peer during IKE negotiation. You must include this statement to use the digital certificate method for IKE authentication with a dynamic peer. You define the IKE policy at the [edit services ipsec-vpn ike policy policy-name] hierarchy level.

• initiate-dead-peer-detection—Detects dead peers on dynamic IPsec tunnels.

• interface-id—Interface identifier, a mandatory attribute used to derive the logical service interface information for the session.

• ipsec-policy—Name of the IPsec policy that defines the IPsec policy information for the session. You define the IPsec policy at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy level. If no policy is set, any policy proposed by the dynamic peer is accepted.

• pre-shared-key—Key used to authenticate the dynamic peer during IKE phase 1 negotiation. This key is known to both ends through an out-of-band secure mechanism. You can configure the value either in hexadecimal or ascii-text format. It is a mandatory value.

• reverse-route —(M Series and MX Series routers with an AS or MultiServices PIC only) Configure a reverse route for dynamic endpoint IPsec tunnels.