AutoVPN on Hub-and-Spoke Devices

 

AutoVPN supports an IPsec VPN aggregator (known as a hub) that serves as a single termination point for multiple tunnels to remote sites (known as spokes). AutoVPN allows network administrators to configure a hub for current and future spokes.

Understanding AutoVPN

AutoVPN supports an IPsec VPN aggregator (known as a hub) that serves as a single termination point for multiple tunnels to remote sites (known as spokes). AutoVPN allows network administrators to configure a hub for current and future spokes. No configuration changes are required on the hub when spoke devices are added or deleted, thus allowing administrators flexibility in managing large-scale network deployments.

Secure Tunnel Modes

AutoVPN is supported on route-based IPsec VPNs. For route-based VPNs, you configure a secure tunnel (st0) interface and bind it to an IPsec VPN tunnel. st0 interfaces in AutoVPN networks can be configured in one of two modes:

  • Point-to-point mode—By default, an st0 interface configured at the [edit interfaces st0 unit x] hierarchy level is in point-to-point mode. Starting with Junos OS Release 17.4R1, IPv6 address is supported on AutoVPN.

  • Point-to-multipoint mode—In this mode, the multipoint option is configured at the [edit interfaces st0 unit x] hierarchy level on both AutoVPN hub and spokes. st0 interfaces on the hub and spokes must be numbered and the IP address configured on a spoke must exist in the hub's st0 interface subnetwork.

Table 1 compares AutoVPN point-to-point and point-to-multipoint secure tunnel interface modes.

Table 1: Comparison Between AutoVPN Point-to-Point and Point-to-Multipoint Secure Tunnel Modes

Point-to-Point Mode

Point-to-Multipoint Mode

Supports IKEv1 or IKEv2.

Supports IKEv1 or IKEv2.

Supports IPv4 and IPv6 traffic.

Supports IPv4 or IPv6.

Traffic selectors

Dynamic routing protocols (OSPF, OSPFv3 and iBGP)

Dead peer detection

Dead peer detection

Allows spoke devices to be SRX Series or third-party devices.

This mode is only supported with SRX Series devices.

Authentication

The supported authentication for AutoVPN hubs and spokes is X.509 public key infrastructure (PKI) certificates. The group IKE user type configured on the hub allows strings to be specified to match the alternate subject field in spoke certificates. Partial matches for the subject fields in spoke certificates can also be specified. See Understanding Spoke Authentication in AutoVPN Deployments.

Configuration and Management

AutoVPN is configured and managed on SRX Series devices using the CLI. Multiple AutoVPN hubs can be configured on a single SRX Series device. The maximum number of spokes supported by a configured hub is specific to the model of the SRX Series device.

Understanding AutoVPN Limitations

The following features are not supported for AutoVPN:

  • Policy-based VPNs are not supported.

  • The RIP dynamic routing protocol is not supported with AutoVPN tunnels.

  • Manual keys and Autokey IKE with preshared keys are not supported.

  • Configuring static next-hop tunnel binding (NHTB) on the hub for spokes is not supported.

  • Multicast is not supported.

  • The group IKE ID user type is not supported with an IP address as the IKE ID.

  • When the group IKE ID user type is used, the IKE ID should not overlap with other IKE gateways configured on the same external interface.

Understanding AutoVPN with Traffic Selectors

AutoVPN hubs can be configured with multiple traffic selectors to protect traffic to spokes. This feature provides the following benefits:

  • A single VPN configuration can support many different peers.

  • VPN peers can be non-SRX Series devices.

  • A single peer can establish multiple tunnels with the same VPN.

  • A larger number of tunnels can be supported than with AutoVPN with dynamic routing protocols.

Starting with Junos OS Release 17.4R1, AutoVPN networks that use secure tunnel interfaces in point-to-point mode support IPv6 addresses for traffic selectors and for IKE peers.

When the hub-to-spoke tunnel is established, the hub uses auto route insertion (ARI), known in previous releases as reverse route insertion (RRI), to insert the route to the spoke prefix in its routing table. The ARI route can then be imported to routing protocols and distributed to the core network.

AutoVPN with traffic selectors can be configured with the secure tunnel (st0) interface in point-to-point mode for both IKEv1 and IKEv2.

Note

Dynamic routing protocols are not supported on st0 interfaces when traffic selectors are configured.

Note the following caveats when configuring AutoVPN with traffic selectors:

  • Dynamic routing protocols are not supported with traffic selectors with st0 interfaces in point-to-point mode.

  • Auto Discovery VPN and IKEv2 configuration payload cannot be configured with AutoVPN with traffic selectors.

  • Spokes can be non-SRX Series devices; however, note the following differences:

    • In IKEv2, a non-SRX Series spoke can propose multiple traffic selectors in a single SA negotiation. This is not supported on SRX Series devices and the negotiation is rejected.

    • A non-SRX Series spoke can identify specific ports or protocols for traffic selector use. Ports and protocols are not supported with traffic selectors on SRX Series devices and the negotiation is rejected.

Understanding Spoke Authentication in AutoVPN Deployments

In AutoVPN deployments, the hub and spoke devices must have valid X.509 PKI certificates loaded. You can use the show security pki local-certificate detail command to display information about the certificates loaded in a device.

This topic covers the configuration on the hub that allows spokes to authenticate and connect to the hub:

Group IKE ID Configuration on the Hub

The group IKE ID feature allows a number of spoke devices to share an IKE configuration on the hub. The certificate holder’s identification, in the subject or alternate subject fields in each spoke’s X.509 certificate, must contain a part that is common to all spokes; the common part of the certificate identification is specified for the IKE configuration on the hub.

For example, the IKE ID example.net can be configured on the hub to identify spokes with the hostnames device1.example.net, device2.example.net, and device3.example.net. The certificate on each spoke must contain a hostname identity in the alternate subject field with example.net in the right-most part of the field; for example, device1.example.net. In this example, all spokes use this hostname identity in their IKE ID payload. During IKE negotiation, the IKE ID from a spoke is used to match the common part of the peer IKE identity configured on the hub. A valid certificate authenticates the spoke.

