Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

Release History Table
Release
Description
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.
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.
Starting in Junos OS Release 17.1, AMS supports IPSec tunnel distribution
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 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.
Starting in Junos OS Release 14.2, passive mode tunneling is supported on MS-MICs and MS-MPCs.
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.
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.