Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Auto Discovery VPNs

Auto Discovery VPN (ADVPN) dynamically establishes VPN tunnels between spokes to avoid routing traffic through the hub.

Understanding Auto Discovery VPN

Auto Discovery VPN (ADVPN) is a technology that allows the central Hub to dynamically inform spokes about a better path for traffic between two spokes. When both spokes acknowledge the information from the Hub, they establish a shortcut tunnel and change the routing topology for the host to reach the other side without sending traffic through the Hub.

ADVPN Protocol

ADVPN uses an extension of IKEv2 protocol to exchange messages between two peers, that allows the spokes to establish a shortcut tunnel between each other. Devices that support the ADVPN extension send an ADVPN_SUPPORTED notification in the IKEv2 Notify payload including its capability information and the ADVPN version number during the initial IKE exchange. A device that supports ADVPN can act as either a shortcut suggester or a shortcut partner, but not both.

Establishing a Shortcut

An IPsec VPN gateway can act as a shortcut suggester when it notices that traffic is exiting a tunnel with one of its peers and entering a tunnel with another peer. Figure 1 shows traffic from Spoke 1 to Spoke 3 passing through the Hub.

Figure 1: Spoke-to-Spoke Traffic Passing Through Hub Spoke-to-Spoke Traffic Passing Through Hub

When ADVPN is configured on the devices, ADVPN shortcut capability information is exchanged between the hub and the spokes. As long as Spokes 1 and 3 have previously advertised ADVPN shortcut partner capability to the Hub, the Hub can suggest that Spokes 1 and 3 establish a shortcut between each other.

The shortcut suggester uses its already established IKEv2 SAs with the peers to begin a shortcut exchange with one of the two peers. If the peer accepts the shortcut exchange, then the shortcut suggester begins a shortcut exchange with the other peer. The shortcut exchange includes information to allow the peers (referred to as shortcut partners) to establish IKE and IPsec SAs with each other. The creation of the shortcut between the shortcut partners starts only after both peers accept the shortcut exchange.

Figure 2 shows traffic passing through a shortcut between Spokes 1 and 3. Traffic from Spoke 1 to Spoke 3 does not need to traverse the Hub.

Figure 2: Spoke-to-Spoke Traffic Passing Through Shortcut Spoke-to-Spoke Traffic Passing Through Shortcut

Shortcut Initiator and Responder Roles

The shortcut suggester chooses one of the shortcut partners to act as the initiator for the shortcut; the other partner acts as the responder. If one of the partners is behind a NAT device, then the partner behind the NAT device is chosen as the initiator. If none of the partners is behind a NAT device, the suggester randomly chooses one of the partners as the initiator; the other partner acts as the responder. If both partners are behind NAT devices, then a shortcut cannot be created between them; the suggester does not send a shortcut exchange to any of the peers.

The shortcut suggester begins the shortcut exchange with the responder first. If the responder accepts the shortcut suggestion, then the suggester notifies the initiator.

Using information contained in the shortcut suggester’s notification, the shortcut initiator establishes an IKEv2 exchange with the responder, and a new IPsec SA is established between the two partners. On each partner, the route to the network behind its partner now points to the shortcut instead of to the tunnel between the partner and the suggester. Traffic originating behind one of the partners that is destined to a network behind the other shortcut partner flows over the shortcut.

If the partners decline the shortcut suggestion, then the partners notify the suggester with the reason for the rejection. In this case, traffic between the partners continues to flow through the shortcut suggester.

Shortcut Attributes

The shortcut receives some of its attributes from the shortcut suggester while other attributes are inherited from the suggester-partner VPN tunnel configuration. Table 1 shows the parameters of the shortcut.

Table 1: Shortcut Parameters

Attributes

Received/Inherited From

ADVPN

Configuration

Antireplay

Configuration

Authentication algorithm

Configuration

Dead peer detection

Configuration

DF bit

Configuration

Encryption algorithm

Configuration

Establish tunnels

Suggester

External interface

Configuration

Gateway policy

Configuration

General IKE ID

Configuration

IKE version

Configuration

Install interval

Configuration

Local address

Configuration

Local identity

Suggester

