Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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, a 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 Firewalls.

Authentication

AutoVPNs support both certificate and preshared key based authentication methods.

For certificate based authentication in AutoVPN hubs and spokes, you can use 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.

Starting in Junos OS Release 21.2R1, SRX5000 line with SPC3 card and vSRX Virtual Firewall running iked process supports AutoVPN with seeded preshared key.

Note:

The SRX5000 line with the SPC3 card and vSRX Virtual Firewall supports AutoVPN with PSK, only if you install the junos-ike package.

We support AutoVPN with the following two options:

  • AutoVPN seeded PSK: Multiple peers connecting to same gateway having different pre-shared key.
  • AutoVPN shared PSK: Multiple peers connecting to same gateway having same pre-shared key.

Seeded PSK is different from non-seeded PSK (that is, same shared PSK). Seeded PSK uses master key to generate the shared PSK for the peer. So each peer will have different PSK connecting to the same gateway. For example: Consider a scenario where peer 1 with the IKE ID user1@juniper.net and peer 2 with IKE ID user2@juniper.net attempts to connect to gateway. In this scenario the gateway that is configured as HUB_GW containing the master key configured as ThisIsMySecretPreSharedkey will have the different PSK as follows:

Peer 1 : 79e4ea39f5c06834a3c4c031e37c6de24d46798a

Peer 2: 3db8385746f3d1e639435a882579a9f28464e5c7

This means, for different users with different user id and same master key will generate a different or unique preshared key.

You can use either seeded-pre-shared-key or pre-shared-key for Auto-VPN PSK:

  • Different preshared key: If the seeded-pre-shared-key is set, different IKE preshared key is used by the VPN gateway to authenticate each remote peer. The peer preshared keys are generated using the master-key set in the IKE gateway and shared across the peers.

    To enable the VPN gateway to use a different IKE preshared key (PSK) for authenticating each remote peer, use the new CLI commands seeded-pre-shared-key ascii-text or seeded-pre-shared-key hexadecimal under the [edit security ike policy policy_name] hierarchy level.

    This command is mutually exclusive with pre-shared-key command under the same hierarchy.

    See policy.

  • Shared/Same preshared key: If pre-shared-key-type is not configured, then the PSK is considered to be shared. Same IKE preshared key is used by the VPN gateway to authenticate all remote peers.

    To enable the VPN gateway to use the same IKE PSK for authenticating all remote peers, use the existing CLI commands pre-sharedkey ascii-text or pre-shared-key hexadecimal.

At the VPN gateway, you can bypass the IKE ID validation using the general-ikeid configuration statement under the [edit security ike gateway gateway_name dynamic] hierarchy level. If this option is configured, then during authentication of remote peer, the VPN gateway allows any remote IKE ID connection. See general-ikeid.

The SRX5000 line with SPC3 card and vSRX Virtual Firewall running iked process (with the junos-ike package) supports the following IKE modes:

Table 2: AutoVPN PSK Support

IKE Mode

SRX5000 line with SPC3 Card and vSRX Virtual Firewall running iked process

Shared PSK

Seeded-PSK

IKEv2

Yes

Yes

IKEv2 with any-remote-id

Yes

Yes

IKEv1 Aggressive Mode

Yes

Yes

IKEv1 Aggressive Mode with any-remote-id/general-ikeid

Yes

Yes

IKEv1 main mode

Yes

No

IKEv1 main mode with any-remote-id/general-ikeid

Yes

No

See Example: Configuring AutoVPN with Pre-Shared Key.

Configuration and Management

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

Multicast Support Using PIM

IP multicast delivers traffic to more than one intended receivers by replicating the data packets. You can use multicast data for applications such as video streaming. Your firewall supports Protocol Independent Multicast (PIM) in point-to-multipoint (P2MP) mode. You can enable PIM on the firewall's secure tunnel, st0, interface with P2MP mode. The protocol detects the P2MP interface from the interface configuration and supports multicast traffic. To understand PIM, see PIM Overview.

