Service Sets for Static Endpoint IPsec Tunnels

Service Sets

• Next-hop service set—Supports multicast and multicast-style dynamic routing protocols (such as OSPF) over IPSec. Next-hop service sets allow you to use inside and outside logical interfaces on the Adaptive Services PIC to connect with multiple routing instances. They also allow the use of Network Address Translation (NAT) and stateful firewall capabilities. However, next-hop service sets do not monitor Routing Engine traffic by default and require configuration of multiple service sets to support traffic from multiple interfaces.

• Interface service set—Applied to a physical interface and similar to a stateless firewall filter. They are easy to configure, can support traffic from multiple interfaces, and can monitor Routing Engine traffic by default. However, they cannot support dynamic routing protocols or multicast traffic over the IPSec tunnel.

In general, we recommend that you use next-hop service sets because they support routing protocols and multicast over the IPSec tunnel, they are easier to understand, and the routing table makes forwarding decisions without administrative intervention.

Configuring IPsec Service Sets

IPsec service sets require additional specifications that you configure at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level:

Configuration of these statements is described in the following sections:

• Configuring the Local Gateway Address for IPsec Service Sets

• Configuring IKE Access Profiles for IPsec Service Sets

• Configuring Certification Authorities for IPsec Service Sets

• Configuring or Disabling Antireplay Service

• Clearing the Do Not Fragment Bit

• Configuring Passive-Mode Tunneling

• Configuring the Tunnel MTU Value

• Configuring IPsec Multipath Forwarding with UDP Encapsulation

Configuring the Local Gateway Address for IPsec Service Sets

If you configure an IPsec service set, you must also configure a local IPv4 or IPv6 address by including the local-gateway statement:

• If the Internet Key Exchange (IKE) gateway IP address is in inet.0 (the default situation), you configure the following statement:

• If the IKE gateway IP address is in a VPN routing and forwarding (VRF) instance, you configure the following statement:

You can configure all the link-type tunnels that share the same local gateway address in a single next-hop-style service set. You must specify a value for the inside-service-interface statement at the [edit services service-set service-set-name] hierarchy level that matches the ipsec-inside-interface value, which you configure at the [edit services ipsec-vpn rule rule-name term term-name from] hierarchy level. For more information about IPsec configuration, see Configuring IPsec Rules.

Starting in Junos OS Release 17.1, AMS supports IPSec tunnel distribution.

IKE Addresses in VRF Instances

You can configure Internet Key Exchange (IKE) gateway IP addresses that are present in a VPN routing and forwarding (VRF) instance as long as the peer is reachable through the VRF instance.

For next-hop service sets, the key management process (kmd) places the IKE packets in the routing instance that contains the outside-service-interface value you specify, as in this example:

For interface service sets, the service-interface statement determines the VRF, as in this example:

Clearing SAs When Local Gateway Address or MS-MPC or MS-MIC Goes Down

Starting in Junos OS Release 17.2R1, tou can use the gw-interface statement to enable the cleanup of IKE triggers and IKE and IPsec SAs when an IPsec tunnel’s local gateway IP address goes down, or the MS-MIC or MS-MPC being used in the tunnel’s service set goes down.

The interface-name and logical-unit-number must match the interface and logical unit on which the local gateway IP address is configured.

If the local gateway IP address for an IPsec tunnel’s service set goes down or the MS-MIC or MS-MPC that is being used in the service set goes down, the service set no longer sends IKE triggers. In addition, when the local gateway IP address goes down, the IKE and IPsec SAs are cleared for next-hop service sets, and go to the Not Installed state for interface-style service sets. The SAs that have the Not Installed state are deleted when the local gateway IP address comes back up.

If the local gateway IP address that goes down for a next-hop service set is for the responder peer, then you need to clear the IKE and IPsec SAs on the initiator peer so that the IPsec tunnel comes back up once the local gateway IP address comes back up. You can either manually clear the IKE and IPsec SAs on the initiator peer (see clear services ipsec-vpn ike security-associations and clear services ipsec-vpn ipsec security-associations) or enable dead peer detection on the initiator peer (see Configuring Stateful Firewall Rules).