The common part of the certificate identification can be one of the following:

  • A partial hostname in the right-most part of the alternate subject field of the certificate, for example example.net.

  • A partial e-mail address in the right-most part of the alternate subject field of the certificate, for example @example.net.

  • A container string, a set of wildcards, or both to match the subject fields of the certificate. The subject fields contain details of the digital certificate holder in Abstract Syntax Notation One (ASN.1) distinguished name (DN) format. Fields can include organization, organizational unit, country, locality, or common name.

    To configure a group IKE ID to match subject fields in certificates, you can specify the following types of identity matches:

    • Container—The hub authenticates the spoke’s IKE ID if the subject fields of the spoke’s certificate exactly match the values configured on the hub. Multiple entries can be specified for each subject field (for example, ou=eng,ou=sw). The order of values in the fields must match.

    • Wildcard—The hub authenticates the spoke’s IKE ID if the subject fields of the spoke’s certificate match the values configured on the hub. The wildcard match supports only one value per field (for example, ou=eng or ou=sw but not ou=eng,ou=sw). The order of the fields is inconsequential.

The following example configures a group IKE ID with the partial hostname example.net in the alternate subject field of the certificate.

In this example, example.net is the common part of the hostname identification used for all spokes. All X.509 certificates on the spokes must contain a hostname identity in the alternate subject field with example.net in the right-most part. All spokes must use the hostname identity in their IKE ID payload.

The following example configures a group IKE ID with wildcards to match the values sales in the organizational unit and example in the organization subject fields of the certificate.

In this example, the fields ou=sales,o=example are the common part of the subject field in the certificates expected from the spokes. During IKE negotiation, if a spoke presents a certificate with the subject fields cn=alice,ou=sales,o=example in its certificate, authentication succeeds and the tunnel is established. If a spoke presents a certificate with the subject fields cn=thomas,ou=engineer,o=example in its certificate, the certificate is rejected by the hub as the organization unit should be sales.

Excluding a Spoke Connection

To exclude a particular spoke from connecting to the hub, the certificate for that spoke must be revoked. The hub needs to retrieve the latest certificate revocation list (CRL) from the CA that contains the serial number of the revoked certificate. The hub will then refuse a VPN connection from the revoked spoke. Until the latest CRL is available in the hub, the hub might continue to establish a tunnel from the revoked spoke. For more information, see Understanding Online Certificate Status Protocol and Certificate Revocation Lists and Understanding Certificate Authority Profiles.

AutoVPN Configuration Overview

The following steps describe the basic tasks for configuring AutoVPN on hub and spoke devices. The AutoVPN hub is configured once for all current and new spokes.

To configure the AutoVPN hub:

  1. Enroll a CA certificate and the local certificate in the device.
  2. Create a secure tunnel (st0) interface and configure it in point-to-multipoint mode.
  3. Configure a single IKE policy.
  4. Configure an IKE gateway with a group IKE ID that is common to all spokes.
  5. Configure a single IPsec policy and VPN.
  6. Configure a dynamic routing protocol.

To configure an SRX Series AutoVPN spoke device:

  1. Enroll a CA certificate and the local certificate in the device.
  2. Create an st0 interface and configure it in point-to-multipoint mode.
  3. Configure an IKE policy to match the IKE policy configured on the hub.
  4. Configure an IKE gateway with an ID to match the group IKE ID configured on the hub.
  5. Configure an IPsec policy to match the IPsec policy configured on the hub.
  6. Configure a dynamic routing protocol.

Example: Configuring Basic AutoVPN with iBGP

This example shows how to configure an AutoVPN hub to act as a single termination point, and then configure two spokes to act as tunnels to remote sites. This example configures iBGP to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series devices as AutoVPN hub and spokes

  • Junos OS Release 12.1X44-D10 and later that support AutoVPN

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels. For more information about specific requirements for a dynamic routing protocol, see the Routing Protocols Overview.

Overview

This example shows the configuration of an AutoVPN hub and the subsequent configurations of two spokes.

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). The certificates for the spokes contain the organizational unit (OU) value “SLT” in the subject field; the hub is configured with a group IKE ID to match the value “SLT” in the OU field.

The spokes establish IPsec VPN connections to the hub, which allows them to communicate with each other as well as access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and all spokes must have the same values. Table 2 shows the options used in this example.

Table 2: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

2

Authentication algorithm

SHA-1

Encryption algorithm

AES 128 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Authentication algorithm

HMAC MD5 96

Encryption algorithm

DES CBC

IPsec policy:

Perfect Forward Secrecy (PFS) group

14

The same certificate authority (CA) is configured on all devices.

Note

Junos OS only supports a single level of certificate hierarchy.

Table 3 shows the options configured on the hub and on all spokes.

Table 3: AutoVPN Configuration for Hub and All Spokes

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

1.1.1.1

Remote IKE ID

Distinguished name (DN) on the spoke’s certificate with the string SLT in the organizational unit (OU) field

DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

ge-0/0/1.0

Spoke 1: fe-0/0/1.0

Spoke 2: ge-0/0/1.0

VPN:

Bind interface

st0.0

st0.0

Establish tunnels

(not configured)

Immediately on configuration commit

Table 4 shows the configuration options that are different on each spoke.

Table 4: Comparison Between the Spoke Configurations

Option

Spoke 1

Spoke 2

st0.0 interface

10.10.10.2/24

10.10.10.3/24

Interface to internal network

(fe-0.0/4.0) 60.60.60.1/24

(fe-0.0/4.0) 70.70.70.1/24

Interface to Internet

(fe-0/0/1.0) 2.2.2.1/30

(ge-0/0/1.0) 3.3.3.1/30

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 1 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 1: Basic AutoVPN Deployment with iBGP
 Basic AutoVPN Deployment
with iBGP

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 2:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 2

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 2:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode, enter the show security ike security-associations command.

