Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Service Sets for Static Endpoint IPsec Tunnels

Service Sets

The Adaptive Services PIC supports two types of service sets when you configure IPSec tunnels. Because they are used for different purposes, it is important to know the differences between these service set types.

  • 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

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.

Note:

Starting in Junos OS Release 16.1, to configure link-type tunnels, (i.e., next-hop style), for HA purposes, you can configure AMS logical interfaces as the IPsec internal interfaces by using the ipsec-inside-interface interface-name statement at the [edit services ipsec-vpn rule rule-name term term-name from] hierarchy level.

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.

Note:

If you configure an IKE access profile in a service set, no other service set can share the same local-gateway address.

Also, you must configure a separate service set for each VRF. All interfaces referenced by the ipsec-inside-interface statement within a service set must belong to the same VRF.

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 Routing Devices. 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.

Note:

The anti-replay-window-size and no-anti-replay settings at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level override the settings specified at the [edit services service-set service-set-name ipsec-vpn-options] 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.

Note:

Setting the anti-replay-window-size and no-anti-replay statements at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level overrides the settings specified at the [edit services service-set service-set-name ipsec-vpn-options] 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.

Note:

This functionality is similar to that provided by the no-ipsec-tunnel-in-traceroute statement, described in Tracing Junos VPN Site Secure Operations. Starting in Junos OS Release 14.2, passive mode tunneling is supported on MS-MICs and MS-MPCs.

Note:

Starting in Junos OS Release 14.2, the header-integrity-check option that is supported on MS-MICs and MS-MPCs to verify the packet header for anomalies in IP, TCP, UDP, and ICMP information and flag such anomalies and errors has a functionality that is opposite to the functionality caused by passive mode tunneling. If you configure both the header-integrity-check statement and the passive-mode tunneling statement on MS-MICs and MS-MPCs, and attempt to commit such a configuration, an error is displayed during commit.

The passive mode tunneling functionality (by including the passive-mode-tunnelin statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level) is a superset of the capability to disable IPsec tunnel endpoint in the traceroute output (by including no-ipsec-tunnel-in-traceroute statement at the [edit services ipsec-vpn] hierarchy level). Passive mode tunneling also bypasses the active IP checks and tunnel MTU check in addition to not treating an IPsec tunnel as a next-hop as configured by the no-ipsec-tunnel-in-traceroute statement.

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.

Note:

The tunnel-mtu setting at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level overrides the value specified at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level.

Configuring IPsec Multipath Forwarding with UDP Encapsulation

Starting in Junos OS Release 16.1, you can enable multipath forwarding of IPsec traffic by configuring UDP encapsulation in the service set, which adds a UDP header to the IPsec encapsulation of packets. This results in the forwarding of IPsec traffic over multiple paths, increasing the throughput of IPsec traffic. If you do not enable UDP encapsulation, all the IPsec traffic follows a single forwarding path.

When NAT-T is detected, only NAT-T UDP encapsulation occurs, not the UDP encapsulation for IPsec packets.

To enable 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

A digital certificate is an electronic means for verifying your identity through a trusted third party, known as a certificate authority (CA). Alternatively, you can use a self-signed certificate to attest to your identity. The CA server you use can be owned and operated by an independent CA or by your own organization, in which case you become your own CA. If you use an independent CA, you must contact them for the addresses of their CA and certificate revocation list (CRL) servers (for obtaining certificates and CRLs) and for the information they require when submitting personal certificate requests. When you are your own CA, you determine this information yourself. The Public Key Infrastructure (PKI) provides an infrastructure for digital certificate management.

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.

This procedure shows how you can configure a CA profile:

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

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

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

This example shows how to configure IKE dynamic SA with digital certificates and contains the following sections.

Requirements

This example uses the following hardware and software components:

  • 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 DiagramMS PIC IKE Dynamic SA Topology Diagram

Configuration

To configure IKE dynamic SA with digital certificates, 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-.

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

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router 1 for OSPF connectivity with Router 2:

  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

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure OSPF connectivity and IPsec tunnel parameters on Router 2:

  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

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

Note:

If the IPsec peers do not have a symmetrical configuration containing all the necessary components, they cannot establish a peering relationship. You need to request a CA certificate, create a local certificate, load these digital certificates into the router, and reference them in your IPsec configuration. For information about digital certification, see Requesting for and Installing a Digital Certificates on Your Router

To configure OSPF connectivity and IPsec tunnel parameters on Router 3:

  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

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To set up OSPF connectivity with Router 4

  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:

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

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.

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

Note:

You can follow the same procedure and use the same configuration given in this example, to configure Junos VPN Site Secure (previously known as IPsec features) on MS-MPCs.

This example contains the following sections:

Requirements

This example uses the following hardware and software components:

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

The following Junos VPN Site Secure features are supported on the MS-MIC and MS-MPC in Release 13.2:

  • 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 TopologyIPsec VPN Tunnel Topology

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

While configuring the routers, note the following points:

  • 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

This section contains:

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 Interfaces on Router 1

Configuring IPsec VPN Service on Router 1

Configuring a Service Set on Router 1

Configuring Routing Options on Router 1

Configuring Interfaces on Router 2

Configuring IPsec VPN Service on Router 2

Configuring a Service Set on Router 2

Configuring Routing Options on Router 2

Configuring Router 1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

Note:

Starting with Release 13.2, the Junos OS extension-provider packages come preinstalled on multiservices MICs and MPCs (MS-MICs and MS-MPCs). The adaptive-services configuration at the [edit chassis fpc number pic number] hierarchy level is preconfigured on these cards.

  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

Purpose

Verify that Dynamic End Points are created.

Action

Run the following command on Router 1:

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

This example shows how to configure a statically assigned IPsec tunnel over a VRF instance, and contains the following sections:

Requirements

This example uses the following hardware and software components:

  • 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

This example shows the configuration of an IPsec tunnel over a VRF instance on a provider edge router, and provides step-by-step instructions for completing the required configuration.

This section contains:

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

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a statically assigned IPsec tunnel on a VRF instance:

  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

The following example-based instructions show how to configure IPsec services. The configuration involves defining an IKE policy, an IPsec policy, IPsec rules, trace options, and service sets.

This topic includes the following tasks:

Configuring the IKE Proposal

The IKE proposal configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway. For more information about IKE proposals, see Configuring IKE Proposals.

To define the IKE proposaI:

  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:

The following sample output shows the configuration of the IKE proposal:

Configuring the IKE Policy (and Referencing the IKE Proposal)

The IKE policy configuration defines the proposal, mode, addresses, and other security parameters used during IKE negotiation. For more information about IKE policies, see Configuring IKE Policies.

To define the IKE policy and reference 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:

The following sample output shows the configuration of the IKE policy:

Configuring the IPsec Proposal

The IPsec proposal configuration defines the protocols and algorithms (security services) that are required to negotiate with the remote IPsec peer. For more information about IPsec proposals, see Configuring IPsec Proposals.

To define 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:

The following sample output shows the configuration of the IPsec proposal:

Configuring the IPsec Policy (and Referencing the IPsec Proposal)

The IPsec policy configuration defines a combination of security parameters (IPsec proposals) used during IPsec negotiation. It defines PFS and the proposals needed for the connection. For more information about IPsec policies, see Configuring IPsec Policies.

To define the IPsec policy and reference 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:

The following sample output shows the configuration of the IPsec policy:

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

The IPsec rule configuration defines the direction that specifies whether the match is applied on the input or output side of the interface. The configuration also consists of a set of terms that specify the match conditions and applications that are included and excluded and also specify the actions and action modifiers to be performed by the router software. For more information about IPsec rules, see Configuring IPsec Rules.

To define the IPsec rule and reference 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:

The following sample output shows the configuration of the IPsec rule:

Configuring IPsec Trace Options

The IPsec trace options configuration tracks IPsec events and records them in a log file in the /var/log directory. By default, this file is named /var/log/kmd. For more information about IPsec rules, see Tracing Junos VPN Site Secure Operations.

To define the 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:

The following sample output shows the configuration of the IPsec trace options:

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

The access profile configuration defines the access profile and references the IKE and IPsec policies. For more information about access profile, see Configuring an IKE Access Profile.

To define the access profile and reference 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:

The following sample output shows the configuration of the access profile:

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

The service set configuration defines IPsec service sets that require additional specifications and references the IKE profile and the IPsec rule. For more information about IPsec service sets, see Configuring IPsec Service Sets.

To define the service set configuration with the next-hop service sets and IPsec VPN options:

  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:

The following sample output shows the configuration of the service set configuration referencing the IKE profile and the IPsec rule:

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

Note:

Junos VPN Site Secure is a suite of IPsec features supported on multiservices line cards (MS-DPC, MS-MPC, and MS-MIC), and was previously referred to as IPsec services.

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

To trace IPsec operations, include the traceoptions statement at the [edit services ipsec-vpn] hierarchy level:

You can specify the following IPsec tracing flags:

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

The level statement sets the key management process (kmd) tracing level. The following values are supported:

  • all—Match all levels.

  • error—Match error conditions.

  • info–Match informational messages.

  • notice—Match conditions that should be handled specially.

  • verbose—Match verbose messages.

  • warning—Match warning messages.

This section includes the following topics:

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.

Note:

This functionality is also provided by the passive-mode-tunneling statement. You can use the no-ipsec-tunnel-in-traceroute statement in specific scenarios in which the IPsec tunnel should not be treated as a next hop and passive mode is not desired.

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:

You can specify the following PKI tracing flags:

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

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
18.2R1
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.
17.2R1
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.
17.1
Starting in Junos OS Release 17.1, AMS supports IPSec tunnel distribution
16.1
Starting in Junos OS Release 16.1, to configure link-type tunnels, (i.e., next-hop style), for HA purposes, you can configure AMS logical interfaces as the IPsec internal interfaces by using the ipsec-inside-interface interface-name statement at the [edit services ipsec-vpn rule rule-name term term-name from] hierarchy level.
16.1
Starting in Junos OS Release 16.1, you can enable multipath forwarding of IPsec traffic by configuring UDP encapsulation in the service set, which adds a UDP header to the IPsec encapsulation of packets.
14.2
Starting in Junos OS Release 14.2, passive mode tunneling is supported on MS-MICs and MS-MPCs.
14.2
Starting in Junos OS Release 14.2, the header-integrity-check option that is supported on MS-MICs and MS-MPCs to verify the packet header for anomalies in IP, TCP, UDP, and ICMP information and flag such anomalies and errors has a functionality that is opposite to the functionality caused by passive mode tunneling.
14.1
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.