Figure 1 illustrates multicast topology in P2MP infrastructure.

Figure 1: Multicast Topology in P2MP Infrastructure Multicast Topology in P2MP Infrastructure

The topology shows that one of the SRX Series Firewalls acting as a hub and the rest of the three acting as spokes. You can also have two spokes in your topology. Typically, the multicast sender resides behind the hub, while the multicast receivers are behind the spokes. For multicast support, notice that the secure tunnel st0 logical interface on the hub-and-spoke devices are configured with PIM P2MP mode. On each of these devices, the st0 P2MP interface tracks all PIM joins per neighbor to ensure that the multicast forwarding or replication happens only to those neighbors that are in joined state.

The SRX Series Firewalls support IP multicast traffic in PIM sparse mode over the st0 P2MP interfaces. The hub acts as the first-hop router (FHR) or the rendezvous point (RP). The spokes can act as the last-hop routers (LHR) in the P2MP network. The devices in the network replicate the multicast data packets to neighbors that join the multicast group.

Note the following considerations when you configure multicast traffic support:

  • For IPsec VPN service with the kmd process, you must run Junos OS Release 19.2R1 or later. You can use the platforms SRX300, SRX320, SRX340, SRX345, SRX550, SRX1500, vSRX 2.0 (with 2 vCPU), and vSRX 3.0 (with 2 vCPU).

  • For IPsec VPN service with the iked process, you must run Junos OS Release 24.2R1 or later. You can use the platforms SRX1500, SRX1600, SRX2300, SRX4100, SRX4200, SRX4600, and vSRX 3.0.

  • You cannot configure IPv6 multicast on P2MP interfaces.

  • For IP multicast configuration to work, you must disable PowerMode IPsec (PMI).

  • You cannot perform multicast ping from or to P2MP interfaces.

  • Note that IGMP is enable by default when you enable PIM, but it doesn't work on P2MP interface.

For details on how to configure multicast support on P2MP infrastructure, see Configure Multicast Support on P2MP Infrastructure.

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.

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

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

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 Firewalls; 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 Firewalls 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 Firewalls 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 using certificates:

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.
    • You can use preshared key based authentication if you do not have CA certificates.

  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.

    • Use the preshared key based authentication method, if you configure preshared key authentication on the hub.

  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.

The examples listed in this topic use SRX Series Firewalls running Junos OS for the hub and spoke configurations. If your spoke devices are not running Junos OS, you need to configure Next-Hop Tunnel Binding. For more details, see Example: Configuring the Multipoint VPN Configuration with Next-Hop Tunnel Binding.

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 and uses certificate based authentication.

For authentication with preshared key, see ‘Configure Phase 1 options’ step at Step-by-Step Procedure hub to configure the hub, Step-by-Step Procedure spoke1 to configure the spoke1, and the Step-by-Step Procedure spoke2 to configure the spoke2.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series Firewalls 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.

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 3 shows the options used in this example.

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

Junos OS only supports a single level of certificate hierarchy.

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

Table 4: AutoVPN Configuration for Hub and All Spokes

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

10.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 5 shows the configuration options that are different on each spoke.

Table 5: 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) 10.60.60.1/24

(fe-0.0/4.0) 10.70.70.1/24