Configuring IKE Access Profiles for IPsec Service Sets

For dynamic endpoint tunneling only, 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 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.

Configuring Certification Authorities for IPsec Service Sets

You can specify one or more trusted certification authorities by including the trusted-ca statement:

When you configure public key infrastructure (PKI) digital certificates in the IPsec configuration, each service set can have its own set of trusted certification authorities. The names you specify for the trusted-ca statement must match profiles configured at the [edit security pki] hierarchy level; for more information, see the Junos OS Administration Library. For more information about IPsec digital certificate configuration, see Configuring IPsec Rules.

Starting in Junos OS Release 18.2R1, you can configure the MX Series router with MS-MPCs or MS-MICs to send only the end-entity certificate for certificate-based IKE authentication instead of the full certificate chain. This avoids IKE fragmentation. To configure this feature, include the no-certificate-chain-in-ike statement:

Configuring or Disabling Antireplay Service

You can include the anti-replay-window-size statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to specify the size of the antireplay window.

This statement is useful for dynamic endpoint tunnels for which you cannot configure the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

For static IPsec tunnels, this statement sets the antireplay window size for all the static tunnels within this service set. If a particular tunnel needs a specific value for antireplay window size, set the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. If antireplay check has to be disabled for a particular tunnel in this service set, set the no-anti-replay statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

You can also include the no-anti-replay statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to disable IPsec antireplay service. It occasionally causes interoperability issues for security associations.

This statement is useful for dynamic endpoint tunnels for which you cannot configure the no-anti-reply statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

For static IPsec tunnels, this statement disables the antireplay check for all the tunnels within this service set. If antireplay check has to be enabled for a particular tunnel, then set the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

Clearing the Do Not Fragment Bit

You can include the clear-dont-fragment-bit statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to clear the do not fragment (DF) bit on all IP version 4 (IPv4) packets entering the IPsec tunnel. If the encapsulated packet size exceeds the tunnel maximum transmission unit (MTU), the packet is fragmented before encapsulation.

This statement is useful for dynamic endpoint tunnels for which you cannot configure the clear-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

For static IPsec tunnels, setting this statement clears the DF bit on packets entering all the static tunnels within this service set. If you want to clear the DF bit on packets entering a specific tunnel, set the clear-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

Starting in Junos OS Release 14.1, in packets that are transmitted through dynamic endpoint IPSec tunnels, you can enable the value set in the DF bit of the packet entering the tunnel to be copied only to the outer header of the IPsec packet and to not cause any modification to the DF bit in the inner header of the IPsec packet. If the packet size exceeds the tunnel maximum transmission unit (MTU) value, the packet is fragmented before encapsulation. For IPsec tunnels, the default MTU value is 1500 regardless of the interface MTU setting. To copy the DF bit value to only the outer header and not modify the inner header, use the copy-dont-fragment-bit statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level. You can also configure the DF bit to be set only in the outer IPv4 header of the IPsec packet and not be defined in the inner IPv4 header. To configure the DF bit in only the outer header of the IPsec packet and to leave the inner header unmodified, include the set-dont-fragment-bit statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level. These settings apply for dynamic endpoint tunnels and not for static tunnels, for which you need to include the copy-dont-fragment-bit and set-dont-fragment-bit statements at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level to clear the DF bit in the IPv4 packets that enter the static tunnel. These functionalities are supported on MX Series routers with MS-MICs and MS-MPCs.

Configuring Passive-Mode Tunneling

You can include the passive-mode-tunneling statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to enable the service set to tunnel malformed packets.

This functionality bypasses the active IP checks, such as version, TTL, protocol, options, address and other land attack checks, and tunnels the packets as is. If this statement is not configured, packets failing the IP checks are dropped in the PIC. In passive mode, the inner packet is not touched; an ICMP error is not generated if the packet size exceeds the tunnel MTU value.