user@host> show security ike security-associations

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. Phase 1 proposal parameters must match on the hub and spokes.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the security ipsec security-associations command.

user@host> security ipsec security-associations

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spokes.

Verifying IPsec Next-Hop Tunnels

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spokes. The next hop should be associated with the correct IPsec VPN name.

Verifying BGP

Purpose

Verify that BGP references the IP addresses for the st0 interfaces of the spokes.

Action

From operational mode, enter the show bgp summary command.

user@host> show bgp summary

Verifying Learned Routes

Purpose

Verify that routes to the spokes have been learned.

Action

From operational mode, enter the show route 60.60.60.0 command.

user@host> show route 60.60.60.0

From operational mode, enter the show route 70.70.70.0 command.

user@host> show route 70.70.70.0

Example: Configuring Basic AutoVPN with iBGP for IPv6 Traffic

This example shows how to configure an AutoVPN hub to act as a single termination point, and then configure two spokes to act as tunnels to remote sites. This example configures AutoVPN for IPv6 environment using iBGP to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series devices as AutoVPN hub and spokes.

  • Junos OS Release 18.1R1 and later releases.

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels. For more information about specific requirements for a dynamic routing protocol, see the Routing Protocols Overview.

Overview

This example shows the configuration of an AutoVPN hub and the subsequent configurations of two spokes .

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). The certificates for the spokes contain the organizational unit (OU) value “SLT” in the subject field; the hub is configured with a group IKE ID to match the value “SLT” in the OU field.

The spokes establish IPsec VPN connections to the hub, which allows them to communicate with each other as well as access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and all spokes must have the same values. Table 5 shows the options used in this example.

Table 5: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

19

Authentication algorithm

SHA-384

Encryption algorithm

AES 256 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Lifetime Seconds

3000

Encryption algorithm

AES 256 GCM

IPsec policy:

Perfect Forward Secrecy (PFS) group

19

The same certificate authority (CA) is configured on all devices.

Note

Junos OS only supports a single level of certificate hierarchy.

Table 6 shows the options configured on the hub and on all spokes.

Table 6: AutoVPN Configuration for Hub and All Spokes

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

2001:db8:2000::1

Remote IKE ID

Distinguished name (DN) on the spoke’s certificate with the string SLT in the organizational unit (OU) field

DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

ge-0/0/0

Spoke 1: ge-0/0/0.0

Spoke 2: ge-0/0/0.0

VPN:

Bind interface

st0.1

st0.1

Establish tunnels

(not configured)

establish-tunnels on-traffic

Table 7 shows the configuration options that are different on each spoke.

Table 7: Comparison Between the Spoke Configurations

Option

Spoke 1

Spoke 2

st0.0 interface

2001:db8:7000::2/64

2001:db8:7000::3/64

Interface to internal network

(ge-0/0/1.0) 2001:db8:4000::1/64

(ge-0/0/1.0) 2001:db8:6000::1/64

Interface to Internet

(ge-0/0/0.0) 2001:db8:3000::2/64

(ge-0/0/0.0) 2001:db8:5000::2/64

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 2 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 2: Basic AutoVPN Deployment with iBGP
 Basic AutoVPN Deployment
with iBGP

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 2:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 2

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 2:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Status

Purpose

Verify the IKE status.

Action

From operational mode, enter the show security ike sa command.

user@host> show security ike sa

Meaning

The show security ike sa 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. Phase 1 proposal parameters must match on the hub and spokes.

Verifying IPsec Status

Purpose

Verify the IPsec status.

Action

From operational mode, enter the show security ipsec sa command.

user@host> show security ipsec sa

Meaning

The show security ipsec sa command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spokes.

Verifying IPsec Next-Hop Tunnels

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spokes. The next hop should be associated with the correct IPsec VPN name.

Verifying BGP

Purpose

Verify that BGP references the IP addresses for the st0 interfaces of the spokes.

Action

From operational mode, enter the show bgp summary command.

user@host> show bgp summary

Example: Configuring AutoVPN with iBGP and ECMP

This example shows how to configure two IPsec VPN tunnels between an AutoVPN hub and spoke. This example configures iBGP with equal-cost multipath (ECMP) to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Two supported SRX Series devices as AutoVPN hub and spoke

  • Junos OS Release 12.1X44-D10 and later that support AutoVPN

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels.

Overview

This example shows the configuration of an AutoVPN hub and a spoke with two IPsec VPN tunnels.

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). Certificates are enrolled in the hub and in the spoke for each IPsec VPN tunnel. One of the certificates for the spoke contains the organizational unit (OU) value “SLT” in the distinguished name (DN); the hub is configured with a group IKE ID to match the value “SLT” in the OU field. The other certificate for the spoke contains the OU value “SBU” in the DN; the hub is configured with a group IKE ID to match the value “SBU” in the OU field.

The spoke establishes IPsec VPN connections to the hub, which allows it to access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and the spoke must have the same values.Table 8 shows the options used in this example.

Table 8: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke iBGP ECMP Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

2

Authentication algorithm

SHA-1

Encryption algorithm

AES 128 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Authentication algorithm

HMAC MD5 96

Encryption algorithm

DES CBC

IPsec policy:

Perfect Forward Secrecy (PFS) group

14

The same certificate authority (CA) is configured on all devices.

Note

Junos OS only supports a single level of certificate hierarchy.

Table 9 shows the options configured on the hub and on the spoke.

Table 9: AutoVPN iBGP ECMP Configuration for Hub and Spoke 1

Option

Hub

Spoke 1

IKE gateway:

Remote IP address

hub-to-spoke-gw-1: Dynamic

hub-to-spoke-gw-2: Dynamic

spoke-to-hub-gw-1: 1.1.1.1

spoke-to-hub-gw-2: 1.1.2.1

Remote IKE ID

hub-to-spoke-gw-1: DN on the spoke’s certificate with the string SLT in the OU field