NAT traversal

Configuration

Perfect forward secrecy

Configuration

Protocol

Configuration

Proxy ID

Not applicable

Remote address

Suggester

Remote identity

Suggester

Respond bad SPI

Configuration

Traffic selector

Not applicable

Shortcut Termination

By default, the shortcut lasts indefinitely. Shortcut partners terminate the shortcut if traffic falls below a specified rate for a specified time. By default, the shortcut gets terminated if traffic falls below 5 packets per second for 300 seconds; the idle time and idle threshold values are configurable for partners. You can manually delete the shortcut on either shortcut partner with the clear security ike security-association or clear security ipsec security-association commands to clear the corresponding IKE or IPsec SA. Either of the shortcut partners can terminate the shortcut at any time by sending an IKEv2 delete payload to the other shortcut partner.

When the shortcut is terminated, the corresponding IKE SA and all child IPsec SAs are deleted. After the shortcut is terminated, the corresponding route is deleted on both shortcut partners and traffic between the two peers again flows through the suggester. Shortcut termination information is sent from a partner to the suggester.

The lifetime of a shortcut is independent of the tunnel between the shortcut suggester and shortcut partner. The shortcut is not terminated simply because the tunnel between the suggester and partner is terminated.

Multicast Support Using PIM

The SRX Series Firewalls support Protocol Independent Multicast (PIM) in point-to-multipoint (P2MP) mode in ADVPN infrastructure. You can enable PIM on the firewall's secure tunnel interface, st0, with P2MP mode. The support for multicast traffic using PIM in ADVPN is similar to the support provided in AutoVPN. ADVPN follows same considerations as AutoVPN when configuring multicast support. For more details on understanding multicast support using PIM on P2MP infrastructure, see Understand AutoVPN. To enable PIM on st0 P2MP interface:

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

  • In Multinode High Availability environment, P2MP multicast is achieved using node-local tunnels. The routing protocol over the st0 interface doesn't support synced-state tunnel. See IPsec VPN Support in Multinode High Availability.

One of the SRX Series Firewalls is a shortcut suggester and rest of the firewalls are shortcut partners. Typically, the multicast sender resides behind the shortcut suggester, while the multicast receivers are behind the shortcut partners. For multicast support, the secure tunnel interface, st0, on the suggester and the partner 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 interface. The suggester acts as the first-hop router (FHR) or the rendezvous point (RP). The partners 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.

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

ADVPN Configuration Limitations

Note the following limitations when configuring ADVPN:

  • ADVPN is only supported for site-to-site communications. Configuring an ADVPN suggester is only allowed on AutoVPN hubs.

  • You cannot configure both suggester and partner roles. When ADVPN is enabled on a gateway, you cannot disable both suggester and partner roles on the gateway.

  • You cannot create a shortcut between partners that are both behind NAT devices. The suggester can initiate a shortcut exchange only if one of the partners is behind a NAT device or if no partners are behind NAT devices.

  • To use an IPv6 address for ADVPN:
    • For IPsec VPN service with the kmd process, you must run Junos OS Release 18.1R1 or later on SRX Series Firewalls.

    • For IPsec VPN service with the iked process, you must run Junos OS Release 24.2R1 or later on SRX Series Firewalls.

    • You must configure the st0 interface with P2MP support on all the hub and spoke devices.

    • You must run dynamic routing protocols (DRPs) such as the OSPFv3 to update the routing preference to shortcut tunnel over static tunnel.

    • Note that you cannot configure the VPN monitor feature with IPv6 P2MP st0 interface based ADVPN.

  • You can run the ADVPN service with a DRP that supports either the IPv6 address or IPv4 address but not both at the same time.

  • For configuration changes on the partner, such as enable, disable or role change, the iked:

    1. Tears down and renegotiates the static IKE SA and the IPsec SA to exchange the new capability.

    2. Cleans the shortcut IKE SA and the IPsec SA, and the suggestion information that exists.

  • For non-ADVPN configuration changes, such as:

    1. The static tunnel configuration change that leads to clearing of both the static IKE SA and the IPsec SA, the iked tears down the shortcut IKE SA and the IPsec SA. The iked cleans the suggestion information. The shortcut tunnel doesn't renegotiate again, until it receives shortcut suggestion from the suggester.

    2. The static tunnel configuration change that leads to clearing of the static tunnel IPsec SA only, the iked tears down the shortcut IKE SA and the IPsec SA. The iked cleans the suggestion information. The shortcut tunnel doesn't renegotiate again, until it receives shortcut suggestion from the suggester.

