VPNs for IKEv2

 

Internet Key Exchange version 2 (IKEv2) is an IPsec based tunneling protocol that provides a secure VPN communication channel between peer VPN devices and defines negotiation and authentication for IPsec security associations (SAs) in a protected manner.

Understanding Internet Key Exchange Version 2

Internet Key Exchange version 2 (IKEv2) is the latest version of the Internet Key Exchange (IKE) protocol defined in RFC 7296.

A VPN peer is configured as either IKEv1 or IKEv2. When a peer is configured as IKEv2, it cannot fall back to IKEv1 if its remote peer initiates IKEv1 negotiation. By default, Juniper Networks security devices are IKEv1 peers.

Use the version v2-only configuration statement at the [edit security ike gateway gw-name] hierarchy level to configure IKEv2. The IKE version is displayed in the output of the show security ike security-associations and show security ipsec security-associations CLI operational commands.

The advantages of using IKEv2 over IKEv1 are as follows:

  • Replaces eight initial exchanges with a single four-message exchange.

  • Reduces the latency for the IPsec SA setup and increases connection establishment speed.

  • Increases robustness against DOS attacks.

  • Improves reliability through the use of sequence numbers, acknowledgements, and error correction.

  • Improves reliability, as all messages are requests or responses. The initiator is responsible for retransmitting if it does not receive a response.

IKEv2 includes support for:

  • Route-based VPNs.

    Note

    IKEv2 does not support policy-based VPNs.

  • Site-to-site VPNs.

  • Dead peer detection.

  • Chassis cluster.

  • Certificate-based authentication.

  • Child SAs. An IKEv2 child SA is known as a Phase 2 SA in IKEv1. In IKEv2, a child SA cannot exist without the underlying IKE SA. If a child SA is required, it is rekeyed. However, if child SAs are currently active, the corresponding IKE SA is rekeyed.

    Note

    On SRX Series devices, if an IPsec VPN tunnel is established using IKEv2, a small number of packet drops might be observed during CHILD_SA rekey as a result of "bad SPI" being logged. This occurs only when the SRX Series device is the responder for this rekey and the peer is a non-Juniper Networks device, and the latency between the peers is low and the packet rate is high. To avoid this issue, ensure that the SRX Series device always initiates the rekeys by setting its IPsec lifetime to a lower value than that of the peer.

  • AutoVPN.

  • Dynamic endpoint VPN.

  • Traffic selectors.

IKEv2 does not support the following features:

  • Policy-based VPN.

  • Dialup tunnels.

  • VPN monitoring.

  • Multiple child SAs for the same traffic selectors for each QoS value.

  • IP Payload Compression Protocol (IPComp).

EAP is supported for Remote Access using IKEv2.

Starting in Junos OS Release 19.1R1, two new options for establishment of IPSec tunnels are introduced, responder-only and responder-only-no-rekey are added to the establish-tunnels command under the [edit security ipsec vpn vpn-name] hierarchy-level.

The responder-only option does not establish any VPN tunnel from the device, so the VPN tunnel is initiated from the remote peer. An established tunnel rekeys both IKE and IPSec based on the configured IKE and IPSec lifetime values.

The responder-only-no-rekey option does not establish any VPN tunnel from the device, so the VPN tunnel is initiated from the remote peer. An established tunnel does not rekey from the device and relies on the remote peer to initiate rekey. If the remote peer does not initiate rekey, then the tunnel teardown occurs after hard-lifetime expires.

Understanding IKEv2 Configuration Payload

Configuration payload is an Internet Key Exchange version 2 (IKEv2) feature used to propagate provisioning information from a responder (or server) to an initiator (or client). IKEv2 configuration payload is supported with route-based VPNs only.

RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), defines 15 different configuration attributes that can be returned to the initiator by the responder. Table 1 describes the IKEv2 configuration attributes supported on SRX Series devices.

Table 1: IKEv2 Configuration Attributes

Attribute Type

Value

Description

Length

INTERNAL_IP4_ADDRESS

1

Specifies an address on the internal network. Multiple internal addresses can be requested. The responder can send up to the number of addresses requested.

0 or 4 octets

INTERNAL_IP4_NETMASK

2

Specifies the internal network's netmask value. Only one netmask value is allowed in the request and response messages (for example, 255.255.255.0), and it must be used only with an INTERNAL_IP4_ADDRESS attribute.

0 or 4 octets

INTERNAL_IP4_DNS

3

Specifies an address of a DNS server within the network. Multiple DNS servers can be requested. The responder can respond with zero or more DNS server attributes.

0 or 4 octets

INTERNAL_IP4_NBNS

4

Specifies an address of a NetBIOS name server (NBNS), for example, a WINS server, within the network. Multiple NBNS servers can be requested. The responder can respond with zero or more NBNS server attributes.

0 or 4 octets

INTERNAL_IP4_DHCP

6

Instructs the host to send any internal DHCP request to the address contained within the attribute. Multiple DHCP servers can be requested. The responder can respond with zero or more DHCP server attributes.

0 or 4 octets

For the IKE responder to provide the initiator with provisioning information, it must acquire the information from a specified source such as a RADIUS server. Provisioning information can also be returned from a DHCP server through a RADIUS server. On the RADIUS server, the user information should not include an authentication password. The RADIUS server profile is bound to the IKE gateway using the aaa access-profile profile-name configuration at the [edit security ike gateway gateway-name] hierarchy level.

In a route-based VPN, secure tunnel (st0) interfaces operate in either point-to-multipoint or point-to-point mode. Dynamic address assignment through the IKEv2 configuration payload is supported for point-to-multipoint interfaces only. For point-to-multipoint interfaces, the interfaces must be numbered and the addresses in the configuration payload INTERNAL_IP4_ADDRESS attribute type must be within the subnetwork range of the associated point-to-multipoint interface.

