Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Route-Based VPN with 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.

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 1 through Table 5 for specific configuration parameters used in this example.

Table 1: 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 2: 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 3: 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 4: 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 5: 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.

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

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.

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

    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.

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.

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.

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

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 29 shows a topology in which the SRX Series supports pico cell provisioning using the IKEv2 configuration payload feature.

Figure 1: 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

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

    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 6 shows the Phase 1 and Phase 2 options configured on the SRX Series, including information for establishing both OAM and 3GPP tunnels.

Table 6: 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.

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.

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.

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 in Junos OS Releases 12.3X48 and Junos OS releases prior to 15.1X49-D160, 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 15.X49-D161, 15.1X49-D170, 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 in Junos OS Releases 12.3X48 and Junos OS releases prior to 15.1X49-D160, 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 15.X49-D161, 15.1X49-D170, 17.3R3, 17.4R2, 18.1R3, 18.2R2, 18.3R1, and 18.1R3-S2:

    FreeRADIUS configuration example:

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

    Starting in Junos OS Release 20.1R1, you can configure a common password for IKEv2 configuration payload requests for an IKE gateway configuration. The common password in the range of 1 to 128 characters allows the administrator to define a common password. This password is used between the SRX Series device and the RADIUS server when the SRX Series device requesting an IP address on behalf of a remote IPsec peer using IKEv2 configuration payload. RADIUS server matches the credentials before it provides any IP information to the SRX Series device for the configuration payload request. You can configure the common password using config-payload-password configured-password configuration statement at [edit security ike gateway gateway-name aaa access-profile access-profile-name] hierarchy level. 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.

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

    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.

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.

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.

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.