The IPsec tunnel is not treated as a next hop and TTL is not decremented. Because an ICMP error is not generated if the packet size exceeds the tunnel MTU value, the packet is tunnelled even if it crosses the tunnel MTU threshold.

Configuring the Tunnel MTU Value

You can include the tunnel-mtu statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to set the maximum transmission unit (MTU) value for IPsec tunnels.

This statement is useful for dynamic endpoint tunnels for which you cannot configure the tunnel-mtu statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

For static IPsec tunnels, this statement sets the tunnel MTU value for all the tunnels within this service set. If you need a specific value for a particular tunnel, then set the tunnel-mtu statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.

Configuring IPsec Multipath Forwarding with UDP Encapsulation

1. Enable UDP encapsulation.
2. (Optional) Specify the UDP destination port number.

   Use a destination port number from 1025 through 65536, but do not use 4500. If you do not specify a port number, the default destination port is 4565.

Requesting for and Installing a Digital Certificates on Your Router

• Requesting a Digital Certificate—Manual Process

Requesting a Digital Certificate—Manual Process

To obtain digital certificates manually, you must configure a CA profile, generate a private-public key pair, create a local certificate, and load the certificates on the router. After loading the certificates, they can be referenced in your IPsec-VPN configuration.

1. Configure a CA profile:

   After you commit this configuration. The configuration on Router 2 must contain the following:
2. Certificate revocation list (CRL) verification is enabled by default. You can optionally specify the Lightweight Access Directory (LDAP) server where the CA stores the CRL. The certificate typically includes a certificate distribution point (CDP), which contains information about how to retrieve the CRL for the certificate. The router uses this information to download the CRL automatically. In this example, the LDAP URL is specified, which overrides the location provided in the certificate:

   After you commit this configuration. The configuration on Router 2 must contain the following:
3. After you configure the CA profile, request a CA certificate from the trusted CA. In this example, the certificate is enrolled online and installed into the router automatically.
   user@R2> request security pki ca-certificate enroll ca-profile entrust
   Note

   If you obtain the CA certificate directly from the CA (for example, as an e-mail attachment or website download), you can install it with the request security pki ca-certificate load command.

4. Next, you must generate a private-public key pair before you can create a local certificate.
   user@R2> request security pki generate-key-pair certificate-id local-entrust2

   When the key pair is available, generate a local certificate request and send it to the CA for processing.

   user@R2> request security pki generate-certificate-request
   Note

   You can request the creation and installation of a local certificate online with the request security pki local-certificate enroll command.

5. The trusted CA digitally signs the local certificate and returns it to you. Copy the certificate file into the router and load the certificate.
   user@R2> request security pki local-certificate load filename /tmp/router2-cert certificate-id local-entrust2
   Note

   The name of the file sent to you by the CA might not match the name of the certificate identifier. However, the certificate-id name must always match the name of the key pair you generated for the router.

Example: IKE Dynamic SA Configuration with Digital Certificates

• Requirements

• Overview

• Configuration

• Verification

Requirements

• Four M Series, MX Series, or T Series routers with multiservices interfaces installed in them.

• Junos OS Release 9.4 or later.

Before you configure this example you must request a CA certificate, create a local certificate, and load these digital certificates into the router. For details, see Requesting for and Installing a Digital Certificates on Your Router

Overview

A security association (SA) is a simplex connection that enables two hosts to securely communicate with each other using IPsec. This example explains IKE dynamic SA configuration with digital certificates. The use of digital certificates provides additional security to your IKE tunnel. Using default values in the Services PIC, you do not need to configure an IPsec proposal or IPsec policy. However, you must configure an IKE proposal that specifies the use of digital certificates, reference the IKE proposal and local certificate in an IKE policy, and apply the CA profile to the service set.

Figure 1 shows an IPsec topology containing a group of four routers. This configuration requires Routers 2 and 3 to establish an IKE-based IPsec tunnel by using digital certificates in place of preshared keys. Routers 1 and 4 provide basic connectivity and are used to verify that the IPsec tunnel is operational.

Topology

Figure 1: MS PIC IKE Dynamic SA Topology Diagram