Understanding Pico Cell Provisioning

IKEv2 configuration payload can be used to propagate provisioning information from an IKE responder, such as an SRX Series device, to multiple initiators, such as LTE pico cell base stations in a cellular network. The pico cells ship from the factory with a standard configuration that allows them to connect to the SRX Series device, but the pico cell provisioning information is stored on one or more provisioning servers within a protected network. The pico cells receive full provisioning information after establishing secure connections with the provisioning servers.

The workflow required to bootstrap and provision a pico cell and introduce it to service includes four distinct stages:

  1. Initial addresses acquisition—The pico cell ships from the factory with the following information:
    • Configuration for the secure gateway tunnel to the SRX Series device

    • Digital certificate issued by the manufacturer

    • Fully qualified domain name (FQDN) of the provisioning servers that lie within the protected network

    The pico cell boots up and acquires an address to be used for IKE negotiation from a DHCP server. A tunnel is then built to the secure gateway on the SRX Series device using this address. An address for Operation, Administration, and Management (OAM) traffic is also assigned by the DHCP server for use on the protected network.

  2. Pico cell provisioning—Using its assigned OAM traffic address, the pico cell requests its provisioning information—typically operator certificate, license, software, and configuration information—from servers within the protected network.
  3. Reboot—The pico cell reboots and uses the acquired provisioning information to make it specific to the service provider’s network and operation model.
  4. Service provision—When the pico cell enters service, it uses a single certificate that contains distinguished name (DN) and subject alternative name values with a FQDN to build two tunnels to the secure gateway on the SRX Series device: one for OAM traffic and the other for Third-Generation Partnership Project (3GPP) data traffic.

Figure 1 shows a typical workflow for a pico cell deployment.

Figure 1: Typical Pico Cell Deployment Workflow
 Typical Pico Cell
Deployment Workflow
Note

The IKEv2 configuration payload feature is supported only for point-to-multipoint secure tunnel (st0) interfaces. Point-to-multipoint interfaces must be numbered, and the addresses provided in the configuration payload must be within the subnetwork range of the associated point-to-multipoint interface.

Configuring Establish-Tunnel Responder-only in IKE

This topic shows how to configure establish-tunnels responder-only in Internet Key Exchange (IKE). Initiate the tunnels from the remote peer and send the traffic through all the tunnels. Specifies when IKE is activated.

Before you begin:

To configure establish-tunnel responder-only in IKE:

  1. Configure establish-tunnel responder-only
  2. Confirm your configuration by entering the show security ipsec vpn IPSEC_VPN command.
  3. Configure establish-tunnel responder-only-no-rekey
  4. Confirm your configuration by entering the show security ipsec vpn IPSEC_VPN command.
    Note

    In case of multiple VPN objects, the Responder-only mode will take precedence. If any of the VPN in a gateway is configured with responder-only mode, all VPN's in the gateway must be configured with the responder-only mode.

Understanding IKEv2 Reauthentication

Overview

With IKEv2, rekeying and reauthentication are separate processes. Rekeying establishes new keys for the IKE security association (SA) and resets message ID counters, but it does not reauthenticate the peers. Reauthentication verifies that VPN peers retain their access to authentication credentials. Reauthentication establishes new keys for the IKE SA and child SAs; rekeys of any pending IKE SA or child SA are no longer needed. After the new IKE and child SAs are created, the old IKE and child SAs are deleted.

IKEv2 reauthentication is disabled by default. You enable reauthentication by configuring a reauthentication frequency value between 1 and 100. The reauthentication frequency is the number of IKE rekeys that occurs before reauthentication occurs. For example, if the configured reauthentication frequency is 1, reauthentication occurs every time there is an IKE rekey. If the configured reauthentication frequency is 2, reauthentication occurs at every other IKE rekey. If the configured reauthentication frequency is 3, reauthentication occurs at every third IKE rekey, and so on.

You configure the reauthentication frequency with the reauth-frequency statement at the [edit security ike policy policy-name] hierarchy level. Reauthentication is disabled by setting the reauthentication frequency to 0 (the default). Reauthentication frequency is not negotiated by peers, and each peer can have its own reauthentication frequency value.

Supported Features

IKEv2 reauthentication is supported with the following features:

  • IKEv2 initiators or responders

  • Dead peer detection (DPD)

  • Virtual routers and secure tunnel (st0) interfaces in virtual routers

  • Network Address Translation traversal (NAT-T)

  • Chassis clusters in active-active and active-passive mode for SRX5400, SRX5600, and SRX5800 devices

  • In-service software upgrade (ISSU) on SRX5400, SRX5600, and SRX5800 devices

  • Upgrade or insertion of a new Services Processing Unit (SPU) using the in-service hardware upgrade (ISHU) procedure

Limitations

Note the following caveats when using IKEv2 reauthentication:

  • With NAT-T, a new IKE SA can be created with different ports from the previous IKE SA. In this scenario, the old IKE SA might not be deleted.

  • In a NAT-T scenario, the initiator behind the NAT device can become the responder after reauthentication. If the NAT session expires, the NAT device might discard new IKE packets that might arrive on a different port. NAT-T keepalive or DPD must be enabled to keep the NAT session alive. For AutoVPN, we recommend that the reauthentication frequency configured on the spokes be smaller than the reauthentication frequency configured on the hub.

  • Based on the reauthentication frequency, a new IKE SA can be initiated by either the initiator or the responder of the original IKE SA. Because Extensible Authentication Protocol (EAP) authentication and configuration payload require the IKE SA to be initiated by the same party as the original IKE SA, reauthentication is not supported with EAP authentication or configuration payload.