We do not support the following configurations with ADVPN with both the kmd and the iked processes:

  • IKEv1

  • Policy-based VPN

  • IKEv2 configuration payload

  • Traffic selectors

  • Point-to-point secure tunnel interfaces

  • Seeded preshared key

  • Shared preshared key—No support with kmd process

Understanding Traffic Routing with Shortcut Tunnels

Tunnel flaps or catastrophic changes can cause both static tunnels and shortcut tunnels to go down. When this happens, traffic to a specific destination might be routed through an unexpected shortcut tunnel instead of through an expected static tunnel.

In Figure 3, static tunnels exist between the hub and each of the spokes. OSPF adjacencies are established between the hub and spokes. Spoke A also has a shortcut tunnel with Spoke B and OSPF adjacencies are established between the spokes. The hub (the shortcut suggester) recognizes that if connectivity between the hub and Spoke A goes down, Spoke A’s network can be reached through the shortcut tunnel between Spoke B and Spoke A.

Figure 3: Static Tunnels and Shortcut Tunnel Established in Hub-and-Spoke NetworkStatic Tunnels and Shortcut Tunnel Established in Hub-and-Spoke Network

In Figure 4, the static tunnel between the hub and Spoke A is down. If there is new traffic from Spoke C to Spoke A, Spoke C forwards the traffic to the hub because it does not have a shortcut tunnel with Spoke A. The hub does not have an active static tunnel with Spoke A but it recognizes that there is a shortcut tunnel between Spoke A and Spoke B, so it forwards the traffic from Spoke C to Spoke B.

Figure 4: Traffic Path from Spoke C to Spoke ATraffic Path from Spoke C to Spoke A

As long as both Spoke B and Spoke C support Auto Discovery VPN (ADVPN) partner capability, the hub can suggest that the spokes establish a direct shortcut between each other. This occurs even though there is no direct traffic between the two spokes. Traffic from Spoke C to Spoke A travels through the shortcut tunnel between Spoke C and Spoke B, and then through the shortcut tunnel between Spoke B and Spoke A (see Figure 5).

Figure 5: Traffic Path from Spoke C to Spoke A Through Shortcut TunnelsTraffic Path from Spoke C to Spoke A Through Shortcut Tunnels

When the static tunnel between the hub and Spoke A is reestablished, the tunnel is advertised to all spokes. Spoke C learns that there is a better route to reach Spoke A; instead of passing traffic through Spoke B, it forwards traffic for Spoke A to the hub. The hub suggests that a shortcut tunnel be established between Spoke C and Spoke A. When the shortcut tunnel is established between Spoke C and Spoke A, traffic flows through the shortcut tunnel (see Figure 6). Traffic between Spoke C and Spoke A no longer travels through Spoke B, and the shortcut tunnel between Spoke B and Spoke C eventually disappears.

Figure 6: Traffic Path from Spoke C to Spoke A Through Shortcut TunnelTraffic Path from Spoke C to Spoke A Through Shortcut Tunnel

You can use the connection-limit option at the [edit security ike gateway gateway-name advpn partner] hierarchy level to set the maximum number of shortcut tunnels that can be created with different shortcut partners using a particular gateway. The maximum number, which is also the default, is platform-dependent.

Example: Improving Network Resource Utilization with Auto Discovery VPN Dynamic Tunnels

If you are deploying an AutoVPN network, you might be able to increase your network resource utilization by configuring Auto Discovery VPN (ADVPN). In AutoVPN networks, VPN traffic flows through the hub even when the traffic is travelling from one spoke to another. ADVPN allows VPN tunnels to be established dynamically between spokes, which can result in better network resource utilization. Use this example to configure ADVPN to enable dynamic spoke-to-spoke VPN tunnels in your AutoVPN network.