hub-to-spoke-gw-2: DN on the spoke’s certificate with the string SBU in the OU field

spoke-to-hub-gw-1: DN on the hub’s certificate

spoke-to-hub-gw-2: DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

hub-to-spoke-gw-1: ge-0/0/1.0

hub-to-spoke-gw-2: ge-0/0/2.0

spoke-to-hub-gw-1: fe-0/0/1.0

spoke-to-hub-gw-2: fe-0/0/2.0

VPN:

Bind interface

hub-to-spoke-vpn-1: st0.0

hub-to-spoke-vpn-2: st0.1

spoke-to-hub-1: st0.0

spoke-to-hub-2: st0.1

Establish tunnels

(not configured)

Immediately on configuration commit

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 3 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 3: AutoVPN Deployment with iBGP and ECMP
 AutoVPN Deployment with iBGP
and ECMP

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair for each certificate.
  4. Enroll the local certificates.
  5. Verify the local certificates.
    user@host> show security pki local-certificate certificate-id Local1 detail
    user@host> show security pki local-certificate certificate-id Local2 detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair for each certificate.
  4. Enroll the local certificates.
  5. Verify the local certificates.
    user@host> show security pki local-certificate certificate-id Local1 detail
    user@host> show security pki local-certificate certificate-id Local2 detail
    Note

    The organizational unit (OU) shown in the subject field is SLT for Local1 and SBU for Local2. The IKE configurations on the hub include OU=SLT and OU=SBU to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode, enter the show security ike security-associations command.

user@host> show security ike security-associations

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. Phase 1 proposal parameters must match on the hub and spoke.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the security ipsec security-associations command.

user@host> security ipsec security-associations

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spoke.

Verifying IPsec Next-Hop Tunnels

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spokes. The next hop should be associated with the correct IPsec VPN name.

Verifying BGP

Purpose

Verify that BGP references the IP addresses for the st0 interfaces of the spoke.

Action

From operational mode, enter the show bgp summary command.

user@host> show bgp summary

Verifying Learned Routes

Purpose

Verify that routes to the spoke have been learned.

Action

From operational mode, enter the show route 60.60.60.0 detail command.

user@host> show route 60.60.60.0 detail

Verifying Route Installation in Forwarding Table

Purpose

Verify that routes to the spoke have been installed in the forwarding table.

Action

From operational mode, enter the show route forwarding-table matching 60.60.60.0 command.

user@host> show route forwarding-table matching 60.60.60.0

Example: Configuring AutoVPN with iBGP and Active-Backup Tunnels

This example shows how to configure active and backup IPsec VPN tunnels between an AutoVPN hub and spoke. This example configures iBGP to forward traffic through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Two supported SRX Series devices as AutoVPN hub and spoke

  • Junos OS Release 12.1X44-D10 and later that support AutoVPN

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels.

Overview

This example shows the configuration of an AutoVPN hub and a spoke with two IPsec VPN tunnels.

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). Certificates are enrolled in the hub and in the spoke for each IPsec VPN tunnel. One of the certificates for the spoke contains the organizational unit (OU) value “SLT” in the distinguished name (DN); the hub is configured with a group IKE ID to match the value “SLT” in the OU field. The other certificate for the spoke contains the OU value “SBU” in the DN; the hub is configured with a group IKE ID to match the value “SBU” in the OU field.

The spoke establishes IPsec VPN connections to the hub, which allows it to access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and the spoke must have the same values. Table 10 shows the options used in this example.

Table 10: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke iBGP Active-Backup Tunnel Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

2

Authentication algorithm

SHA-1

Encryption algorithm

AES 128 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Authentication algorithm

HMAC MD5 96

Encryption algorithm

DES CBC

IPsec policy:

Perfect Forward Secrecy (PFS) group

14

The same certificate authority (CA) is configured on all devices.

Note

Junos OS only supports a single level of certificate hierarchy.

Table 11 shows the options configured on the hub and on the spoke.

Table 11: AutoVPN IBGP Active-Backup Tunnel Configuration for Hub and Spoke 1

Option

Hub

Spoke 1

IKE gateway:

Remote IP address

hub-to-spoke-gw-1: Dynamic

hub-to-spoke-gw-2: Dynamic

spoke-to-hub-gw-1: 1.1.1.1

spoke-to-hub-gw-2: 1.1.2.1

Remote IKE ID

hub-to-spoke-gw-1: DN on the spoke’s certificate with the string SLT in the OU field

hub-to-spoke-gw-2: DN on the spoke’s certificate with the string SBU in the OU field

spoke-to-hub-gw-1: DN on the hub’s certificate

spoke-to-hub-gw-2: DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

hub-to-spoke-gw-1: ge-0/0/1.0

hub-to-spoke-gw-2: ge-0/0/2.0

spoke-to-hub-gw-1: fe-0/0/1.0

spoke-to-hub-gw-2: fe-0/0/2.0

VPN:

Bind interface

hub-to-spoke-vpn-1: st0.0

hub-to-spoke-vpn-2: st0.1

spoke-to-hub-1: st0.0

spoke-to-hub-2: st0.1

VPN monitor

hub-to-spoke-vpn-1: ge-0/0/1.0 (source interface)

hub-to-spoke-vpn-2: ge-0/0/2.0 (source interface)

spoke-to-hub-1: 1.1.1.1 (destination IP)

spoke-to-hub-2: 1.1.2.1 (destination IP)

Establish tunnels

(not configured)

Immediately on configuration commit

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 4 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 4: AutoVPN Deployment with iBGP and Active-Backup Tunnels
 AutoVPN Deployment
with iBGP and Active-Backup Tunnels

In this example, two IPsec VPN tunnels are established between the hub and spoke 1. Routing information is exchanged through iBGP sessions in each tunnel. The longest prefix match for the route to 60.60.60.0/24 is through the st0.0 interface on the hub. Thus, the primary tunnel for the route is through the st0.0 interfaces on the hub and spoke 1. The default route is through the backup tunnel on the st0.1 interfaces on the hub and spoke 1.