Configuration

• Configuring Router 1

• Configuring Router 2

• Configuring Router 3

• Configuring Router 4

Configuring Router 1

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 Router 1.

Step-by-Step Procedure

1. Configure an Ethernet interface and the loopback interface.
2. Specify the OSPF area and associate the interfaces with the OSPF area.
3. Configure the router ID.
4. Commit the configuration.

Results

From the configuration mode, confirm your configuration by entering the show interfaces, show protocols ospf, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Router 2

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 Router 2.

Step-by-Step Procedure

1. Configure interface properties. In this step, you configure two Ethernet interfaces (ge-1/0/0 and ge-1/0/1), the loopback interface and a multiservices interface (ms-1/2/0).
2. Specify the OSPF area and associate the interfaces with the OSPF area.
3. Configure the router ID.
4. Configure an IKE proposal and policy. To enable an IKE proposal for digital certificates, include the rsa-signatures statement at the [edit services ipsec-vpn ike proposal proposal-name authentication-method] hierarchy level. To reference the local certificate in the IKE policy, include the local-certificate statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. To identify the CA or RA in the service set, include the trusted-ca statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level.Note

   For information about creating and installing digital certificates, see Requesting for and Installing a Digital Certificates on Your Router
5. Configure an IPsec proposal and policy. Also, set the established-tunnels knob to immediately.
6. Configure an IPsec rule.
7. Configure a next-hop style service set, specify the local-gateway address, and associate the IPsec VPN rule with the service set.
8. Commit the configuration.

Results

From the configuration mode, confirm your configuration by entering the show interfaces, show protocols ospf, show routing-options, and show services commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration

Configuring Router 3

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 Router 3.

Step-by-Step Procedure

1. Configure interface properties. In this step, you configure two Ethernet interfaces (ge-1/0/0 and ge-1/0/1), the loopback interface, and a multiservices interface (ms-1/2/0).
2. Specify the OSPF area, associate the interfaces with the OSPF area.
3. Configure a router ID.
4. Configure an IKE proposal and policy. To enable an IKE proposal for digital certificates, include the rsa-signatures statement at the [edit services ipsec-vpn ike proposal proposal-name authentication-method] hierarchy level. To reference the local certificate in the IKE policy, include the local-certificate statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. To identify the CA or RA in the service set, include the trusted-ca statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level.Note

   For information about creating and installing digital certificates, see Requesting for and Installing a Digital Certificates on Your Router
5. Configure an IPsec proposal. Also, set the established-tunnels knob to immediately.
6. Configure an IPsec rule.
7. Configure a next-hop style service set, specify the local-gateway address, and associate the IPsec VPN rule with the service set.
8. Commit the configuration.

Results

From the configuration mode, confirm your configuration by entering the show interfaces, show protocols ospf, show routing-options, and show services commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration

Configuring Router 4

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 Router 4.

Step-by-Step Procedure

1. Configure the interfaces. In this step, you configure an Ethernet interface (ge-1/0/1) and the loopback interface.
2. Specify the OSPF area and associate the interfaces with the OSPF area.
3. Configure the router ID.

Results

From the configuration mode, confirm your configuration by entering the show interfaces, show protocols ospf, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration

Verification

Verifying Your Work on Router 1

Purpose

On Router 1, verify ping command to the so-0/0/0 interface on Router 4 to send traffic across the IPsec tunnel.

Action

From operational mode, enter ping 10.1.56.2.

If you ping the loopback address of Router 4, the operation succeeds because the address is part of the OSPF network configured on Router 4.

Verifying Your Work on Router 2

Purpose

To verify that matched traffic is being diverted to the bidirectional IPsec tunnel, view the IPsec statistics:

Action

From operational mode, enter the show services ipsec-vpn ipsec statistics.

To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command:

To verify that the IPsec security association is active, issue the show services ipsec-vpn ipsec security-associations detail command. Notice that the SA contains the default settings inherent in the Services PIC, such as ESP for the protocol and HMAC-SHA1-96 for the authentication algorithm.