Understanding Certificate Chains

Multilevel Hierarchy for Certificate Authentication

Certificate-based authentication is an authentication method supported on SRX Series devices during IKE negotiation. In large networks, multiple certificate authorities (CAs) can issue end entity (EE) certificates to their respective end devices. It is common to have separate CAs for individual locations, departments, or organizations.

When a single-level hierarchy for certificate-based authentication is employed, all EE certificates in the network must be signed by the same CA. All firewall devices must have the same CA certificate enrolled for peer certificate validation. The certificate payload sent during IKE negotiation only contains EE certificates.

Alternatively, the certificate payload sent during IKE negotiation can contain a chain of EE and CA certificates. A certificate chain is the list of certificates required to validate a peer’s EE certificate. The certificate chain includes the EE certificate and any CA certificates that are not present in the local peer.

The network administrator needs to ensure that all peers participating in an IKE negotiation have at least one common trusted CA in their respective certificate chains. The common trusted CA does not have to be the root CA. The number of certificates in the chain, including certificates for EEs and the topmost CA in the chain, cannot exceed 10.

Starting with Junos OS Release 18.1R1, validation of a configured IKE peer can be done with a specified CA server or group of CA servers. With certificate chains, the root CA must match the trusted CA group or CA server configured in the IKE policy

In the example CA hierarchy shown in Figure 2, Root-CA is the common trusted CA for all devices in the network. Root-CA issues CA certificates to the engineering and sales CAs, which are identified as Eng-CA and Sales-CA, respectively. Eng-CA issues CA certificates to the development and quality assurance CAs, which are identified as Dev-CA and Qa-CA, respectively. Host-A receives its EE certificate from Dev-CA while Host-B receives its EE certificate from Sales-CA.

Figure 2: Multilevel Hierarchy for Certificate-Based Authentication
 Multilevel
Hierarchy for Certificate-Based Authentication

Each end device needs to be loaded with the CA certificates in its hierarchy. Host-A must have Root-CA, Eng-CA, and Dev-CA certificates; Sales-CA and Qa-CA certificates are not necessary. Host-B must have Root-CA and Sales-CA certificates. Certificates can be loaded manually in a device or enrolled using the Simple Certificate Enrollment Process (SCEP).

Each end device must be configured with a CA profile for each CA in the certificate chain. The following output shows the CA profiles configured on Host-A:

The following output shows the CA profiles configured on Host-B:

Example: Configuring a Device for Peer Certificate Chain Validation

This example shows how to configure a device for certificate chains used to validate peer devices during IKE negotiation.

Requirements

Before you begin, obtain the address of the certificate authority (CA) and the information they require (such as the challenge password) when you submit requests for local certificates.

Overview

This example shows how to configure a local device for certificate chains, enroll CA and local certificates, check the validity of enrolled certificates, and check the revocation status of the peer device.

This example shows the configuration and operational commands on Host-A, as shown in Figure 3. A dynamic CA profile is automatically created on Host-A to allow Host-A to download the CRL from Sales-CA and check the revocation status of Host-B’s certificate.

Figure 3: Certificate Chain Example
 Certificate
Chain Example
Note

The IPsec VPN configuration for Phase 1 and Phase 2 negotiation is shown for Host-A in this example. The peer device (Host-B) must be properly configured so that Phase 1 and Phase 2 options are successfully negotiated and security associations (SAs) are established. See Configuring Remote IKE IDs for Site-to-Site VPNs for examples of configuring peer devices for VPNs.

Configuration

To configure a device for certificate chains:

Configure CA Profiles

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure CA profiles:

  1. Create the CA profile for Root-CA.
  2. Create the CA profile for Eng-CA.
  3. Create the CA profile for Dev-CA.

Results

From configuration mode, confirm your configuration by entering the show security pki command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Enroll Certificates

Step-by-Step Procedure

To enroll certificates:

  1. Enroll the CA certificates.

    Type yes at the prompts to load the CA certificate.

  2. Verify that the CA certificates are enrolled in the device.
    user@host> show security pki ca-certificate ca-profile Root-CA
    user@host> show security pki ca-certificate ca-profile Eng-CA
    user@host> show security pki ca-certificate ca-profile Dev-CA
  3. Verify the validity of the enrolled CA certificates.
    user@host> request security pki ca-certificate verify ca-profile Root-CA
    user@host> request security pki ca-certificate verify ca-profile Eng-CA
    user@host> request security pki ca-certificate verify ca-profile Dev-CA
  4. Generate a key pair.
  5. Enroll the local certificate.
  6. Verify that the local certificate is enrolled in the device.
    user@host> show security pki local-certificate
  7. Verify the validity of the enrolled local certificate.
    user@host> request security pki local-certificate verify certificate-id Host-A
  8. Check the CRL download for configured CA profiles.
    user@host> show security pki crl

Configure IPsec VPN Options

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IPsec VPN options:

  1. Configure Phase 1 options.
  2. Configure Phase 2 options.

Results

From configuration mode, confirm your configuration by entering the show security ike and show security ipsec commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

If certificate validation is successful during IKE negotiation between peer devices, both IKE and IPsec security associations (SAs) are established.

The IKE SA is UP if the certificate is valid. The IKE SA is DOWN and IPSEC SA is formed if the certificate is revoked, only if revocation check is configured on the peer device

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

Enter the show security ike security-associations command from operational mode.

user@host> show security ike security-associations

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

Enter the show security ipsec security-associations command from operational mode.

user@host> show security ipsec security-associations

IKE and IPsec SA Failure for a Revoked Certificate

Checking for Revoked Certificates

Problem