VPN monitoring checks the status of the tunnels. If there is a problem with the primary tunnel (for example, the remote tunnel gateway is not reachable), the tunnel status changes to down and data destined for 60.60.60.0/24 is rerouted through the backup tunnel.

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair for each certificate.
  4. Enroll the local certificates.
  5. Verify the local certificates.
    user@host> show security pki local-certificate certificate-id Local1 detail
    user@host> show security pki local-certificate certificate-id Local2 detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair for each certificate.
  4. Enroll the local certificates.
  5. Verify the local certificates.
    user@host> show security pki local-certificate certificate-id Local1 detail
    user@host> show security pki local-certificate certificate-id Local2 detail
    Note

    The organizational unit (OU) shown in the subject field is SLT for Local1 and SBU for Local2. The IKE configurations on the hub include OU=SLT and OU=SBU to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Phase 1 Status (Both Tunnels Are Up)

Purpose

Verify the IKE Phase 1 status when both IPSec VPN tunnels are up.

Action

From operational mode, enter the show security ike security-associations command.

user@host> show security ike security-associations

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. Phase 1 proposal parameters must match on the hub and spoke.

Verifying IPsec Phase 2 Status (Both Tunnels Are Up)

Purpose

Verify the IPsec Phase 2 status when both IPsec VPN tunnels are up.

Action

From operational mode, enter the security ipsec security-associations command.

user@host> security ipsec security-associations

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spoke.

Verifying IPsec Next-Hop Tunnels (Both Tunnels Are Up)

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spoke. The next hop should be associated with the correct IPsec VPN name.

Verifying BGP (Both Tunnels Are Up)

Purpose

Verify that BGP references the IP addresses for the st0 interfaces of the spoke when both IPsec VPN tunnels are up.

Action

From operational mode, enter the show bgp summary command.

user@host> show bgp summary

Verifying Learned Routes (Both Tunnels Are Up)

Purpose

Verify that routes to the spoke have been learned when both tunnels are up. The route to 60.60.60.0/24 is through the st0.0 interface and the default route is through the st0.1 interface.

Action

From operational mode, enter the show route 60.60.60.0 command.

user@host> show route 60.60.60.0

From operational mode, enter the show route 0.0.0.0 command.

user@host> show route 0.0.0.0

Verifying IKE Phase 1 Status (Primary Tunnel Is Down)

Purpose

Verify the IKE Phase 1 status when the primary tunnel is down.

Action

From operational mode, enter the show security ike security-associations command.

user@host> show security ike security-associations

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. Phase 1 proposal parameters must match on the hub and spoke.

Verifying IPsec Phase 2 Status (Primary Tunnel Is Down)

Purpose

Verify the IPsec Phase 2 status when the primary tunnel is down.

Action

From operational mode, enter the security ipsec security-associations command.

user@host> security ipsec security-associations

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spoke.

Verifying IPsec Next-Hop Tunnels (Primary Tunnel Is Down)

Purpose

Verify the IPsec next-hop tunnel.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spoke. The next hop should be associated with the correct IPsec VPN name, in this case the backup VPN tunnel.

Verifying BGP (Primary Tunnel Is Down)

Purpose

Verify that BGP references the IP addresses for the st0 interfaces of the spoke when the primary tunnel is down.

Action

From operational mode, enter the show bgp summary command.

user@host> show bgp summary

Verifying Learned Routes (Primary Tunnel Is Down)

Purpose

Verify that routes to the spoke have been learned when the primary tunnel is down. Both the route to 60.60.60.0/24 and the default route are through the st0.1 interface.

Action

From operational mode, enter the show route 60.60.60.0 command.

user@host> show route 60.60.60.0

From operational mode, enter the show route 0.0.0.0 command.

user@host> show route 0.0.0.0

Example: Configuring Basic AutoVPN with OSPF

This example shows how to configure an AutoVPN hub to act as a single termination point, and then configure two spokes to act as tunnels to remote sites. This example configures OSPF to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series devices as AutoVPN hub and spokes

  • Junos OS Release 12.1X44-D10 and later that support AutoVPN

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels.

Overview

This example shows the configuration of an AutoVPN hub and the subsequent configurations of two spokes.

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). The certificates for the spokes contain the organizational unit (OU) value “SLT” in the subject field; the hub is configured with a group IKE ID to match the value “SLT” in the OU field.

The spokes establish IPsec VPN connections to the hub, which allows them to communicate with each other as well as access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and all spokes must have the same values. Table 12 shows the options used in this example.

Table 12: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke Basic OSPF Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

2

Authentication algorithm

SHA-1

Encryption algorithm

AES 128 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Authentication algorithm

HMAC MD5 96

Encryption algorithm

DES CBC

IPsec policy:

Perfect Forward Secrecy (PFS) group

14

The same certificate authority (CA) is configured on all devices.

Note

Junos OS only supports a single level of certificate hierarchy.

Table 13 shows the options configured on the hub and on all spokes.

Table 13: AutoVPN Basic OSPF Configuration for Hub and All Spokes

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

1.1.1.1

Remote IKE ID

Distinguished name (DN) on the spoke’s certificate with the string SLT in the organizational unit (OU) field

DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

ge-0/0/1.0

Spoke 1: fe-0/0/1.0

Spoke 2: ge-0/0/1.0

VPN:

Bind interface

st0.0

st0.0

Establish tunnels

(not configured)

Immediately on configuration commit

Table 14 shows the configuration options that are different on each spoke.

Table 14: Comparison Between the Basic OSPF Spoke Configurations

Option

Spoke 1

Spoke 2

st0.0 interface

10.10.10.2/24

10.10.10.3/24

Interface to internal network

fe-0.0/4.0: 60.60.60.1/24

fe-0.0/4.0: 70.70.70.1/24

Interface to Internet

fe-0/0/1.0: 2.2.2.1/30

ge-0/0/1.0: 3.3.3.1/30

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 5 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 5: Basic AutoVPN Deployment with OSPF
 Basic AutoVPN Deployment