Requirements

This example uses the following hardware and software components:

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

  • Junos OS Release 12.3X48-D10 or later releases that support ADVPN.

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

Before you begin:

  1. 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. See Understanding Local Certificate Requests.

  2. Enroll the digital certificates in each device. See Example: Loading CA and Local Certificates Manually.

This example uses the OSPF dynamic routing protocol as well as static route configurations to forward packets through VPN tunnels. You should be familiar with the OSPF dynamic routing protocol that is used to forward packets through the VPN tunnels.

Overview

This example shows the configurations of an AutoVPN hub and two spokes for ADVPN. The spokes establish IPsec VPN connections to the hub, which allows them to communicate with each other as well as to access resources on the hub. While traffic is initially passed from one spoke to the other through the hub, ADVPN allows the spokes to establish a direct security association between each other. The hub acts as the shortcut suggester. On the hub, the ADVPN configuration disables the partner role. On the spokes, ADVPN configuration disables the suggester role.

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

Table 2: Phase 1 and Phase 2 Options for AutoVPN Hub and Spokes for ADVPN Example

Option

Value

IKE proposal:

Authentication method

rsa-signatures

Diffie-Hellman (DH) group

group5

Authentication algorithm

sha1

Encryption algorithm

aes-256-cbc

IKE policy:

Certificate

local-certificate

IKE gateway:

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

The IKE gateway configuration on the hub and spokes include remote and local values that identify VPN peers. Table 3 shows the IKE gateway configuration for the hub and spokes in this example.

Table 3: IKE Gateway Configuration for ADVPN Example

Option

Hub

Spokes

Remote IP address

Dynamic

Spoke 1: 11.1.1.1

Spoke 2: 11.1.1.1

Local IP address

11.1.1.1

Spoke 1: 21.1.1.2

Spoke 2: 31.1.1.2

Remote IKE ID

Distinguished name (DN) with the string “XYZ” in the organization (O) field and “Sales” in the organization unit (OU) field in the spokes’ certificates

DN with the string “Sales” in the OU field in the hub’s certificate

Local IKE ID

DN on the hub’s certificate

DN on the spokes’ certificate

The hub authenticates the spokes’ IKE ID if the subject fields of the spokes’ certificates contain the string “XYZ” in the O field and “Sales” in the OU field.

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

Figure 7: AutoVPN Deployment with ADVPNAutoVPN Deployment with ADVPN

Configuration