If certificate validation fails during IKE negotiation between peer devices, check to make sure that the peer’s certificate has not been revoked. A dynamic CA profile allows the local device to download the CRL from the peer’s CA and check the revocation status of the peer’s certificate. To enable dynamic CA profiles, the revocation-check crl option must be configured on a parent CA profile.

Solution

To check the revocation status of a peer’s certificate:

  1. Identify the dynamic CA profile that will show the CRL for the peer device by entering the show security pki crl command from operational mode.
    user@host> show security pki crl

    The CA profile dynamic-001 is automatically created on Host-A so that Host-A can download the CRL from Host-B’s CA (Sales-CA) and check the revocation status of the peer’s certificate.

  2. Display CRL information for the dynamic CA profile by entering the show security pki crl ca-profile dynamic-001 detail command from operational mode.

    Enter

    user@host> show security pki crl ca-profile dynamic-001 detail

    Host-B’s certificate (serial number 10647084) has been revoked.

Understanding IKEv2 Fragmentation

Overview

When certificate-based authentication is used, IKEv2 packets can exceed the path MTU if multiple certificates are transmitted. If the IKE message size exceeds the path MTU, the messages are fragmented at the IP level. Some network equipment, such as NAT devices, does not allow IP fragments to pass through, which prevents the establishment of IPsec tunnels.

Message Fragmentation

IKEv2 message fragmentation, as described in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, allows IKEv2 to operate in environments where IP fragments might be blocked and peers would not be able to establish an IPsec security association (SA). IKEv2 fragmentation splits a large IKEv2 message into a set of smaller ones so that there is no fragmentation at the IP level. Fragmentation takes place before the original message is encrypted and authenticated, so that each fragment is separately encrypted and authenticated. On the receiver, the fragments are collected, verified, decrypted, and merged into the original message.

For IKEv2 fragmentation to occur, both VPN peers must indicate fragmentation support by including the IKEV2_FRAGMENTATION_SUPPORTED notification payload in the IKE_SA_INIT exchange. If both peers indicate fragmentation support, it is up to the initiator of the message exchange to determine whether or not IKEv2 fragmentation is used.

On SRX Series devices, a maximum of 32 fragments are allowed per IKEv2 message. If the number of IKEv2 message fragments to be sent or received exceeds 32, the fragments are dropped and the tunnel is not established. Retransmission of individual message fragments is not supported

Configuration

On SRX Series devices, IKEv2 fragmentation is enabled by default for IPv4 and IPv6 messages. To disable IKEv2 fragmentation, use the disable statement at the [edit security ike gateway gateway-name fragmentation] hierarchy level. You can also use the size statement to configure the size of the packet at which messages are fragmented; the packet size ranges from 500 to 1300 bytes. If size is not configured, the default packet size is 576 bytes for IPv4 traffic and 1280 bytes for IPv6 traffic. An IKEv2 packet that is larger than the configured packet size is fragmented.

After IKEv2 fragmentation is disabled or enabled or the packet fragment size is changed, the VPN tunnels that are hosted on the IKE gateway are brought down and IKE and IPsec SAs are renegotiated.

Caveats

The following features are not supported with IKEv2 fragmentation:

  • Path MTU Discovery.

  • SNMP.

Example: Configuring a Route-Based VPN for IKEv2

This example shows how to configure a route-based IPsec VPN to allow data to be securely transferred between a branch office and a corporate office.

Requirements

This example uses the following hardware:

  • SRX240 device

  • SSG140 device

Before you begin, read IPsec VPN Overview.

Overview

In this example, you configure a route-based VPN for a branch office in Chicago, Illinois, because you want to conserve tunnel resources but still get granular restrictions on VPN traffic. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

In this example, you configure interfaces, an IPv4 default route, security zones, and address books. Then you configure IKE Phase 1, IPsec Phase 2, a security policy, and TCP-MSS parameters. See Table 2 through Table 6 for specific configuration parameters used in this example.

Table 2: Interface, Static Route, Security Zone, and Address Book Information

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/0.0

192.168.10.1/24

ge-0/0/3.0

10.1.1.2/30

st0.0 (tunnel interface)

10.11.11.10/24

Static routes

0.0.0.0/0 (default route)

The next hop is 10.1.1.1.

192.168.168.0/24

The next hop is st0.0.

Security zones

trust

  • All system services are allowed.

  • The ge-0/0/0.0 interface is bound to this zone.

untrust

  • IKE is the only allowed system service.

  • The ge-0/0/3.0 interface is bound to this zone.

vpn-chicago

The st0.0 interface is bound to this zone.

Address book entries

sunnyvale

  • This address is for the trust zone’s address book.

  • The address for this address book entry is 192.168.10.0/24.

chicago

  • This address is for the untrust zone’s address book.

  • The address for this address book entry is 192.168.168.0/24.

Table 3: IKE Phase 1 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ike-phase1-proposal

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: aes-128-cbc

Policy

ike-phase1-policy

  • Mode: main

  • Proposal reference: ike-phase1-proposal

  • IKE Phase 1 policy authentication method: pre-shared-key ascii-text

Gateway

gw-chicago

  • IKE policy reference: ike-phase1-policy

  • External interface: ge-0/0/3.0

  • Gateway address: 10.2.2.2

Table 4: IPsec Phase 2 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ipsec-phase2-proposal

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: aes-128-cbc

Policy

ipsec-phase2-policy

  • Proposal reference: ipsec-phase2-proposal

  • PFS: Diffie-Hellman group2

VPN

ipsec-vpn-chicago

  • IKE gateway reference: gw-chicago

  • IPsec policy reference: ipsec-phase2-policy

  • Bind to interface: st0.0

Table 5: Security Policy Configuration Parameters

Purpose