To display the digital certificates that are used to establish the IPsec tunnel, issue the show services ipsec-vpn certificates command:

To display the CA certificate, issue the show security pki ca-certificate detail command. Notice that there are three separate certificates: one for certificate signing, one for key encipherment, and one for the CA’s digital signature.

To display the local certificate request, issue the show security pki certificate-request command:

To display the local certificate, issue the show security pki local-certificate command:

Verifying Your Work on Router 3

Purpose

To verify that matched traffic is being diverted to the bidirectional IPsec tunnel, view the IPsec statistics:

Action

From operational mode, enter the show services ipsec-vpn ipsec statistics.

To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.

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

To verify that the IPsec SA is active, issue the show services ipsec-vpn ipsec security-associations detail command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.

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

To display the digital certificates that are used to establish the IPsec tunnel, issue the show services ipsec-vpn certificates command:

From operational mode, enter the show services ipsec-vpn certificates.

To display the CA certificate, issue the show security pki ca-certificate detail command. Notice that there are three separate certificates: one for certificate signing, one for key encipherment, and one for the CA’s digital signature.

From operational mode, enter the show security pki ca-certificate detail.

To display the local certificate request, issue the show security pki certificate-request command:

From operational mode, enter the show security pki certificate-request.

To display the local certificate, issue the show security pki local-certificate command:

From operational mode, enter the show security pki local-certificate.

Verifying Your Work on Router 4

Purpose

On Router 4, issue a ping command to the so-0/0/0 interface on Router 1 to send traffic across the IPsec tunnel.

Action

From operational mode, enter ping 10.1.12.2.

The final way you can confirm that traffic travels over the IPsec tunnel is by issuing the traceroute command to the so-0/0/0 interface on Router 1. Notice that the physical interface between Routers 2 and 3 is not referenced in the path; traffic enters the IPsec tunnel through the adaptive services IPsec inside interface on Router 3, passes through the loopback interface on Router 2, and ends at the so-0/0/0 interface on Router 1.

From operational mode, enter the traceroute 10.1.12.2.

Configuring Junos VPN Site Secure or IPSec VPN

IPsec VPN is supported on all MX Series routers with MS-MICs, MS-MPCs, or MS-DPCs.

On M Series and T Series routers, IPsec VPN is supported with Multiservices 100 PICs, Multiservices 400 PICs, and Multiservices 500 PICs.

MS-MICs and MS-MPCs are supported from Junos OS Release 13.2 and later. MS-MICs and MS-MPCs support all features that are supported by MS-DPCs and MS-PICs except for authentication header protocol (ah), encapsulating security payload protocol (esp), and bundle (ah and esp protocol) protocol for a dynamic or manual security association and flowless IPsec service.

NAT traversal (NAT-T) is supported for IKEv1 and IKEv2 from Junos OS Release 17.4R1 onwards. NAT-T is enabled by default. You can specify the UDP encapsulation and decapsulation for IKE and ESP packets using the configuration disable-natt at the [edit services ipsec-vpn] hierarchy levels.

Example: Configuring Junos VPN Site Secure on MS-MIC and MS-MPC

• Requirements

• Overview

• Configuration

• Verification

Requirements

• Two MX Series routers with MS-MICs

• Junos OS Release 13.2 or later

Overview

Junos OS Release 13.2, extends support for Junos VPN Site Secure (formerly known as IPsec features) to the newly-introduced Multiservices MIC and MPC (MS-MIC and MS-MPC) on MX Series routers. The Junos OS extension-provider packages come preinstalled and preconfigured on the MS-MIC and MS-MPC.

• Dynamic End Points (DEP)

• Encapsulating Security Payload (ESP) protocol

• Dead Peer Detection (DPD) trigger messages

• Sequence Number Rollover notifications

• Static IPsec tunnels with next-hop-style and interface-style service sets

However, in Junos OS Release 13.2, the Junos VPN Site Secure support on the MS-MIC and MS-MPC is limited to IPv4 traffic. Passive module tunneling is not supported on MS-MICs and MS-MPCs.