Configuring the Suggester (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 in the CLI User Guide.

To configure the suggester:

  1. Configure interfaces.

  2. Configure the routing protocol and static routes.

  3. Configure Phase 1 options.

  4. Configure Phase 2 options.

  5. Configure certificate information.

  6. Configure zones.

  7. Configure the default security policy.

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 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 Partner (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 in the CLI User Guide.

To configure spoke 1:

  1. Configure interfaces.

  2. Configure the routing protocol and static routes.

  3. Configure Phase 1 options.

  4. Configure Phase 2 options.

  5. Configure certificate information.

  6. Configure zones.

  7. Configure the default security policy.

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 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 Partner (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 in the CLI User Guide.

To configure spoke 2:

  1. Configure interfaces.

  2. Configure the routing protocol and static routes.

  3. Configure Phase 1 options.

  4. Configure Phase 2 options.

  5. Configure certificate information.

  6. Configure zones.

  7. Configure the default security policy.

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 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. First, verify that tunnels are established between the AutoVPN hub and spokes. When traffic is passed from one spoke to another through the hub, a shortcut can be established between the spokes. Verify that the shortcut partners have established a tunnel between them and that a route to the peer is installed on the partners.

Verifying Tunnels Between the Hub and Spokes

Purpose

Verify that tunnels are established between the AutoVPN hub and spokes. Initial traffic from one spoke to another must travel through the hub.

Action

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

The following commands are entered on the hub:

The following commands are entered on spoke 1:

The following commands are entered on spoke 2:

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 spoke. Each spoke shows an 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 spokes.

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

The show route protocol ospf command displays entries in the routing table that were learned from the OSPF protocol. The show ospf neighbor command displays information about OSPF neighbors.

Verifying the Shortcut Tunnel Between Partners

Purpose

The AutoVPN hub can act as a shortcut suggester when it notices that traffic is exiting a tunnel with one of its spokes and entering a tunnel with another spoke. A new IPsec SA, or shortcut, is established between the two shortcut partners. On each partner, the route to the network behind its partner now points to the shortcut tunnel instead of to the tunnel between the partner and the suggester (hub).

Action

From operational mode, enter the show security ike security-associations, show security ipsec security-associations, show route protocol ospf, and show ospf neighbor commands on the spokes.

The following commands are entered on the hub:

The following commands are entered on spoke 1:

The following commands are entered on spoke 2:

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 still shows two active tunnels, one to each spoke. Each spoke shows two active tunnels, one to the hub and one to its shortcut partner.

The show route protocol ospf command shows the addition of routes to the partner and to the hub.

Example: Configuring ADVPN with OSPFv3 for IPv6 Traffic

This example shows how to configure an ADVPN hub and two spokes to create a shortcut tunnel and change the routing topology for the host to reach the other side without sending traffic through the hub. This example configures ADVPN for IPv6 environment using OSPFv3 to forward packets through the VPN tunnels.

Requirements

This example uses the following hardware and software components:

  • Three supported SRX Series Firewalls as ADVPN hub and spokes

  • Junos OS Release 18.1R1 or later releases if your firewall runs the kmd process.

  • Junos OS Release 24.2R1 or later releases if your firewall runs the iked process.

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 ADVPN 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 ADVPN hub and all spokes must have the same values. Table 4 shows the options used in this example.

Table 4: Phase 1 and Phase 2 Options for ADPN 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 5 shows the options configured on the hub and on all spokes.

Table 5: ADVPN 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

reth1

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 immediately

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

Table 6: Comparison Between the OSPFv3 Spoke Configurations

Option

Spoke 1

Spoke 2

st0.1 interface

2001:db8:9000::2/64

2001:db8:9000::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 8 shows the SRX Series Firewalls to be configured for ADVPN in this example.

Figure 8: ADVPN Deployment with OSPFv3ADVPN Deployment with OSPFv3

Configuration

To configure ADVPN, 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.

  8. Configure chassis cluster

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 show chassis cluster 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 interface command.

Enabling OSPF to Update Routes Quickly After ADVPN Shortcut Tunnels Are Established

Problem

Description

OSPF can take up to 9 seconds to update a shortcut route in the routing table. It can take up to 10 seconds before traffic is forwarded to the shortcut tunnel.

Symptoms

When a shortcut tunnel is established between two shortcut partners, OSPF initiates an OSPF hello packet. Because of the timing of the shortcut tunnel establishment and the OSPF neighbor installation, the first packet in the tunnel might be dropped. This can cause OSPF to try again to establish an OSPF adjacency.

By default, the interval at which the OSPF retries to establish an adjacency is 10 seconds. After a shortcut tunnel is established, it can take more than 10 seconds for OSPF to establish an adjacency between the partners.

Solution

Configuring a smaller retry interval, such as 1 or 2 seconds, can enable OSPF to establish adjacencies faster over the shortcut tunnel. For example, use the following configurations:

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 IPv6 address with ADVPN for firewalls running the iked process is added in Junos OS Release 24.2R1.
24.2R1
Support for multicast traffic (IPv4 address) with ADVPN for firewalls running the iked process is added in Junos OS Release 24.2R1.
23.4R1
Support for ADVPN with firewalls running the iked process is added in Junos OS Release 23.4R1.
19.2R1
Starting in Junos OS Release 19.2R1, on SRX300, SRX320, SRX340, SRX345, SRX550, SRX1500, vSRX Virtual Firewall 2.0 (with 2 vCPUs), and vSRX Virtual Firewall 3.0 (with 2 vCPUs) Series devices, Protocol Independent Multicast (PIM) using point-to-multipoint (P2MP) mode supports Auto Discovery VPN in which a new p2mp interface type is introduced for PIM.
18.1R1
Starting with Junos OS Release 18.1R1, ADVPN supports IPv6 with the kmd process.