Name

Configuration Parameters

The security policy permits traffic from the trust zone to the vpn-chicago zone.

vpn-tr-chi

  • Match criteria:

    • source-address sunnyvale

    • destination-address chicago

    • application any

  • Action: permit

The security policy permits traffic from the vpn-chicago zone to the trust zone.

vpn-chi-tr

  • Match criteria:

    • source-address chicago

    • destination-address sunnyvale

    • application any

  • Action: permit

Table 6: TCP-MSS Configuration Parameters

Purpose

Configuration Parameters

TCP-MSS is negotiated as part of the TCP three-way handshake and limits the maximum size of a TCP segment to better fit the MTU limits on a network. For VPN traffic, the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting ESP packet to exceed the MTU of the physical interface, which causes fragmentation. Fragmentation increases bandwidth and device resources.

Note: We recommend a value of 1350 as the starting point for most Ethernet-based networks with an MTU of 1500 or greater. You might need to experiment with different TCP-MSS values to obtain optimal performance. For example, you might need to change the value if any device in the path has a lower MTU, or if there is any additional overhead such as PPP or Frame Relay.

MSS value: 1350

Configuration

Configuring Interface, Static Route, Security Zone, and Address Book Information

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure interface, static route, security zone, and address book information:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the untrust security zone.
  4. Assign an interface to the security zone.
  5. Specify allowed system services for the security zone.
  6. Configure the trust security zone.
  7. Assign an interface to the trust security zone.
  8. Specify allowed system services for the trust security zone.
  9. Configure the address book entry for the trust security zone.
  10. Configure the vpn-chicago security zone.
  11. Assign an interface to the security zone.
  12. Configure the address book entry for the vpn-chicago zone.

Results

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

If you are done configuring the device, enter commit from configuration mode.

Configuring IKE

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IKE:

  1. Create the IKE Phase 1 proposal.
  2. Define the IKE proposal authentication method.
  3. Define the IKE proposal Diffie-Hellman group.
  4. Define the IKE proposal authentication algorithm.
  5. Define the IKE proposal encryption algorithm.
  6. Create an IKE Phase 1 policy.
  7. Specify a reference to the IKE proposal.
  8. Define the IKE Phase 1 policy authentication method.
  9. Create an IKE Phase 1 gateway and define its external interface.
  10. Define the IKE Phase 1 policy reference.
  11. Define the IKE Phase 1 gateway address.
  12. Define the IKE Phase 1 gateway version.

Results

From configuration mode, confirm your configuration by entering the show security ike command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring IPsec

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IPsec:

  1. Create an IPsec Phase 2 proposal.
  2. Specify the IPsec Phase 2 proposal protocol.
  3. Specify the IPsec Phase 2 proposal authentication algorithm.
  4. Specify the IPsec Phase 2 proposal encryption algorithm.
  5. Create the IPsec Phase 2 policy.
  6. Specify the IPsec Phase 2 proposal reference.
  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
  8. Specify the IKE gateway.
  9. Specify the IPsec Phase 2 policy.
  10. Specify the interface to bind.

Results

From configuration mode, confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring Security Policies

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure security policies:

  1. Create the security policy to permit traffic from the trust zone to the vpn-chicago zone.
  2. Create the security policy to permit traffic from the vpn-chicago zone to the trust zone.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring TCP-MSS

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure TCP-MSS information:

  1. Configure TCP-MSS information.

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring the SSG Series Device

CLI Quick Configuration

For reference, the configuration for the SSG Series device is provided. For information about configuring SSG Series devices, see the Concepts & Examples ScreenOS Reference Guide, which is located at https://www.juniper.net/documentation.

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

Verification

Confirm that the configuration is working properly.

Verifying the IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

Note

Before starting the verification process, you need to send traffic from a host in the 192.168.10/24 network to a host in the 192.168.168/24 network. For route-based VPNs, traffic can be initiated by the SRX Series device through the tunnel. We recommend that when testing IPsec tunnels, test traffic be sent from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate a ping from 192.168.10.10 to 192.168.168.10.

From operational mode, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations index index_number detail command.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs. If no SAs are listed, there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration.

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations index detail command to get more information about the SA.

  • Remote Address—Verify that the remote IP address is correct.

  • State

    • UP—The Phase 1 SA has been established.

    • DOWN—There was a problem establishing the Phase 1 SA.

  • Mode—Verify that the correct mode is being used.

Verify that the following are correct in your configuration:

  • External interfaces (the interface must be the one that receives IKE packets).

  • IKE policy parameters.

  • Preshared key information.

  • Phase 1 proposal parameters (must match on both peers).

The show security ike security-associations index 1 detail command lists additional information about the SA with an index number of 1:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

  • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)

  • Role information

    Note

    Troubleshooting is best performed on the peer using the responder role.

  • Initiator and responder information

  • Number of IPsec SAs created

Verifying the IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the show security ipsec security-associations command. After obtaining an index number from the command, use the show security ipsec security-associations index index_number detail command.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations index 16384 detail

Meaning

The output from the show security ipsec security-associations command lists the following information:

  • The ID number is 16384. Use this value with the show security ipsec security-associations index command to get more information about this particular SA.

  • There is one IPsec SA pair using port 500.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3363/ unlim value indicates that the Phase 2 lifetime expires in 3363 seconds, and that no lifesize has been specified, which indicates that it is unlimited. Phase 2 lifetime can differ from Phase 1 lifetime, because Phase 2 is not dependent on Phase 1 after the VPN is up.

  • The vsys is the root system, and it is always listed as 0.

  • The IKEv2 allows connections from a version 2 peer and will initiate a version 2 negotiation.

