IPsec Tunnels With Dynamic Endpoints

The remote (dynamic peer) initiates the negotiations with the local (Juniper Networks) router. The local router uses the default IKE and IPsec policies to match the proposals sent by the remote peer to negotiate the security association (SA) values. Implicit proposals contain a list of all the supported transforms that the local router expects from all the dynamic peers.

If preshared key authentication is used, the preshared key is global for a service set. When seeking the preshared key for the peer, the local router matches the peer’s source address against any explicitly configured preshared keys in that service set. If a match is not found, the local router uses the global preshared key for authentication.

Phase 2 of the authentication matches the proxy identities of the protected hosts and networks sent by the peer against a list of configured proxy identities. The accepted proxy identity is used to create the dynamic rules for encrypting the traffic. You can configure proxy identities by including the allowed-proxy-pair statement in the IKE access profile. If no entry matches, the negotiation is rejected.

If you do not configure the allowed-proxy-pair statement, the default value ANY(0.0.0.0/0)-ANY is applied, and the local router accepts any proxy identities sent by the peer. Both IPv4 and IPv6 addresses are accepted, but you must configure all IPv6 addresses manually.

Once the phase 2 negotiation completes successfully, the router builds the dynamic rules and inserts the reverse route into the routing table using the accepted proxy identity.

After successful negotiation with the dynamic peer, the key management process (kmd) creates a dynamic rule for the accepted phase 2 proxy and applies it on the local AS or Multiservices PIC. The source and destination addresses are specified by the accepted proxy. This rule is used to encrypt traffic directed to one of the end hosts in the phase 2 proxy identity.

The dynamic rule includes an ipsec-inside-interface value, which is the interface name assigned to the dynamic tunnel. The source-address and destination-address values are accepted from the proxy ID. The match-direction value is input for next-hop-style service sets.

Rule lookup for static tunnels is unaffected by the presence of a dynamic rule; it is performed in the order configured. When a packet is received for a service set, static rules are always matched first.

Dynamic rules are matched after the rule match for static rules has failed.

Response to dead peer detection (DPD) hello messages takes place the same way with dynamic peers as with static peers. Initiating DPD hello messages from dynamic peers is not supported.

Static routes are automatically inserted into the route table for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities.

Each route is created based on the remote proxy network and mask sent by the peer and is inserted in the relevant route table after successful phase 1 and phase 2 negotiations.

The route preference for each static reverse route is 1. This value is necessary to avoid conflict with similar routes that might be added by the routing protocol process (rpd).

No routes are added if the accepted remote proxy address is the default (0.0.0.0/0). In this case you can run routing protocols over the IPsec tunnel to learn routes and add static routes for the traffic you want to be protected over this tunnel.

For next-hop-style service sets, the reverse routes include next hops pointing to the locations specified by the inside-service-interface statement.

The route table in which to insert these routes depends on where the inside-service-interface location is listed. If these interfaces are present in a VPN routing and forwarding (VRF) instance, then routes are added to the corresponding VRF table; otherwise, the routes are added to inet.0.

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. Alternatively, you can include the ike-policy statement to reference an IKE policy you define with either specific identification values or a wildcard (the any-remote-id option). You configure the IKE policy at the [edit services ipsec-vpn ike] hierarchy level.

The IKE tunnel profile specifies all the information needed 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 at the [edit access] hierarchy level; for more information on access profiles, see the Junos OS Administration Library for Routing Devices.

The following statements make 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. Both IPv4 and IPv6 address formats are supported in this configuration, but there are no default IPv6 addresses. You must specify even 0::0/0.

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

• ike-policy—Policy that defines the remote identification values corresponding to the allowed dynamic peers; can contain a wildcard value any-remote-id for use in dynamic endpoint configurations only.

• interface-id—Interface identifier, a mandatory attribute used to derive the logical services 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.

To complete the configuration, you need to reference the IKE access profile configured at the [edit access] hierarchy level. To do this, include the ike-access-profile statement at the [edit services service-set name ipsec-vpn-options] hierarchy level:

The ike-access-profile statement must reference the same name as the profile statement you configured for IKE access at the [edit access] hierarchy level. You can reference only one access profile in each service set. This profile is used to negotiate IKE and IPsec security associations with dynamic peers only.

All interfaces referenced by the inside-service-interface statement within a service set must belong to the same VRF instance.

You can configure an interface identifier for a group of dynamic peers, which specifies which adaptive services logical interface(s) take part in the dynamic IPsec negotiation. By assigning the same interface identifier to multiple logical interfaces, you can create a pool of interfaces for this purpose. To configure an interface identifier, include the ipsec-interface-id statement and the dedicated or shared statement at the [edit interfaces interface-name unit logical-unit-number dial-options] hierarchy level:

Specifying the interface identifier in the dial-options statement makes this logical interface part of the pool identified by the ipsec-interface-id statement.

If you configure shared mode, it enables one logical interface to be shared across multiple tunnels. The dedicated statement specifies that the logical interface is used in a dedicated mode, which is necessary when you are configuring an IPsec link-type tunnel. You must include the dedicated statement when you specify an ipsec-interface-id value.

The software includes implicit default IKE and IPsec proposals to match the proposals sent by the dynamic peers. The values are shown in Table 1; if more than one value is shown, the first value is the default.

Starting in Junos OS Release 16.2R1, you can distribute IPsec tunnels with dynamic endpoints among multiple MS-MICs or among multiple service PICs of an MS-MPC. You configure tunnel distribution by configuring a next-hop IPsec service set for each service PIC’s multiservices (ms-) interface. Starting in Junos OS Release 17.1R1, you can also distribute IPsec tunnels with dynamic endpoints among aggregated multiservices (AMS) interfaces of MS-MICs or MS-MPCs by configuring a next-hop IPsec service set for each AMS interface.

You can later add service PIC hardware to the MX Series router and include the service PIC in the tunnel distribution by simply adding another service set, without needing to change the configuration of the IPsec peers.

To configure tunnel distribution, perform the following steps when configuring dynamic endpoint IPsec tunnels:

• Configure a next-hop IPsec service set for each services interface or AMS interface used by the dynamic endpoint IPsec tunnel (see Referencing the IKE Access Profile in a Service Set). All of the service sets must:

  • Use the same type of services interface—either multiservices (ms-) interfaces or AMS (ams-) interfaces.

  • Have an interface in the outside-service statement that is in the same VPN routing and forwarding (VRF) instance as the interfaces in the other service sets.

  • Have the same local-gateway IP address.

  • Have the same ike-access-profile name.

• When configuring the interface identifier (see Configuring the Interface Identifier), the ipsec-interface-id identifier must be configured:

  • Only under interfaces that appear in the inside-service-set statements of the service sets.

  • With dedicated for all the interfaces, or with shared for all the interfaces.

  • Under no more than one shared unit of an interface.

  • Only under interfaces configured with service-domain inside.

  • Only under interfaces that are in the same VRF.