Figure 2 shows the IPsec VPN tunnel topology.

Figure 2: IPsec VPN Tunnel Topology

This example shows configuration of two routers, Router 1 and Router 2, that have an IPsec VPN tunnel configured between them.

• The IP address you configure for source-address under the [edit services ipsec-vpn rule name term term from] hierarchy level on Router 1 must be the same as the IP address you configure for destination-address under the same hierarchy on Router 2, and vice versa.

• The IP address of the remote-gateway you configure under the [edit services ipsec-vpn rule name term term then] hierarchy level should match the IP address of the local-gateway you configure under the [edit services service-set name ipsec-vpn-options] hierarchy level of Router 2, and vice versa.

Configuration

• Configuring Router 1

• Configuring Router 2

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.

Configuring Router 1

Step-by-Step Procedure

1. Configure the interface properties such as family, service-domain, and unit.
2. Configure IPsec properties such as address, remote-gateway, policies, match-direction, protocol, replay window size, algorithm details, secrecy keys, proposal, authentication method, groups, and version.
3. Configure a service set, the ipsec-vpn options, and rules.
4. Configure routing options static route and next hop.

Results

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

Configuring Router 2

Step-by-Step Procedure

1. Configure the interface properties such as family, service-domain, and unit.
2. Configure IPsec properties such as address, remote-gateway, policies, match-direction, protocol, replay window size, algorithm details, secrecy keys, proposal, authentication method, groups, and version.
3. Configure a service set such as next-hop-service, and the ipsec-vpn-options.
4. Configure routing options static route and the next hop.

Results

From the configuration mode of Router 2, confirm your configuration by entering the show interfaces, show services ipsec-vpn, and show services service-set commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

• Verifying Tunnel Creation

• Verifying Traffic Flow Through the DEP Tunnel

• Verifying IPsec Security Associations for the Service Set

Verifying Tunnel Creation

Purpose

Verify that Dynamic End Points are created.

Action

Meaning

The output shows that the IPSec SAs are up on the router with their state as Installed. The IPSec tunnel is up and ready to send traffic over the tunnel.

Verifying Traffic Flow Through the DEP Tunnel

Purpose

Verify traffic flow across the newly-created DEP tunnel.

Action

Run the following command on Router 2:

Verifying IPsec Security Associations for the Service Set

Purpose

Verify that the security associations configured for the service set are functioning correctly.

Action

Run the following command on Router 2:

Example: Configuring Statically Assigned IPsec Tunnels over a VRF Instance

• Requirements

• Overview

• Configuration

Requirements

• M Series, MX Series, or T Series router that is configured as a provider edge router.

• Junos OS Release 9.4 and later.

No special configuration beyond device initialization is required before you can configure this feature.

Overview

Junos OS enables you to configure statically assigned IPsec tunnels on Virtual Routing and Forwarding (VRF) instances. Ability to configure IPsec tunnels on VRF instances enhances network segmentation and security. You can have multiple customer tunnels configured on the same PE router over VRF instances. Each VRF instance acts as logical router with an exclusive routing table.

Configuration

• Configuring the Provider Edge Router

• Results

Configuring the Provider Edge Router

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.

Step-by-Step Procedure

1. Configure the interfaces. In this step, you configure two Ethernet (ge) interfaces, one services interface (ms-), and also the service-domain properties for the logical interfaces of the services interface. Note that the logical interface that is marked as the inside interface applies the configured service on the traffic, whereas the one that is marked as the outside interface acts as the egress point for the traffic on which the inside interface has applied the service.
2. Configure a routing policy to specify route import and export criteria for the VRF instance. The import and export policies defined in this step are referenced from the routing-instance configuration in the next step.
3. Configure a routing instance and specify the routing-instance type as vrf. Apply the import and export policies defined in the previous step to the routing instance, and specify a static route to send the IPsec traffic to the inside interface (ms-1/2/0.1) configured in the first step.
4. Configure IKE and IPsec proposals and policies, and a rule to apply the IKE policy on the incoming traffic.. Note

   By default, Junos OS uses IKE policy version 1.0. Junos OS Release 11.4 and later also support IKE policy version 2.0 which you must configure at [edit services ipsec-vpn ike policy policy-name pre-shared].