The output from the show security ipsec security-associations index 16384 detail command lists the following information:

  • The local identity and remote identity make up the proxy ID for the SA.

    A proxy ID mismatch is one of the most common causes for a Phase 2 failure. If no IPsec SA is listed, confirm that Phase 2 proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.

  • Another common reason for Phase 2 failure is not specifying the ST interface binding. If IPsec cannot complete, check the kmd log or set trace options.

Reviewing Statistics and Errors for an IPsec Security Association

Purpose

Review ESP and authentication header counters and errors for an IPsec SA.

Action

From operational mode, enter the show security ipsec statistics index index_number command, using the index number of the VPN for which you want to see statistics.

user@host> show security ipsec statistics index 16384

You can also use the show security ipsec statistics command to review statistics and errors for all SAs.

To clear all IPsec statistics, use the clear security ipsec statistics command.

Meaning

If you see packet loss issues across a VPN, you can run the show security ipsec statistics or show security ipsec statistics detail command several times to confirm that the encrypted and decrypted packet counters are incrementing. You should also check that the other error counters are incrementing.

Testing Traffic Flow Across the VPN

Purpose

Verify the traffic flow across the VPN.

Action

You can use the ping command from the SRX Series device to test traffic flow to a remote host PC. Make sure that you specify the source interface so that the route lookup is correct and the appropriate security zones are referenced during policy lookup.

From operational mode, enter the ping command.

ssg-> ping 192.168.168.10 interface ge-0/0/0 count 5

You can also use the ping command from the SSG Series device.

user@host> ping 192.168.10.10 from ethernet0/6

Meaning

If the ping command fails from the SRX Series or SSG Series device, there might be a problem with the routing, security policies, end host, or encryption and decryption of ESP packets.

Example: Configuring the SRX Series for Pico Cell Provisioning with IKEv2 Configuration Payload

In networks where many devices are being deployed, managing the network needs to be simple. The IKEv2 configuration payload feature supports the provisioning of these devices without touching either the device configuration or the SRX Series configuration. This example shows how to configure an SRX Series to support pico cell provisioning using the IKEv2 configuration payload feature.

Requirements

This example uses the following hardware and software components:

  • Two SRX Series devices configured in a chassis cluster

  • One SRX Series device configured as an intermediate router

  • Two pico cell clients

  • One RADIUS server configured with pico cell client provisioning information

  • Junos OS Release 12.1X46-D10 or later for IKEv2 configuration payload support

Overview

In this example, an SRX Series uses the IKEv2 configuration payload feature to propagate provisioning information to a series of pico cells. The pico cells ship from the factory with a standard configuration that allows them to connect to the SRX Series, but the pico cell provisioning information is stored on an external RADIUS server. The pico cells receive full provisioning information after establishing secure connections with provisioning servers in a protected network. The IKEv2 configuration payload feature is supported for IPv4 only.

Figure 4 shows a topology in which the SRX Series supports pico cell provisioning using the IKEv2 configuration payload feature.

Figure 4: SRX Series Support for Pico Cell Provisioning with IKEv2 Configuration Payload
SRX Series Support for Pico Cell Provisioning
with IKEv2 Configuration Payload

Each pico cell in this topology initiates two IPsec VPNs: one for management and one for data. In this example, management traffic uses the tunnel labeled OAM Tunnel, while the data traffic flows through the tunnel labeled 3GPP Tunnel. Each tunnel supports connections with OAM and 3GPP provisioning servers on separate, configurable networks, requiring separate routing instances and VPNs. This example provides the IKE Phase 1 and Phase 2 options for establishing the OAM and 3GPP VPNs.

In this example, the SRX Series acts as the IKEv2 configuration payload server, acquiring provisioning information from the RADIUS server and providing that information to the pico cell clients. The SRX Series returns the provisioning information for each authorized client in the IKEv2 configuration payload during tunnel negotiation. The SRX Series cannot be used as a client device.

Additionally, the SRX Series uses the IKEv2 configuration payload information to update the Traffic Selector initiator (TSi) and Traffic Selector responder (TSr) values exchanged with the client during tunnel negotiation. The configuration payload uses the TSi and TSr values that are configured on the SRX Series using the proxy-identity statement at the [edit security ipsec vpn vpn-name ike] hierarchy level. The TSi and TSr values define the network traffic for each VPN.

The intermediate router routes pico cell traffic to the appropriate interfaces on the SRX Series.

The following process describes the connection sequence:

  1. The pico cell initiates an IPsec tunnel with the SRX Series using the factory configuration.
  2. The SRX Series authenticates the client using the client certificate information and the root certificate of the CA that is enrolled in the SRX Series. After authentication, the SRX Series passes the IKE identity information from the client certificate to the RADIUS server in an authorization request.
  3. After authorizing the client, the RADIUS server responds to the SRX Series with the client provisioning information:
    • IP address (TSi value)

    • IP subnet mask (optional; the default is 32 bit)

    • DNS address (optional)

  4. The SRX Series returns the provisioning information in the IKEv2 configuration payload for each client connection, and exchanges final TSi and TSr values with the pico cells. In this example, the SRX Series provides the following TSi and TSr information for each VPN:

    VPN Connection

    TSi/TSr Values Provided by SRX

    Pico 1 OAM

    TSi: 12.12.1.201/32, TSr: 192.168.2.0/24

    Pico 1 3GPP

    TSi: 13.13.1.201/32, TSr: 192.169.2.0/24, TSr: 13.13.0.0/16

    Pico 2 OAM

    TSi: 12.12.1.205/32, TSr: 192.168.2.0/24

    Pico 2 3GPP

    TSi: 13.13.1.205/32, TSr: 192.169.2.0/24, TSr: 13.13.0.0/16

    Note

    If the provisioning information supplied by the RADIUS server includes a subnet mask, the SRX Series returns a second TSr value for the client connection that includes the IP subnet. This enables intrapeer communication for devices on that subnet. In this example, intrapeer communication is enabled for the subnet associated with the 3GPP VPN (13.13.0.0/16).

    Note

    The IKEv2 configuration payload feature is supported only for point-to-multipoint secure tunnel (st0) interfaces. For point-to-multipoint interfaces, the interfaces must be numbered, and the addresses provided in the configuration payload must be within the subnetwork range of the associated point-to-multipoint interface.