Interface to Internet

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

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

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

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

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. Ignore this step, if you are using PSK.

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.

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.

    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.

    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.

    If you intend to use preshared keys instead of certificates for the authentication, make the following changes in your configuration:

    • In the ike proposal, at the [edit security ike proposal ike-proposal] hierarchy level, replace authentication-method rsa-signatures with the authentication-method pre-shared-keys.

      For details about the options, see proposal (Security IKE).

    • In the ike policy, at the [edit security ike policy policy-name] hierarchy level, replace certificate local-certificate Local1 with the pre-shared-key ascii-text key.

      • For example, set pre-shared-key ascii-text juniper123

      For details about the options, see policy (Security IKE).

    • In the ike gateway, at the [edit security ike gateway hub-to-spoke-gw] hierarchy level,

      • Replace dynamic distinguished-name wildcard OU=SLT with the dynamic hostname domain-name.

        • For example, set dynamic hostname juniper.net

          Ensure your device is able to resolve the hostname. Alternatively, you can use set dynamic general-ikeid and  set dynamic ike-user-type group-ike-id for the spoke dynamic identity.

      • Replace local-identity distinguished-name with the local-identity hostname hub-hostname.

        • For example, set local-identity hostname hub.juniper.net.

          Ensure your device is able to resolve the hostname. Alternatively, you can use inet ip-address as in set local-identity inet 192.168.1.100.

      For details about the options, see gateway (Security IKE).

  4. Configure Phase 2 options.

  5. Configure zones.

  6. Configure the default security policy.

  7. Configure the CA profile. Ignore this step, if you are using PSK.

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.

    If you intend to use preshared keys instead of certificates for the authentication, make the following changes in your configuration.

    • In the ike proposal, at the [edit security ike proposal ike-proposal] hierarchy level, replace authentication-method rsa-signatures with the authentication-method pre-shared-keys.

    • In the ike policy, at the [edit security ike policy policy-name] hierarchy level, replace certificate local-certificate Local1 with the pre-shared-key ascii-text key.

    • In the ike gateway, at the [edit security ike gateway hub-to-spoke-gw] hierarchy level,

      • Replace local-identity distinguished-name with the local-identity hostname spoke1-hostname.

        • For example, set local-identity hostname spoke1.juniper.net.

      • Replace remote-identity distinguished-name with the remote-identity hostname hub-hostname.

        • For example, set remote-identity hostname hub.juniper.net

      Ensure your device is able to resolve the hostname. Alternatively, you can use inet ip-address as in set local-identity inet 172.16.1.100 and set remote-identity inet 192.168.1.100.

  4. Configure Phase 2 options.

  5. Configure zones.

  6. Configure the default security policy.

  7. Configure the CA profile. Ignore this step, if you are using PSK.

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.

    If you intend to use preshared keys instead of certificates for the authentication, make the following changes in your configuration.

    • In the ike proposal, at the [edit security ike proposal ike-proposal] hierarchy level, replace authentication-method rsa-signatures with the authentication-method pre-shared-keys.

    • In the ike policy, at the [edit security ike policy policy-name] hierarchy level, replace certificate local-certificate Local1 with the pre-shared-key ascii-text key.

    • In the ike gateway, at the [edit security ike gateway hub-to-spoke-gw] hierarchy level,

      • Replace local-identity distinguished-name with the local-identity hostname spoke2-hostname.

        • For example, set local-identity hostname spoke2.juniper.net

      • Replace remote-identity distinguished-name with the remote-identity hostname hub-hostname.

        • For example, set remote-identity hostname hub.juniper.net

      Ensure your device is able to resolve the hostname. Alternatively, you can use inet ip-address as in set local-identity inet 10.0.1.100 and set remote-identity inet 192.168.1.100.

  4. Configure Phase 2 options.

  5. Configure zones.

  6. Configure the default security policy.

  7. Configure the CA profile. Ignore this step, if you are using PSK.

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.

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.

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.

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.

Verifying Learned Routes

Purpose

Verify that routes to the spokes have been learned.

Action

From operational mode, enter the show route 10.60.60.0 command.

From operational mode, enter the show route 10.70.70.0 command.

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 using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series Firewalls 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.

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 6 shows the options used in this example.

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

Junos OS only supports a single level of certificate hierarchy.

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

Table 7: 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 8 shows the configuration options that are different on each spoke.

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

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 Firewalls to be configured for AutoVPN in this example.

Figure 3: Basic AutoVPN Deployment with iBGPBasic AutoVPN Deployment with iBGP