5. Configure a next-hop style service set. Note that you must configure the inside and outside interfaces that you configured in the first step as the inside-service-interface and outside-service-interface respectively.
6. Commit the configuration.

Results

From the configuration mode of Router 1, confirm your configuration by entering the show interfaces, show policy-options, show routing-instances, show services ipsec-vpn, and show services service-set commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Multitask Example: Configuring IPsec Services

This topic includes the following tasks:

1. Configuring the IKE Proposal

2. Configuring the IKE Policy (and Referencing the IKE Proposal)

3. Configuring the IPsec Proposal

4. Configuring the IPsec Policy (and Referencing the IPsec Proposal)

5. Configuring the IPsec Rule (and Referencing the IKE and IPsec Policies)

6. Configuring IPsec Trace Options

7. Configuring the Access Profile (and Referencing the IKE and IPsec Policies)

8. Configuring the Service Set (and Referencing the IKE Profile and the IPsec Rule)

Configuring the IKE Proposal

1. In configuration mode, go to the following hierarchy level:
2. Configure the authentication method, which is pre-shared keys in this example:
3. Configure the Diffie-Hellman Group and specify a name—for example, group1:
4. Configure the authentication algorithm, which is sha1 in this example:
5. Configure the encryption algorithm, which is aes-256-cbc in this example:

Configuring the IKE Policy (and Referencing the IKE Proposal)

1. In configuration mode, go to the following hierarchy level:
2. Configure the IKE first phase mode—for example, main:
3. Configure the proposal, which is test-IKE-proposal in this example:
4. Configure the local identification with an IPv4 address—for example, 192.168.255.2:
5. Configure the preshared key in ASCII text format, which is TEST in this example:

Configuring the IPsec Proposal

1. In configuration mode, go to the following hierarchy level:
2. Configure the IPsec protocol for the proposal—for example, esp:
3. Configure the authentication algorithm for the proposal, which is hmac-sha1-96 in this example:
4. Configure the encryption algorithm for the proposal, which is aes-256-cbc in this example:

Configuring the IPsec Policy (and Referencing the IPsec Proposal)

1. In configuration mode, go to the following hierarchy level:
2. Configure the keys for perfect forward secrecy in the IPsec policy—for example, group1:
3. Configure a set of IPsec proposals in the IPsec policy—for example, test-IPsec-proposal:

Configuring the IPsec Rule (and Referencing the IKE and IPsec Policies)

1. In configuration mode, go to the following hierarchy level:
2. Configure the IP destination address for the IPsec term in the IPsec rule—for example, 192.168.255.2/32:
3. Configure the remote gateway address for the IPsec term in the IPsec rule—for example, 0.0.0.0:
4. Configure a dynamic security association for IKE policy for the IPsec term in the IPsec rule, which is test-IKE-policy in this example:
5. Configure a dynamic security association for IKE proposal for the IPsec term in the IPsec rule, which is test-IPsec-proposal in this example:
6. Configure a direction for which the rule match is being applied in the IPsec rule—for example, input:

Configuring IPsec Trace Options

1. In configuration mode, go to the following hierarchy level:
2. Configure the trace file, which is ipsec.log in this example:
3. Configure all the tracing parameters with the option all in this example:

Configuring the Access Profile (and Referencing the IKE and IPsec Policies)

1. In configuration mode, go to the following hierarchy level:
2. Configure the list of local and remote proxy identity pairs with the allowed-proxy-pair option. In this example, 10.0.0.0/24 is the IP address for local proxy identity and 10.0.1.0/24 is the IP address for remote proxy identity:
3. Configure the IKE policy—for example, test-IKE-policy:
4. Configure the IPsec policy—for example, test-IPsec-policy:
5. Configure the identity of logical service interface pool, which is TEST-intf in this example:

Configuring the Service Set (and Referencing the IKE Profile and the IPsec Rule)

1. In configuration mode, go to the following hierarchy level:
2. Configure a service set with parameters for next hop service interfaces for the inside network—for example, sp-1/2/0.1:
3. Configure a service set with parameters for next hop service interfaces for the outside network—for example, sp-1/2/0.2:
4. Configure the IPsec VPN options with the address and routing instance for the local gateway—for example, 192.168.255.2:
5. Configure the IPsec VPN options with the IKE access profile for dynamic peers, which is IKE-profile-TEST in this example:
6. Configure a service set with IPsec VPN rules, which is test-IPsec-rule in this example:

Disabling NAT-T on MX Series Routers for Handling NAT with IPsec-Protected Packets

Before Junos OS Release 17.4R1, Network Address Translation-Traversal (NAT-T) is not supported for the Junos VPN Site Secure suite of IPsec features on the MX Series routers. By default, Junos OS detects whether either one of the IPsec tunnels is behind a NAT device and automatically switches to using NAT-T for the protected traffic. To avoid running unsupported NAT-T in Junos OS releases before 17.4R1, you must disable NAT-T by including the disable-natt statement at the [edit services ipsec-vpn] hierarchy level. When you disable NAT-T, the NAT-T functionality is globally switched off. When you disable NAT-T and a NAT device is present between the two IPsec gateways, ISAKMP messages are negotiated using UDP port 500 and data packets are encapsulated with Encapsulating Security Payload (ESP).

Network Address Translation-Traversal (NAT-T) is a method for getting around IP address translation issues encountered when data protected by IPsec passes through a NAT device for address translation. Any changes to the IP addressing, which is the function of NAT, causes IKE to discard packets. After detecting one or more NAT devices along the data path during Phase 1 exchanges, NAT-T adds a layer of User Datagram Protocol (UDP) encapsulation to IPsec packets so they are not discarded after address translation. NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port. Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.

The location of a NAT device can be such that:

• Only the IKEv1 or IKEv2 initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices. Initiators can also connect to the responder through multiple NAT devices.

• Only the IKEv1 or IKEv2 responder is behind a NAT device.

• Both the IKEv1 or IKEv2 initiator and the responder are behind a NAT device.

Dynamic endpoint VPN covers the situation where the initiator's IKE external address is not fixed and is therefore not known by the responder. This can occur when the initiator's address is dynamically assigned by an ISP or when the initiator's connection crosses a dynamic NAT device that allocates addresses from a dynamic address pool.

Configuration examples for NAT-T are provided for the topology in which only the responder is behind a NAT device and the topology in which both the initiator and responder are behind a NAT device. Site-to-site IKE gateway configuration for NAT-T is supported on both the initiator and responder. A remote IKE ID is used to validate a peer’s local IKE ID during Phase 1 of IKE tunnel negotiation. Both the initiator and responder require a local identify and remote identity string.

Tracing Junos VPN Site Secure Operations

This section includes the following topics:

• Disabling IPsec Tunnel Endpoint in Traceroute

• Tracing IPsec PKI Operations

Disabling IPsec Tunnel Endpoint in Traceroute

If you include the no-ipsec-tunnel-in-traceroute statement at the [edit services ipsec-vpn] hierarchy level, the IPsec tunnel is not treated as a next hop and the time to live (TTL) is not decremented. Also, if the TTL reaches zero, an ICMP time exceeded message is not generated.

Tracing IPsec PKI Operations

Trace operations track IPsec PKI events and record them in a log file in the /var/log directory. By default, this file is named /var/log/pkid.

To trace IPsec PKI operations, include the traceoptions statement at the [edit security pki] hierarchy level:

• all—Trace everything.

• certificates—Trace certificates events.

• database—Trace security associations database events.

• general—Trace general events.

• ike—Trace IKE module processing.

• parse—Trace configuration processing.

• policy-manager—Trace policy manager processing.

• routing-socket—Trace routing socket messages.

• snmp—Trace SNMP operations.

• timer—Trace internal timer events.