Table 7 shows the Phase 1 and Phase 2 options configured on the SRX Series, including information for establishing both OAM and 3GPP tunnels.

Table 7: Phase 1 and Phase 2 Options for the SRX Series

Option

Value

IKE proposal:

Proposal name

IKE_PROP

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

group5

Authentication algorithm

SHA-1

Encryption algorithm

AES 256 CBC

IKE policy:

IKE Policy name

IKE_POL

Local certificate

Example_SRX

IKE gateway (OAM):

IKE policy

IKE_POL

Remote IP address

dynamic

IKE user type

group-ike-id

Local IKE ID

hostname srx_series.example.net

Remote IKE ID

hostname .pico_cell.net

External interface

reth0.0

Access profile

radius_pico

IKE version

v2-only

IKE gateway (3GPP):

IKE policy

IKE_POL

Remote IP address

Dynamic

IKE user type

group-ike-id

Local IKE ID

distinguished-name wildcard OU=srx_series

Remote IKE ID

distinguished-name wildcard OU=pico_cell

External interface

reth1

Access profile

radius_pico

IKE version

v2-only

IPsec proposal:

Proposal name

IPSEC_PROP

Protocol

ESP

Authentication algorithm

HMAC SHA-1 96

Encryption algorithm

AES 256 CBC

IPsec policy:

Policy name

IPSEC_POL

Perfect Forward Secrecy (PFS) keys

group5

IPsec proposals

IPSEC_PROP

IPsec VPN (OAM):

Bind interface

st0.0

IKE gateway

OAM_GW

Local proxy-identity

192.168.2.0/24

Remote proxy-identity

0.0.0.0/0

IPsec policy

IPSEC_POL

IPsec VPN (3GPP):

Bind interface

st0.1

IKE gateway

3GPP_GW

Local proxy-identity

192.169.2.0/24

Remote proxy-identity

0.0.0.0/0

IPsec policy

IPSEC_POL

Certificates are stored on the pico cells and the SRX Series.

Note

In this example, the default security policy that permits all traffic is used for all devices. More restrictive security policies should be configured for production environments. See Security Policies Overview.

Configuration

Configuring the SRX Series

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure the SRX Series:

  1. Configure the chassis cluster.
  2. Configure interfaces.
  3. Configure routing options.
  4. Specify security zones.
  5. Create the RADIUS profile.
  6. Configure Phase 1 options.
  7. Specify Phase 2 options.
  8. Specify the routing instances.
  9. Specify security policies to permit site-to-site traffic.

Results

From configuration mode, confirm your configuration by entering the show chassis cluster, show interfaces, show security zones, show access profile radius_pico, show security ike, show security ipsec, show routing-instances, and show security policies commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring the Intermediate 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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure the intermediate router:

  1. Configure interfaces.
  2. Configure routing options.
  3. Specify security zones.
  4. Specify security policies.

Results

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

If you are done configuring the device, enter commit from configuration mode.

Configuring the Pico Cell (Sample Configuration)

Step-by-Step Procedure

The pico cell information in this example is provided for reference. Detailed pico cell configuration information is beyond the scope of this document. The pico cell factory configuration must include the following information:

  • Local certificate (X.509v3) and IKE identity information

  • Traffic Selector (TSi, TSr) values set to any/any (0.0.0.0/0)

  • SRX Series IKE identity information and public IP address

  • Phase 1 and Phase 2 proposals that match the SRX Series configuration

The pico cells in this example use strongSwan open source software for IPsec-based VPN connections. This information is used by the SRX Series for pico cell provisioning using the IKEv2 configuration payload feature. In networks where many devices are being deployed, the pico cell configuration can be identical except for the certificate (leftcert) and identity (leftid) information. The following sample configurations illustrate factory settings.

  1. Review the Pico 1 configuration:

    Pico 1: Sample Configuration

  2. Review the Pico 2 configuration:

    Pico 2 Sample Configuration

Configuring the RADIUS Server (Sample Configuration using a FreeRADIUS)

Step-by-Step Procedure

The RADIUS server information in this example is provided for reference. Complete RADIUS server configuration information is beyond the scope of this document. The following information is returned to the SRX Series by the RADIUS server:

  • Framed-IP-Address

  • Framed-IP-Netmask (optional)

  • Primary-DNS and Secondary-DNS (optional)

In this example, the RADIUS server has separate provisioning information for the OAM and 3GPP connections. The User-Name is taken from the client certificate information provided in the SRX Series authorization request.

Note

If the RADIUS server acquires client provisioning information from a DHCP server, the client identity information relayed to the DHCP server by the RADIUS server must be consistent with the client IKE identity information relayed to the RADIUS server by the SRX Series device. This ensures the continuity of the client identity across the various protocols.

Note