Configuration

To configure AutoVPN, perform these tasks:

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.

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.

    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.

    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.

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.

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.

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.

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 using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

  • Two supported SRX Series Firewalls 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.

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 9 shows the options used in this example.

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

Junos OS only supports a single level of certificate hierarchy.

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

Table 10: 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: 10.1.1.1

spoke-to-hub-gw-2: 10.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.

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 Firewalls to be configured for AutoVPN in this example.

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

Configuration

To configure AutoVPN, perform these tasks:

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.

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.

    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.

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.

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.

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.

Verifying Learned Routes

Purpose

Verify that routes to the spoke have been learned.

Action

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

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

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 using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

  • Two supported SRX Series Firewalls 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.

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 11 shows the options used in this example.

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

Junos OS only supports a single level of certificate hierarchy.

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

Table 12: 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: 10.1.1.1

spoke-to-hub-gw-2: 10.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: 10.1.1.1 (destination IP)

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

Establish tunnels

(not configured)

Immediately on configuration commit

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

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 Firewalls to be configured for AutoVPN in this example.

Figure 5: 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 10.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 10.60.60.0/24 is rerouted through the backup tunnel.

Configuration

To configure AutoVPN, perform these tasks:

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.

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.

    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.

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.

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.

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.

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 10.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 10.60.60.0 command.

From operational mode, enter the show route 0.0.0.0 command.

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.

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.

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.

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.

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 10.60.60.0/24 and the default route are through the st0.1 interface.

Action

From operational mode, enter the show route 10.60.60.0 command.

From operational mode, enter the show route 0.0.0.0 command.

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 using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series Firewalls 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.

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 13 shows the options used in this example.

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

Junos OS only supports a single level of certificate hierarchy.

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

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

Option

Hub

All Spokes

IKE gateway:

Remote IP address

Dynamic

10.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 15 shows the configuration options that are different on each spoke.

Table 15: 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: 100.60.60.1/24

fe-0.0/4.0: 10.70.70.1/24

Interface to Internet

fe-0/0/1.0: 10.2.2.1/30

ge-0/0/1.0: 10.3.3.1/30

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

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 Firewalls to be configured for AutoVPN in this example.

Figure 6: Basic AutoVPN Deployment with OSPF Basic AutoVPN Deployment with OSPF

Configuration

To configure AutoVPN, perform these tasks:

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.

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.

    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.

    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.

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.

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.

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.

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.

From operational mode, enter the show route 10.70.70.0 command.

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 using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series Firewalls 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.

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 16 shows the options used in this example.

Table 16: 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 17 shows the options configured on the hub and on all spokes.

Table 17: 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 18 shows the configuration options that are different on each spoke.

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

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 7 shows the SRX Series Firewalls to be configured for AutoVPN in this example.

Figure 7: Basic AutoVPN Deployment with OSPFv3Basic AutoVPN Deployment with OSPFv3

Configuration

To configure AutoVPN, perform these tasks:

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.

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.

    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.

    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.

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.

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.

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:

Spoke 1:

Spoke 2:

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. The example is using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

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

  • An SRX Series Firewall 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.

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 19 shows the values used in this example:

Table 19: 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 8 shows the SRX Series Firewalls to be configured for this example.

Figure 8: 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.

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.

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

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.

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

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 Firewalls. 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 Firewalls 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. The example is using the certificate based authentication. For authentication with preshared key, set up a similar configuration shown at Example: Configuring Basic AutoVPN with iBGP.

Requirements

This example uses the following hardware and software components:

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

  • An SRX Series Firewall 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:

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 Firewalls 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 20 shows the values used in this example:

Table 20: 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

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 Firewalls allows all types of inbound traffic; this configuration is not recommended for production deployments.

Topology

Figure 9 shows the SRX Series Firewalls to be configured for this example.

