Configuring an IKE Access Profile for IPsec Dynamic Endpoint Tunnels
Configuring an IKE Access Profile for IPsec Dynamic Endpoint Tunnels
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.
The IKE tunnel profile specifies all the information needed to complete the IKE negotiation. For more information on access profiles, see the Junos System Basics Configuration Guide.
[edit access] profile profile-name { client * { ike { allowed-proxy-pair { remote remote-proxy-address local local-proxy-address; } pre-shared-key ([ ascii-text key-string ] | [hexadecimal key-string ]); interface-id string-value; ipsec-policy ipsec-policy; } } }
For dynamic peers, the Junos OS supports only IKE main mode with the preshared key method of authentication. In this mode, an IPv4 or IPv6 address is used to identify a tunnel peer to get the preshared key information. The client value * (wildcard) means that the configuration within this profile is valid for all dynamic peers terminating within the service set accessing this profile.
The following statements are the parts of 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.
pre-shared-key—Mandatory key used to authenticate the dynamic peer during IKE phase 1 negotiation. This key must be configured on both ends of the tunnel and distributed through an out-of-band secure mechanism. You can configure the key value either in hexadecimal or ascii-text format.
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.
Configuring the Service Set for IPsec Dynamic Endpoint Tunnels
To complete a dynamic endpoint tunnel configuration,
you need to reference the IKE access profile configured at the [edit access] hierarchy level in the service set. To do this,
include the ike-access-profile
statement at the [edit
services service-set name ipsec-vpn-options] hierarchy level:
[edit services] service-set name { next-hop-service { inside-service-interface interface-name; outside-service-interface interface-name; } ipsec-vpn-options { local-gateway address; ike-access-profile profile-name; } }
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.
If you configure an IKE access profile in a service set, no other service set can share the same local-gateway address.
Configuring the Interface Identifier for IPsec Dynamic Endpoint Tunnels
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, include
the ipsec-interface-id
statement at the [edit interfaces interface-name] hierarchy level:
[edit interfaces sp-fpc/pic/port] unit logical-unit-number { dial-options { ipsec-interface-id identifier; (shared | dedicated); } }
Specifying the interface identifier in the dial-options
statement makes this logical interface part of
the pool identified by the IPsec interface identifier.
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 simultaneously.
The shared
statement enables one logical
interface to be shared across multiple tunnels. The dedicated
statement specifies that the logical interface is associated with
a single tunnel, 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.
Configuring Multiple Routed Tunnels in a Single Next-Hop Service Set
You can optionally configure several routed IPSec tunnels within a single
next-hop service set. To do so, start by establishing multiple services interfaces as inside
interfaces by including the service-domain inside statement at the [edit
interfaces sp-fpc/pic/port unit logical-unit-number] hierarchy
level. Then, include the ipsec-inside-interface
statement at the [edit services
ipsec-vpn rule rule-name term term-name from]
hierarchy level.
The full IPsec and IKE proposals and policies are not shown in the following example for the sake of brevity.
[edit] interfaces { sp-3/3/0 { unit 3 { family inet; service-domain inside; } unit 4 { family inet; service-domain outside; } unit 5 { family inet; service-domain inside; } } } services { service-set link_type_ss_1 { next-hop-service { inside-service-interface sp-3/3/0.3; outside-service-interface sp-3/3/0.4; } ipsec-vpn-options { local-gateway 10.8.7.2; } ipsec-vpn-rules link_rule_1; } ipsec-vpn { rule link_rule_1 { term 1 { from { ipsec-inside-interface sp-3/3/0.3; } then { remote-gateway 10.10.7.3; backup-remote-gateway 10.8.7.1; dynamic { ike-policy main_mode_ike_policy; ipsec-policy dynamic_ipsec_policy; } } } term 2 { from { ipsec-inside-interface sp-3/3/0.5; } then { remote-gateway 10.12.7.5; dynamic { ike-policy main_mode_ike_policy; ipsec-policy dynamic_ipsec_policy; } } } match-direction input; } } }
To confirm that your configuration is working, issue the show services
ipsec-vpn ipsec security-associations
command. Notice that each IPsec inside interface
that you assigned to each IPsec tunnel is included in the output of this command.
user@router> show services ipsec-vpn ipsec security-associations Service set: link_type_ss_1 Rule: link_rule_1, Term: 1, Tunnel index: 1 Local gateway: 10.8.7.2, Remote gateway: 10.8.7.1 IPSec inside interface: sp-3/3/0.3 Direction SPI AUX-SPI Mode Type Protocol inbound 3216392497 0 tunnel dynamic ESP outbound 398917249 0 tunnel dynamic ESP Rule: link_rule_1, Term: 2, Tunnel index: 2 Local gateway: 10.8.7.2, Remote gateway: 10.12.7.5 IPSec inside interface: sp-3/3/0.5 Direction SPI AUX-SPI Mode Type Protocol inbound 762146783 0 tunnel dynamic ESP outbound 319191515 0 tunnel dynamic ESP