with OSPF

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 2:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 2

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 2:

  1. Configure interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode, enter the show security ike security-associations command.

user@host> show security ike security-associations

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. Phase 1 proposal parameters must match on the hub and spokes.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the security ipsec security-associations command.

user@host> security ipsec security-associations

Meaning

The show security ipsec security-associations command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spokes.

Verifying IPsec Next-Hop Tunnels

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spokes. The next hop should be associated with the correct IPsec VPN name.

Verifying OSPF

Purpose

Verify that OSPF references the IP addresses for the st0 interfaces of the spokes.

Action

From operational mode, enter the show ospf neighbor command.

user@host> show ospf neighbor

Verifying Learned Routes

Purpose

Verify that routes to the spokes have been learned.

Action

From operational mode, enter the show route 60.60.60.0 command.

user@host> show route 60.60.60.0

From operational mode, enter the show route 70.70.70.0 command.

user@host> show route 70.70.70.0

Example: Configuring AutoVPN with OSPFv3 for IPv6 Traffic

This example shows how to configure an AutoVPN hub to act as a single termination point, and then configure two spokes to act as tunnels to remote sites. This example configures AutoVPN for IPv6 environment using OSPFv3 to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series devices as AutoVPN hub and spokes.

  • Junos OS Release 18.1R1 and later releases.

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.

Note

You should be familiar with the dynamic routing protocol that is used to forward packets through the VPN tunnels.

Overview

This example shows the configuration of an AutoVPN with OSPFv3 routing protocol on hub and the subsequent configurations of two spokes.

In this example, the first step is to enroll digital certificates in each device using the Simple Certificate Enrollment Protocol (SCEP). The certificates for the spokes contain the organizational unit (OU) value “SLT” in the subject field; the hub is configured with a group IKE ID to match the value “SLT” in the OU field.

The spokes establish IPsec VPN connections to the hub, which allows them to communicate with each other as well as access resources on the hub. Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hub and all spokes must have the same values. Table 15 shows the options used in this example.

Table 15: Phase 1 and Phase 2 Options for AutoVPN Hub and Spoke Basic OSPFv3 Configurations

Option

Value

IKE proposal:

Authentication method

RSA digital certificates

Diffie-Hellman (DH) group

19

Authentication algorithm

SHA-384

Encryption algorithm

AES 256 CBC

IKE policy:

Mode

Main

IPsec proposal:

Protocol

ESP

Lifetime seconds

3000

Encryption algorithm

AES 256 GCM

IPsec policy:

Perfect Forward Secrecy (PFS) group

19

The same certificate authority (CA) is configured on all devices.

Table 16 shows the options configured on the hub and on all spokes.

Table 16: AutoVPN OSPFv3 Configuration for Hub and All Spokes

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

2001:db8:2000::1

Remote IKE ID

Distinguished name (DN) on the spoke’s certificate with the string SLT in the organizational unit (OU) field

DN on the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spoke’s certificate

External interface

ge-0/0/0

Spoke 1: ge-0/0/0.0

Spoke 2: ge-0/0/0.0

VPN:

Bind interface

st0.1

st0.1

Establish tunnels

(not configured)

Immediately on configuration commit

Table 17 shows the configuration options that are different on each spoke.

Table 17: Comparison Between the OSPFv3 Spoke Configurations

Option

Spoke 1

Spoke 2

st0.1 interface

2001:db8:7000::2/64

2001:db8:7000::3/64

Interface to internal network

(ge-0/0/1.0) 2001:db8:4000::1/64

(ge-0/0/1.0) 2001:db8:6000::1/64

Interface to Internet

(ge-0/0/0.0) 2001:db8:3000::2/64

(ge-0/0/0.0) 2001:db8:5000::2/64

Routing information for all devices is exchanged through the VPN tunnels.

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.

Topology

Figure 6 shows the SRX Series devices to be configured for AutoVPN in this example.

Figure 6: Basic AutoVPN Deployment with OSPFv3
 Basic AutoVPN Deployment
with OSPFv3

Configuration

To configure AutoVPN, perform these tasks:

Note

The first section describes how to obtain CA and local certificates online using the Simple Certificate Enrollment Protocol (SCEP) on the hub and spoke devices.

Enroll Device Certificates with SCEP

Step-by-Step Procedure

To enroll digital certificates with SCEP on the hub:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 1:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Step-by-Step Procedure

To enroll digital certificates with SCEP on spoke 2:

  1. Configure the CA.
  2. Enroll the CA certificate.

    Type yes at the prompt to load the CA certificate.

  3. Generate a key pair.
  4. Enroll the local certificate.
  5. Verify the local certificate.
    user@host> show security pki local-certificate detail
    Note

    The organizational unit (OU) shown in the subject field is SLT. The IKE configuration on the hub includes ou=SLT to identify the spoke.

Configuring the Hub

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

  1. Configure the interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 1

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 1:

  1. Configure interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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 Spoke 2

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, 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 spoke 2:

  1. Configure interfaces.
  2. Configure the routing protocol.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.
  5. Configure zones.
  6. Configure the default security policy.
  7. Configure the CA profile.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show security ike, show security ipsec, show security zones, show security policies, and show security pki 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

Confirm that the configuration is working properly.

Verifying IKE Status

Purpose

Verify the IKE status.

Action

From operational mode, enter the show security ike sa command.

user@host> show security ike sa

Meaning

The show security ike sa 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. Phase 1 proposal parameters must match on the hub and spokes.

Verifying IPsec Status

Purpose

Verify the IPsec status.

Action

From operational mode, enter the show security ipsec sa command.

user@host> show security ipsec sa

Meaning

The show security ipsec sa command lists all active IKE Phase 2 SAs. If no SAs are listed, there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spokes.

Verifying IPsec Next-Hop Tunnels

Purpose

Verify the IPsec next-hop tunnels.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