Figure 9: Georedundant IPsec VPN Gateways to eNodeB DevicesGeoredundant 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
  1. 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.

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.

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.

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 10.30.1.0/24 and 10.50.1.0/24 are added to the routing table on the SRX Series hub. These routes are reachable through the st0.1 interface.

Example: Configuring AutoVPN with Pre-Shared Key

This example shows how to configure different IKE preshared key used by the VPN gateway to authenticate the remote peer. Similarly, to configure same IKE preshared key used by the VPN gateway to authenticate the remote peer.

Refer other examples in this topic for end-to-end configuration of AutoVPN.

Requirements

This example uses the following hardware and software components:

  • MX240, MX480, and MX960 with MX-SPC3 and Junos OS Release 21.1R1 that support AutoVPN
  • or SRX5000 line with SPC3 and Junos OS Release 21.2R1 that support AutoVPN
  • or vSRX Virtual Firewall running iked process (with the junos-ike package) and Junos OS Release 21.2R1 that support AutoVPN

Configure different IKE preshared key

To configure different IKE preshared key that the VPN gateway uses to authenticate the remote peer, perform these tasks.

  1. Configure the seeded preshared for IKE policy in the device with AutoVPN hub.

    or

    For example:

    or

  2. Display the pre-shared key for remote peer using gateway name and user-id.

    For example:

    Pre-shared key: 79e4ea39f5c06834a3c4c031e37c6de24d46798a
  3. Configure the generated PSK ("79e4ea39f5c06834a3c4c031e37c6de24d46798a" in step 2) in the ike policy on the remote peer device.

    For example:

  4. (Optional) To bypass the IKE ID validation and allow all IKE ID types, configure general-ikeid configuration statement under the [edit security ike gateway gateway_name dynamic] hierarchy level in the gateway.

Result

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

Configure same IKE preshared key

To configure same IKE preshared key that the VPN gateway uses to authenticate the remote peer, perform these tasks.

  1. Configure the common pre-shared-key for ike policy in the device with AutoVPN hub.

    For example:

  2. Configure the common pre-shared-key on the ike policy for remote peer device.

    For example:

  3. (Optional) To bypass the IKE ID validation and allow all IKE ID types, configure general-ikeid configuration statement under the [edit security ike gateway gateway_name dynamic] hierarchy level in the gateway.

Result

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

Configure Multicast Support on P2MP Infrastructure

In this topic, you'll learn how to enable multicast support on P2MP infrastructure.

Before enabling multicast support, ensure that you meet the considerations listed in Multicast Support Using PIM.

See the following sections to configure and verify multicast support.

Configure Multicast Interface

  • To enable PIM on the st0.0 interface, use the set protocols pim interface interface-name command:

    Here, st0.0 is the secure tunnel interface.

  • To enable multipoint on the st0.0 interface for P2MP mode use set interfaces interface-name unit unit-number multipoint command:

  • To set the IPv4 address for the st0.0 interface, use the set interfaces interface-name unit unit-number family inet address IPv4 address command:

    Here, 192.168.1.3/24 is the IP address of the interface.

  • To disable PIM on the st0.0 interface, use the option disable:

CLI Commands to Verify the Multicast Configuration

You can verify multicast configuration using the following commands.

  • To list the PIM interfaces, use the show pim interfaces command.

  • To list the neighbors that joined the multicast groups, use the show pim join extensive command.

  • To view the entries in the IP multicast forwarding table, use the show multicast route command.

  • To view the multicast next hop details, use the show multicast next-hops detail command.

  • To view the IP multicast statistics, use the show multicast statistics command.

  • To view the forwarding table entries, use the show route forwarding-table extensive command.

Change History Table

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

Release
Description
24.2R1
Support for multicast traffic (IPv4 address) with AutoVPN for firewalls running the iked process is added in Junos OS Release 24.2R1.
17.4R1
Starting with Junos OS Release 17.4R1, IPv6 address is supported on AutoVPN.
17.4R1
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.
15.1X49-D120
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.