The communication channel between the SRX Series device and the RADIUS server is protected by a RADIUS shared secret.

  1. Review the RADIUS configuration for the Pico 1 OAM VPN. The RADIUS server has the following information:

    Sample RADIUS configuration earlier to Junos OS Releases 17.3R3, 17.4R2, 18.1R3, 18.2R2, 18.3R1, and 18.1R3-S2:

    FreeRADIUS configuration example:

    Sample RADIUS configuration starting from Junos OS Releases 17.3R3, 17.4R2, 18.1R3, 18.2R2, 18.3R1, and 18.1R3-S2:

    FreeRADIUS configuration example:

    In this case, the RADIUS server provides the default subnet mask (255.255.255.255), which blocks intrapeer traffic.

  2. Review the RADIUS configuration for the Pico 1 3GPP VPN. The RADIUS server has the following information:

    Sample RADIUS configuration earlier to Junos OS Release 17.3R4, 17.4R2, 18.1R3, 18.2R2, 18.3R1, and 18.1R2-S3:

    FreeRADIUS configuration example:

    Sample RADIUS configuration starting from Junos OS Release 17.3R4, 17.4R2, 18.1R3, 18.2R2, 18.3R1, and 18.1R2-S3:

    FreeRADIUS configuration example:

    In this case, the RADIUS server provides a subnet mask value (255.255.0.0), which enables intrapeer traffic.

    Note

    The clear-text password is hard-coded and is not configurable. Additionally, this example creates two tunnels from the same client certificate by using different parts of the certificate for User-Name (IKE identity) information.

Verification

Confirm that the configuration is working properly.

Verifying the IKE Phase 1 Status for the SRX Series

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode on node 0, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations detail command.

user@host# show security ike security-associations
user@host# show security ike security-associations index 553329718 detail

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs with pico cells devices. If no SAs are listed, there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration. This example shows only the IKE Phase 1 SA for the OAM VPN; however, a separate IKE Phase 1 SA will be displayed showing the IKE Phase 1 parameters for the 3GPP VPN.

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA: you can use the show security ike security-associations index detail command to get more information about the SA.

  • Remote address—Verify that the local IP address is correct and that port 500 is being used for peer-to-peer communication.

  • Role responder state:

    • Up—The Phase 1 SA has been established.

    • Down—There was a problem establishing the Phase 1 SA.

  • Peer (remote) IKE ID—Verify the certificate information is correct.

  • Local identity and remote identity—Verify these addresses are correct.

  • Mode—Verify that the correct mode is being used.

Verify that the following items are correct in your configuration:

  • External interfaces (the interface must be the one that sends IKE packets)

  • IKE policy parameters

  • Phase 1 proposal parameters (must match between peers)

The show security ike security-associations command lists the following additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

  • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)

  • Role information

    Note

    Troubleshooting is best performed on the peer using the responder role.

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the SRX Series

Purpose

Verify the IPsec status.

Action

From operational mode on node 0, enter the show security ipsec security-associations command. After obtaining an index number from the command, use the show security ipsec security-associations detail command.

user@host# show security ipsec security-associations
user@host# show security ipsec security-associations detail

Meaning

This examples shows the active IKE Phase 2 SAs for Pico 1. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IPsec policy parameters in your configuration. For each Phase 2 SA (OAM and 3GPP), information is provided in both the inbound and outboard direction. The output from the show security ipsec security-associations command lists the following information:

  • The remote gateway has an IP address of 1.1.1.1.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3529/ value indicates that the Phase 2 lifetime expires in 3529 seconds, and that no lifesize has been specified, which indicates that it is unlimited. The Phase 2 lifetime can differ from the Phase 1 lifetime, because Phase 2 is not dependent on Phase 1 after the VPN is up.

  • VPN monitoring is not enabled for this SA, as indicated by a hyphen in the Mon column. If VPN monitoring is enabled, U indicates that monitoring is up, and D indicates that monitoring is down.

  • The virtual system (vsys) is the root system, and it always lists 0.

The above output from the show security ipsec security-associations index index_id detail command lists the following information:

  • The local identity and remote identity make up the proxy ID for the SA.

    A proxy ID mismatch is one of the most common causes for a Phase 2 failure. If no IPsec SA is listed, confirm that Phase 2 proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.

  • Authentication and encryption algorithms used.

  • Phase 2 proposal parameters (must match between peers).

  • Secure tunnel (st0.0 and st0.1) bindings to the OAM and 3GPP gateways.

Configuring an IKE Policy with a Trusted CA

This example shows how to bind a trusted CA server to an IKE policy of the peer.

Before you begin, you must have a list of all the trusted CAs you want to associate with the IKE policy of the peer.

You can associate an IKE policy to a single trusted CA profile or a trusted CA group. For establishing a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate. A certificate issued by any source other than the trusted CA or trusted CA group is not validated. If there is a certificate validation request coming from an IKE policy then the associated CA profile of the IKE policy will validate the certificate. If an IKE policy is not associated with any CA then by default the certificate is validated by any one of the configured CA profiles.

In this example, a CA profile named root-ca is created and a root-ca-identity is associated to the profile.

Note

You can configure a maximum of 20 CA profiles that you want to add to a trusted CA group. You cannot commit your configuration if you configure more than 20 CA profiles in a trusted CA group.

  1. Create a CA profile and associate a CA identifier to the profile.
  2. Define an IKE proposal and the IKE proposal authentication method.
  3. Define the Diffie-Hellman group, authentication algorithm, an encryption algorithm for the IKE proposal.
  4. Configure an IKE policy and associate the policy with the IKE proposal.
  5. Configure a local certificate identifier for the IKE policy.
  6. Define the CA to be used for the IKE policy.

To view the CA profiles and the trusted CA groups configured on your device, run show security pki command.

The show security ike command displays the CA profile group under the IKE policy named ike_policy and the certificate associated with the IKE policy.

Release History Table
Release
Description
Starting with Junos OS Release 18.1R1, validation of a configured IKE peer can be done with a specified CA server or group of CA servers.