user@host> show security ipsec next-hop-tunnels

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of the spokes. The next hop should be associated with the correct IPsec VPN name.

Verifying OSPFv3

Purpose

Verify that OSPFv3 references the IP addresses for the st0 interfaces of the spokes.

Action

From operational mode, enter the show ospf3 neighbor detail command.

Hub:

user@host> show ospf3 neighbor detail

Spoke 1:

user@host> show ospf3 neighbor detail

Spoke 2:

user@host> show ospf3 neighbor detail

Example: Forwarding Traffic Through an AutoVPN Tunnel with Traffic Selectors

This example shows how to configure traffic selectors, instead of dynamic routing protocols, to forward packets through a VPN tunnel in an AutoVPN deployment. When traffic selectors are configured, the secure tunnel (st0) interface must be in point-to-point mode. Traffic selectors are configured on both the hub and spoke devices.

Requirements

This example uses the following hardware and software components:

  • Two SRX Series devices connected and configured in a chassis cluster. The chassis cluster is the AutoVPN hub.

  • An SRX Series device configured as an AutoVPN spoke.

  • Junos OS Release 12.3X48-D10 or later.

  • Digital certificates enrolled in the hub and the spoke devices that allow the devices to authenticate each other.

Before you begin:

Overview

In this example, traffic selectors are configured on the AutoVPN hub and spoke. Only traffic that conforms to the configured traffic selector is forwarded through the tunnel. On the hub, the traffic selector is configured with the local IP address 192.0.0.0/8 and the remote IP address 172.0.0.0/8. On the spoke, the traffic selector is configured with the local IP address 172.0.0.0/8 and the remote IP address 192.0.0.0/8.

Note

The traffic selector IP addresses configured on the spoke can be a subset of the traffic selector IP addresses configured on the hub. This is known as traffic selector flexible match.

Certain Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hubs and spokes must have the same values. Table 18 shows the values used in this example:

Table 18: Phase 1 and Phase 2 Options for AutoVPN Hubs and Spokes with Traffic Selectors

Option

Value

IKE proposal:

Authentication method

rsa-signatures

Diffie-Hellman (DH) group

group5

Authentication algorithm

sha-1

Encryption algorithm

aes-256-cbc

IKE policy:

Mode

main

Certificate

local-certificate

IKE gateway:

Dynamic

distinguished name wildcard DC=Common_component

IKE user type

group IKE id

Local identity

distinguished name

Version

v1-only

IPsec proposal:

Protocol

esp

Authentication algorithm

hmac-sha1-96

Encryption algorithm

aes-192-cbc

Lifetime

3600 seconds

150,000 kilobytes

IPsec policy:

Perfect Forward Secrecy (PFS) group

group5

Topology

Figure 7 shows the SRX Series devices to be configured for this example.

Figure 7: AutoVPN with Traffic Selectors
 AutoVPN with
Traffic Selectors

Configuration

Configuring the Hub

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.

Starting with Junos OS Release 15.1X49-D120, you can configure the CLI option reject-duplicate-connection at the [edit security ike gateway gateway-name dynamic] hierarchy level to retain an existing tunnel session and reject negotiation requests for a new tunnel with the same IKE ID. By default, an existing tunnel is tear down when a new tunnel with the same IKE ID is established. The reject-duplicate-connection option is only supported when ike-user-type group-ike-id or ike-user-type shared-ike-id is configured for the IKE gateway; the aaa access-profile profile-name configuration is not supported with this option.

Note

Use the CLI option reject-duplicate-connection only when you are certain that reestablishment of a new tunnel with the same IKE ID should be rejected.

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 the hub:

  1. Configure interfaces.
  2. Configure Phase 1 options.
  3. Configure Phase 2 options.
  4. Configure certificate information.
  5. Configure security zones.

Results

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

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

Configuring the Spoke

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 the hub:

  1. Configure interfaces.
  2. Configure Phase 1 options.
  3. Configure Phase 2 options.
  4. Configure certificate information.
  5. Configure security zones.

Results

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

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

Verification

Confirm that the configuration is working properly.

Verifying Tunnels

Purpose

Verify that tunnels are established between the AutoVPN hub and spoke.

Action

From operational mode, enter the show security ike security-associations and show security ipsec security-associations commands on the hub.

user@host> show security ike security-associations
user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

From operational mode, enter the show security ike security-associations and show security ipsec security-associations commands on the spoke.

user@host> show security ike security-associations
user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs. The show security ipsec security-associations command lists all active IKE Phase 2 SAs. The hub shows one active tunnel to the spoke while the spoke shows one active tunnel to the hub.

If no SAs are listed for IKE Phase 1, then there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 1 proposal parameters must match on the hub and spoke.

If no SAs are listed for IKE Phase 2, then there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and spoke.

Verifying Traffic Selectors

Purpose

Verify the traffic selectors.

Action

From operational mode, enter the show security ipsec traffic-selector interface-name st0.1 command on the hub.

user@host> show security ipsec traffic-selector interface-name st0.1

From operational mode, enter the show security ipsec traffic-selector interface-name st0.1 command on the spoke.

user@host> show security ipsec traffic-selector interface-name st0.1

Meaning

A traffic selector is an agreement between IKE peers to permit traffic through a tunnel if the traffic matches a specified pair of local and remote addresses. Only traffic that conforms to a traffic selector is permitted through an SA. Traffic selectors are negotiated between the initiator and the responder (the SRX Series hub).

Example: Ensuring VPN Tunnel Availability with AutoVPN and Traffic Selectors

Georedundancy is the deployment of multiple geographically distant sites so that traffic can continue to flow over a provider network even if there is a power outage, a natural disaster, or other catastrophic event that affects a site. In a mobile provider network, multiple Evolved Node B (eNodeB) devices can be connected to the core network through georedundant IPsec VPN gateways on SRX Series devices. The alternate routes to the eNodeB devices are distributed to the core network using a dynamic routing protocol.

