Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec Tunnels With Dynamic Endpoints

Configuring Dynamic Endpoints for IPsec Tunnels

IPsec tunnels can also be established using dynamic peer security gateways, in which the remote ends of tunnels do not have a statically assigned IP address. Since the remote address is not known and might be pulled from an address pool each time the remote host reboots, establishment of the tunnel relies on using IKE main mode with either preshared global keys or digital certificates that accept any remote identification value. Both policy-based and link-type tunnels are supported:

  • Policy-based tunnels used shared mode.

  • Link-type or routed tunnels use dedicated mode. Each tunnel allocates a services interface from a pool of interfaces configured for the dynamic peers. Routing protocols can be configured to run on these services interfaces to learn routes over the IPsec tunnel that is used as a link in this scenario.

This section includes the following topics:

Authentication Process

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.

Implicit Dynamic Rules

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.

Note:

You do not configure this rule; it is created by the key management process (kmd).

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.

Reverse Route Insertion

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.

Note:

Reverse route insertion takes place only for tunnels to dynamic peers. These routes are added only for next-hop-style service sets.

Configuring an IKE Access Profile

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.

Note:

For dynamic peers, the Junos OS supports the IKE main mode with either the preshared key method of authentication or an IKE access profile that uses a local digital certificate.

  • In preshared key mode, the IP address is used to identify a tunnel peer to get the preshared key 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.

  • In digital certificate mode, the IKE policy defines which remote identification values are allowed.

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.

Referencing the IKE Access Profile in a Service Set

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.

Configuring the Interface Identifier

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.

Note:

Only one interface identifier can be specified at a time. You can include the ipsec-interface-id statement or the l2tp-interface-id statement, but not both.

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.

Default IKE and IPsec Proposals

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.

Note:

RSA certificates are not supported with dynamic endpoint configuration.

Table 1: Default IKE and IPsec Proposals for Dynamic Negotiations

Statement Name

Values

Implicit IKE Proposal

authentication-method

pre-shared keys

dh-group

group1, group2, group5, group14

authentication-algorithm

sha1, md5, sha-256

encryption-algorithm

3des-cbc, des-cbc, aes-128, aes-192, aes-256

lifetime-seconds

3600 seconds

Implicit IPsec Proposal

protocol

esp, ah, bundle

authentication-algorithm

hmac-sha1-96, hmac-md5-96

encryption-algorithm

3des-cbc, des-cbc, aes-128, aes-192, aes-256

lifetime-seconds

28,800 seconds (8 hours)

Distributing Endpoint IPsec Tunnels Among Services Interfaces

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.

Example: Configuring Dynamically Assigned Policy Based Tunnels

This example shows how to configure dynamically assigned policy-based tunnels and contains the following sections.

Requirements

This example uses the following hardware and software components:

  • Three M Series, MX Series or T Series routers.

  • Junos OS Release 9.4 or later.

Overview and Topology

An IPsec policy for dynamic endpoints defines a combination of security parameters (IPsec proposals) used during IPsec negotiation between dynamic peer security gateways, in which the remote ends of tunnels do not have a statically assigned IP address.

A policy based VPN is a configuration with a specific VPN tunnel referenced in a policy which acts as a Tunnel. You use a Policy-based VPN if the remote VPN device is a non-Juniper device and if you must access only one subnet or one network at the remote site, across the VPN.

This example explains the IPsec dynamic endpoint tunneling topology as shown in Figure 1.

Before you configure dynamically assigned tunnels, be sure you have:

  • A local network N-1 connected to a security gateway SG-1. The exit points must have a Juniper Networks router to terminate the static and dynamic peer endpoints. The tunnel termination address on SG-1 is 10.1.1.1 and the local network address is 172.16.1.0/24.

  • Two remote peer routers that obtain addresses from an ISP pool and run an RFC-compliant IKE. The remote network N-2 has the address 172.16.2.0/24 and is connected to the security gateway SG-2 with the tunnel termination address 10.2.2.2. The remote network N-3 has the address 172.16.3.0/24 and is connected to the security gateway SG-3 with the tunnel termination address 10.3.3.3.

Topology

Figure 1: IPsec Dynamic Endpoint Tunneling TopologyIPsec Dynamic Endpoint Tunneling Topology

Configuration

To configure dynamically assigned policy based tunnels, perform these tasks:

Note:

The interface types shown in this example are for indicative purpose only. For example, you can use so- interfaces instead of ge- and sp- instead of ms-.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI, at the [edit] hierarchy level, of SG1 router.

Configuring Interfaces

Configuring Access Profile

Configuring Service Set

Configuring IPsec Properties

Configuring Routing Instances

Configuring a Next-Hop SG1 Service-Set

Step-by-Step Procedure
Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy.

  1. Configure the interfaces.

  2. Configure the access profile.

  3. Configure the services set.

  4. Configure the IPsec properties.

  5. Configure the routing instances.

Results

From configuration mode of Router 1, confirm your configuration by entering the show interfaces, show access, and show services commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Verifying That the Next-Hop SG1 Service Set with Policy-Based Tunnels Is Created

Purpose

Verify that the next-hop SG1 service set with policy-based tunnels is created.

Action

From operational mode, enter the show route command.

From operational mode, enter the show services ipsec-vpn ipsec security-associations detail

Meaning

The show services ipsec-vpn ipsec security-associations detail command output shows the properties that you configured.

Release History Table
Release
Description
17.1
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.
16.2
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.