This example configures AutoVPN hubs with multiple traffic selectors on SRX Series devices to ensure that there are georedundant IPsec VPN gateways to eNodeB devices. Auto route insertion (ARI) is used to automatically insert routes toward the eNodeB devices in the routing tables on the hubs. ARI routes are then distributed to the provider’s core network through BGP.

Requirements

This example uses the following hardware and software components:

  • Two SRX Series devices connected and configured in a chassis cluster. The chassis cluster is AutoVPN hub A.

  • An SRX Series device configured as AutoVPN hub B.

  • Junos OS Release 12.3X48-D10 or later.

  • eNodeB devices that can establish IPsec VPN tunnels with AutoVPN hubs. eNodeB devices are third-party network equipment providers that initiate a VPN tunnel with AutoVPN hubs.

  • Digital certificates enrolled in the hubs and the eNodeB devices that allow the devices to authenticate each other.

Before you begin:

Note

This example uses the BGP dynamic routing protocol to advertise routes toward the eNodeB devices to the core network.

Overview

In this example, two AutoVPN hubs are configured with multiple traffic selectors on SRX Series devices to provide georedundant IPsec VPN gateways to eNodeB devices. ARI automatically inserts routes to the eNodeB devices in the routing tables on the hubs. ARI routes are then distributed to the provider’s core network through BGP.

Certain Phase 1 and Phase 2 IKE tunnel options configured on the AutoVPN hubs and eNodeB devices must have the same values. Table 19 shows the values used in this example:

Table 19: Phase 1 and Phase 2 Options for Georedundant AutoVPN Hubs

Option

Value

IKE proposal:

Authentication method

rsa-signatures

Diffie-Hellman (DH) group

group5

Authentication algorithm

sha-1

Encryption algorithm

aes-256-cbc

IKE policy:

Certificate

local-certificate

IKE gateway:

Dynamic

distinguished name wildcard DC=Common_component

IKE user type

group IKE id

Dead peer detection

probe-idle-tunnel

Local identity

distinguished name

Version

v2-only

IPsec proposal:

Protocol

esp

Authentication algorithm

hmac-sha1-96

Encryption algorithm

aes-256-cbc

IPsec policy:

Perfect Forward Secrecy (PFS) group

group5

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. For simplicity, the configuration on the SRX Series devices allows all types of inbound traffic; this configuration is not recommended for production deployments.

Topology

Figure 8 shows the SRX Series devices to be configured for this example.

Figure 8: Georedundant IPsec VPN Gateways to eNodeB Devices
 Georedundant
IPsec VPN Gateways to eNodeB Devices

Configuration

Configuring Hub A

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 hub A:

  1. Configure interfaces.
  2. Configure Phase 1 options.
  3. Configure Phase 2 options.
  4. Configure the BGP routing protocol.
  5. Configure routing options.
  6. Configure certificate information.
  7. Configure security zones.

Results

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

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

Configuring Hub B

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 hub B:

  1. Configure interfaces.
  2. Configure Phase 1 options.
  3. Configure Phase 2 options.
  4. Configure the BGP routing protocol.
  5. Configure routing options.
  6. Configure certificate information.
  7. Configure security zones.

Results

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

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

Configuring the eNodeB (Sample Configuration)

Step-by-Step Procedure

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

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

  • SRX Series IKE identity information and public IP address

  • Phase 1 and Phase 2 proposals that match the configurations on the SRX Series hubs

Results

The eNodeB devices in this example use strongSwan open source software for IPsec-based VPN connections:

Verification

Confirm that the configuration is working properly.

Verifying Tunnels on the AutoVPN Hubs

Purpose

Verify that tunnels are established between the AutoVPN hub and eNodeB devices.

Action

From operational mode, enter the show security ike security-associations and show security ipsec security-associations commands on the hub.

user@host> show security ike security-associations
user@host> show security ipsec security-associations

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs. The show security ipsec security-associations command lists all active IKE Phase 2 SAs. The hub shows two active tunnels, one to each eNodeB device.

If no SAs are listed for IKE Phase 1, then there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 1 proposal parameters must match on the hub and eNodeB devices.

If no SAs are listed for IKE Phase 2, then there was a problem with Phase 2 establishment. Check the IKE policy parameters and external interface settings in your configuration. Phase 2 proposal parameters must match on the hub and eNodeB devices.

Verifying Traffic Selectors

Purpose

Verify the traffic selectors.

Action

From operational mode, enter the show security ipsec traffic-selector interface-name st0.1 command.

user@host> show security ipsec traffic-selector interface-name st0.1

Meaning

A traffic selector is an agreement between IKE peers to permit traffic through a tunnel if the traffic matches a specified pair of local and remote addresses. Only traffic that conforms to a traffic selector is permitted through an SA. Traffic selectors are negotiated between the initiator and the responder (the SRX Series hub).

Verifying ARI Routes

Purpose

Verify that the ARI routes are added to the routing table.

Action

From operational mode, enter the show route command.

user@host> show route

Meaning

Auto route insertion (ARI) automatically inserts a static route for the remote network and hosts protected by a remote tunnel endpoint. A route is created based on the remote IP address configured in the traffic selector. In the case of traffic selectors, the configured remote address is inserted as a route in the routing instance associated with the st0 interface that is bound to the VPN.

Static routes to the eNodeB destinations 30.1.1.0/24 and 50.1.1.0/24 are added to the routing table on the SRX Series hub. These routes are reachable through the st0.1 interface.

Related Documentation

Release History Table
Release
Description
Starting with Junos OS Release 17.4R1, IPv6 address is supported on AutoVPN.
Starting with Junos OS Release 17.4R1, AutoVPN networks that use secure tunnel interfaces in point-to-point mode support IPv6 addresses for traffic selectors and for IKE peers.
Starting with Junos OS Release 15.1X49-D120, you can configure the CLI option reject-duplicate-connection at the [edit security ike gateway gateway-name dynamic] hierarchy level to retain an existing tunnel session and reject negotiation requests for a new tunnel with the same IKE ID.