Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Group VPNv2 Server Clusters

 

Group VPNv2 server cluster provides group controller/key server (GCKS) redundancy, so there is no single point of failure for the entire group VPN network.

Understanding Group VPNv2 Server Clusters

In the Group Domain of Interpretation (GDOI) protocol, the group controller/key server (GCKS) manages Group VPN security associations (SAs), and generates encryption keys and distributes them to group members. Group members encrypt traffic based on the group SAs and keys provided by the GCKS. If the GCKS fails, group members cannot register or obtain keys. A Group VPNv2 server cluster provides GCKS redundancy so there is no single point of failure for the entire group VPN network. Group VPNv2 server clusters can also provide load balancing, scaling, and link redundancy.

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. All servers in a Group VPNv2 server cluster must be supported on SRX Series devices or vSRX instances. Group VPNv2 server clusters are a Juniper Networks proprietary solution and have no interoperability with other vendor’s GCKS.

Root-Server and Sub-Servers

A Group VPNv2 server cluster consists of one root-server with up to four connected sub-servers. All servers in the cluster share the same SA and encryption keys that are distributed to Group VPNv2 members. Servers in the cluster can be located at different sites, as shown in Figure 1.

Figure 1: Group VPNv2 Server Cluster
 Group VPNv2 Server
Cluster

Messages between servers in the cluster are encrypted and authenticated by IKE SAs. The root-server is responsible for generating and distributing encryption keys to sub-servers; because of this responsibility, we recommend that the root-server be configured as a chassis cluster. Sub-servers are single devices and cannot be chassis clusters. Sub-servers must be able to connect to the root-server, although direct links between sub-servers are not necessary.

If a sub-server loses its connection to the root-server, no further connection to the sub-server from group members are allowed and SAs are deleted. Therefore, we recommend that you use a different link to connect each sub-server to the root-server.

Group VPNv2 server clusters are configured with the server-cluster statements at the [edit security group-vpn server group-name] hierarchy level. The following values must be configured for each server in a cluster:

  • The server role—Specify either root-server or sub-server. A given server can be part of multiple Group VPNv2 server clusters, but it must have the same server role in all clusters. A server cannot be configured with the root-server role in one group and the sub-server role in another group.

    You must ensure that there is only one root-server at any time for a Group VPNv2 server cluster.

  • IKE gateway—Specify the name of an IKE gateway configured at the [edit security group-vpn server ike] hierarchy level. For a root-server, the IKE gateway must be a sub-server in the cluster; up to four sub-servers can be specified. For sub-servers, the IKE gateway must be the root-server.

    The root-server and sub-servers must be configured with dead-peer-detection always-send and cannot be configured for a dynamic (unspecified) IP address. Group members are not configured with dead peer detection.

The Group VPNv2 configuration must be the same on each sub-server in a given group.

Each sub-server in the Group VPNv2 server cluster operates as a normal GCKS for registering and deleting members. Upon successful member registration, the registering server is responsible for sending updates to the member. For a given group, you can configure the maximum number of Group VPNv2 members that can be accepted by each sub-server; this number must be the same on all sub-servers in the cluster. A sub-server stops responding to registration requests by new members when it reaches the configured maximum number of Group VPNv2 members. See Load Balancing.

Group Member Registration with Server Clusters

Group members can register with any server in the Group VPNv2 server cluster for a given group, however we recommend that members only connect to sub-servers and not the root-server. Up to four server addresses can be configured on each group member. The server addresses configured on group members can be different. In the example shown below, group member A is configured for sub-servers 1 through 4, while member B is configured for sub-servers 4 and 3:

Group member A:

Group member B:

Server addresses:

Sub-server 1

Sub-server 2

Sub-server 3

Sub-server 4

Sub-server 4

Sub-server 3

The order that the server addresses is configured on a member is important. A group member attempts to register with the first configured server. If registration with a configured server is not successful, the group member tries to register with the next configured server.

Each server in a Group VPNv2 server cluster operates as a normal GCKS for registering and deleting members. Upon successful registration, the registering server is responsible for sending updates to the member via groupkey-push exchanges. For a given group, you can configure the maximum number of group members that can be accepted by each server, however this number must be the same on all servers in the cluster for a given group. Upon reaching the configured maximum number of group members, a server stops responding to registration requests by new members. See Load Balancing for additional information.

Dead Peer Detection

To verify the availability of peer servers in a Group VPNv2 server cluster, each server in the cluster must be configured to send dead peer detection (DPD) requests regardless of whether there is outgoing IPsec traffic to the peer. This is configured with the dead-peer-detection always-send statement at the [edit security group-vpn server ike gateway gateway-name] hierarchy level.

An active server in a Group VPNv2 server cluster sends DPD probes to the IKE gateway(s) configured in the server cluster. DPD should not be configured for a group because multiple groups can share the same peer server IKE gateway configuration. When DPD detects that a server is down, the IKE SA with that server is deleted. All groups mark the server as inactive and DPD to the server is stopped.

DPD should not be configured for the IKE gateway on group members.

When DPD marks the root-server as inactive, the sub-servers stop responding to new group member requests however existing SAs for current group members remain active. An inactive sub-server does not send deletes to group members because the SAs could be still valid and group members can continue using existing SAs.

If an IKE SA expires while a peer server is still active, DPD triggers IKE SA negotiation. Because both root-servers and sub-servers can trigger IKE SAs through DPD, simultaneous negotiation might result in multiple IKE SAs. No impact on server-cluster functionality is expected in this case.

Load Balancing

Load balancing in the Group VPNv2 server cluster can be achieved by configuring the right member-threshold value for the group. When the number of members registered on a server exceeds the member-threshold value, subsequent member registration on that server is rejected. The member registration fails over to the next server configured on the group member until it reaches a server whose member-threshold is not yet reached.

There are two restrictions on configuring the member-threshold:

  • For a given group, the same member-threshold value must be configured on the root-server and all sub-servers in a group server cluster. If the total number of members in the group exceeds the configured member-threshold value, then a groupkey-pull registration initiated by a new member is rejected (the server does not send a response).

  • A server can support members in multiple groups. Each server has a maximum number of group members that it can support. If a server reaches the maximum number of members it can support, then a groupkey-pull registration initiated by a new member is rejected even if the member-threshold value of a specific group has not been reached.

There is no member synchronization among servers in the cluster. The root-server does not have information about the number of registered members on sub-servers. Each sub-server can only show its own registered members.

Understanding Group VPNv2 Server Cluster Limitations

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. Note the following caveats when configuring Group VPNv2 server clusters:

  • Certificate authentication is not supported for server authentication; only preshared keys can be configured.

  • There is no configuration synchronization between servers in the Group VPNv2 server cluster.

  • When enabling a Group VPNv2 server cluster, configuration must be done on the root-server first and then on the sub-servers. Until the configuration is manually synchronized among the servers, traffic loss can be expected during the configuration change.

  • In certain corner cases, the SAs on Group VPNv2 members can be out of sync. Group VPN members can synchronize SAs by getting a new key through a groupkey-pull exchange. You can manually clear SAs on a Group VPNv2 member with the clear security group-vpn member ipsec security-associations or clear security group-vpn member group commands to help speed recovery.

  • The Group VPNv2 server cluster does not support ISSU.

  • If the last groupkey-pull message is lost during a Group VPNv2 member’s registration, a server might consider the member to be a registered member even though the member might fail over to the next server in the server cluster. In this case, the same member might appear to be registered on multiple servers. If the total member-threshold on all servers equals the total number of deployed members, subsequent group members might fail to register.

Note the following caveats for chassis cluster operations on the root-server:

  • No statistics are preserved.

  • No negotiation data or state is saved. If a root-server chassis cluster failover occurs during a groupkey-pull or groupkey-push negotiation, the negotiation is not restarted after the failover.

  • If both chassis cluster nodes of a root-server go down during a rekey of an encryption key, some Group VPNv2 members might receive the new key while other members do not. Traffic might be impacted. Manually clearing SAs on a Group VPNv2 member with the clear security group-vpn member ipsec security-associations or clear security group-vpn member group commands might help speed up recovery when the root-server becomes reachable.

  • In a large-scale environment, RG0 failover on the root-server might take time. If the DPD interval and threshold on a sub-server are configured with small values, it can result in the sub-server marking the root-server as inactive during an RG0 failover. Traffic might be impacted. We recommend that you configure the IKE gateway for the sub-server with a DPD interval * threshold value larger than 150 seconds.

Understanding Group VPNv2 Server Cluster Messages

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. All messages between servers in a Group VPNv2 server cluster are encrypted and authenticated by an IKE security association (SA). Each sub-server initiates an IKE SA with the root-server; this IKE SA must be established before messages can be exchanged between the servers.

This section describes the messages exchanged between the root-server and sub-servers.

Cluster Exchanges

Figure 2 shows the basic messages exchanged between the Group VPNv2 server cluster and Group VPNv2 members.

Figure 2: Group VPNv2 Server Cluster Messages
 Group VPNv2 Server Cluster Messages

Cluster-Init Exchanges

A sub-server launches a cluster initialization (cluster-init) exchange with the root-server to obtain SA and encryption key information. The root-server responds by sending current SA information to the sub-server through the cluster-init exchange.

Sub-servers can then respond to registration requests from Group VPNv2 members through a groupkey-pull exchange. The groupkey-pull exchange allows a Group VPNv2 member to request SAs and keys shared by the group from a sub-server.

Sub-servers start a cluster-init exchange with the root-server when:

  • The root-server is considered inactive. This is the initial assumed state of the root-server. If there is no IKE SA between the root-server and the sub-server, the sub-server initiates an IKE SA with the root-server. After a successful cluster-init exchange, the sub-server obtains information on SAs and marks the root-server as active.

  • The soft lifetime of the SA has expired.

  • A cluster-update message is received to delete all SAs.

  • There are group configuration changes.

If the cluster-init exchange fails, the sub-server retries the exchange with the root-server every 5 seconds.

Cluster-Update Messages

The groupkey-push exchange is a single rekey message that allows a group controller/key server (GCKS) to send group SAs and keys to members before existing group SAs expire and to update group membership. Rekey messages are unsolicited messages sent from the GCKS to members

Upon generating new encryption keys for an SA, the root-server sends SA updates to all active sub-servers through a cluster-update message. After receiving a cluster-update from the root-server, the sub-server installs the new SA and sends the new SA information through a groupkey-push to its registered group members.

A cluster-update message sent from the root-server requires an acknowledgement from the sub-server. If there is no acknowledgement received from a sub-server, the root-server retransmits the cluster-update at the configured retransmission period (the default is 10 seconds). The root-server does not retransmit if dead peer detection (DPD) indicates that the sub-server is unavailable. If a sub-server fails to update SA information after receiving a cluster-update, it does not send an acknowledgement and the root-server retransmits the cluster-update message.

If the soft lifetime of an SA expires before a new SA is received from the root-server, the sub-server sends a cluster-init message to the root-server to get all SAs and does not send a groupkey-push message to its members until it has a new update. If the hard lifetime of an SA expires on the sub-server before it receives a new SA, the sub-server marks the root-server inactive, deletes all registered group members, and continues to send cluster-init messages to the root-server.

A cluster-update message can be sent to delete an SA or a group member; this can be the result of a clear command or a configuration change. If a sub-server receives a cluster-update message to delete an SA, it sends a groupkey-push delete message to its group members and deletes the corresponding SA. If all SAs for a group are deleted, the sub-server initiates a cluster-init exchange with the root-server. If all registered members are deleted, the sub-server deletes all locally registered members.

Understanding Configuration Changes with Group VPNv2 Server Clusters

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. Group VPNv2 server clusters behave differently from standalone Group VPNv2 servers when there are configuration changes that result in new encryption keys and changes to security associations (SAs). The root-server sends SA updates or deletions to sub-servers through cluster-update messages. The sub-servers then send groupkey-push messages to members. Sub-servers cannot send delete messages to group members without first receiving delete messages from the root-server.

All configuration changes must be made on the root-server first and then on sub-servers to ensure that group members receive updates or deletions as expected. Until configuration is synchronized between the servers in the Group VPNv2 server cluster, traffic loss can be expected.

Table 1 describes the effects of various configuration changes on Group VPNv2 servers.

Table 1: Effects of Configuration Changes on Group VPNv2 Servers

Configuration Change

Standalone Group VPNv2 Server Action

Group VPNv2 Server Cluster Action

Root-server

Sub-server

Change IKE proposal, policy, or gateway

Delete the IKE SA for the affected gateway. For IKE proposal, policy, or gateway deletions, delete the registered members for the affected gateway.

Change IPsec proposal

Changes take effect after the traffic encryption key (TEK) rekey.

Group changes:

Delete group name

Send “delete all” to group members. Delete all IKE SAs in the group. Delete all keys in the group immediately. Delete all registered members in the group.

Send “delete all” to sub-servers. Delete all keys in the group immediately. Mark all peers inactive. Delete sub-server IKE SAs. Delete all member IKE SAs.

Delete all member IKE SAs. Delete all keys in the group immediately. Delete all registered members in the group. Mark peer inactive. Delete peer server IKE SAs.

Change ID

Send “delete all” to all members. Delete all IKE SAs in the group. Delete all keys in the group immediately. Delete all registered members in the group. Generate new keys according to the configuration.

Send ”delete all” to sub-servers. Delete all member IKE SAs in the group. Delete all keys in the group immediately. Mark all peers inactive. Delete all peer server IKE SAs. Generate new keys according to the configuration.

Delete all member IKE SAs in the group. Delete all keys in the group immediately. Delete all registered members in the group. Mark peer inactive. Delete peer server IKE SAs. Initiate new cluster-init exchange.

Add or delete IKE gateway

No changes for additions. For deletions, delete the IKE SA and registered members for the affected gateway.

Add or change anti-replay time window

New value takes effect after the TEK rekey.

Add or change no anti-replay

New value takes effect after the TEK rekey.

Server-member communication changes:

Add

Delete all registered members. Generate key encryption key (KEK) SA.

Generate KEK SA. Send new KEK SA to sub-server. Delete all member IKE SAs.

Delete all registered members.

Change

New value takes effect after KEK rekey.

Delete

Send delete to delete all KEK SAs. Delete KEK SA.

Send delete to sub-servers. Delete KEK SA. Delete all member IKE SAs.

Delete KEK SA.

IPsec SA:

Add

Generate new TEK SA. Update the new TEK SA on members.

Generate new TEK SA. Send new TEK SA to sub-servers.

No action.

Change

New value takes effect after TEK rekey.

If the match-policy changes, the current TEK is removed immediately and delete groupkey-push is sent because members need to be explicitly notified that this configuration is removed.

If the match-policy changes, send delete to sub-servers. Delete TEK immediately.

If the match-policy changes, delete TEK immediately.

Delete

Delete TEK immediately. Send delete to delete this TEK SA.

Send delete to sub-servers. Delete TEK immediately.

Delete TEK immediately.

Table 2 describes the effects of changing Group VPNv2 server cluster configuration.

You must ensure that there is only one root-server in a server cluster at any time.

Table 2: Effects of Group VPNv2 Server Cluster Configuration Changes

Server Cluster Configuration Change

Group VPNv2 Server Cluster

Root-server

Sub-server

IKE proposal, policy, or gateway (cluster peer)

For additions, there is no change. For changes or deletions, delete the IKE SA for the affected peer.

Server cluster:

Add

None.

Send “delete all” to group members. Delete all member IKE SAs in the group. Delete all TEKs and KEKs immediately in the group. Delete all registered members in the group. Send cluster-init to root-server.

Change role

You must ensure that there is only one root-server in a server cluster at any time.

Send “delete all” to sub-servers. Delete all member IKE SAs in the group. Delete all TEKs and KEKs immediately in the group. Mark all peers inactive. Delete all peer server IKE SAs. Send cluster-init to root-server.

Rekey TEK. Rekey KEK. Send new keys to sub-servers. Send new keys to members.

Add peer

None.

Delete peer

Mark peer inactive. Clear peer IKE SA.

Mark peer inactive. Clear KEK. Clear TEK. Clear peer IKE SA.

Change retransmission period

None.

Delete server cluster

Send “delete all” to sub-servers. Delete all TEKs and KEKs immediately in the group. Mark all peers inactive. Delete all peer server IKE SAs. Generate new TEKs and KEKs according to the configuration.

Delete all member IKE SAs in the group. Delete all TEKs and KEKs immediately in the group. Delete all registered members in the group. Mark peer inactive. Delete peer server IKE SAs. Generate new TEK and KEK according to the configuration.

Migrating a Standalone Group VPNv2 Server to a Group VPNv2 Server Cluster

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. This section describes how to migrate a standalone Group VPNv2 server to a Group VPNv2 server cluster.

To migrate a standalone Group VPNv2 server to a root-server:

We highly recommend that the root-server be a chassis cluster.

  1. Upgrade the standalone Group VPNv2 server to a chassis cluster. See Chassis Cluster User Guide for SRX Series Devices for more information

    A reboot is required during the upgrade of a standalone SRX Series device to a chassis cluster node. Traffic loss is expected.

  2. On the chassis cluster, add the Group VPNv2 server cluster root-server configuration. The configured server role for the cluster must be root-server.

    There should be no traffic loss among existing group members during the configuration change.

To add a sub-server to the Group VPNv2 server cluster:

  1. On the root-server, configure both a Group VPNv2 server IKE gateway and a server cluster IKE gateway for the sub-server. SAs and existing member traffic should not be impacted.
  2. On the sub-server, configure the server cluster. Remember that the Group VPNv2 configuration must be the same on each server in the cluster, with the exception of the Group VPNv2 server IKE gateways, the server role in the cluster, and the server cluster IKE gateway configurations. On the sub-server, the configured server role in the cluster must be sub-server. Configure a Group VPNv2 server IKE gateway and a server cluster IKE gateway for the root-server.

To delete a sub-server from the Group VPNv2 server cluster:

  1. On the root-server, delete both the Group VPNv2 server IKE gateway and the server cluster IKE gateway configurations for the sub-server. SAs and existing member traffic should not be impacted.
  2. Power off the sub-server.

Example: Configuring a Group VPNv2 Server Cluster and Members

This example shows how to configure a Group VPNv2 server cluster to provide group controller/key server (GCKS) redundancy and scaling to Group VPNv2 group members. Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances.

Requirements

The example uses the following hardware and software components:

  • Eight supported SRX Series devices or vSRX instances running Junos OS Release 15.1X49-D30 or later that support Group VPNv2:

    • Two devices or instances are configured to operate as a chassis cluster. The chassis cluster operates as the root-server in the Group VPNv2 server cluster. The devices or instances must have the same software version and licenses.

      The root-server is responsible for generating and distributing encryption keys to sub-servers in the group VPN server cluster; because of this responsibility, we recommend that the root-server be a chassis cluster.

    • Four other devices or instances operate as sub-servers in the Group VPNv2 server cluster.

    • Two other devices or instances operate as Group VPNv2 group members.

  • Two supported MX Series devices running Junos OS Release 15.1R2 or later that support Group VPNv2. These devices operate as Group VPNv2 group members.

A hostname, a root administrator password, and management access must be configured on each SRX Series device or vSRX instance. We recommend that NTP also be configured on each device.

The configurations in this example focus on what is needed for Group VPNv2 operation, based on the topology shown in Figure 3. Some configurations, such as interface, routing, or chassis cluster setups, are not included here. For example, Group VPNv2 operation requires a working routing topology that allows client devices to reach their intended sites throughout the network; this example does not cover the configuration of static or dynamic routing.

Overview

In this example, the Group VPNv2 network consists of a server cluster and four members. The server cluster consists of a root-server and four sub-servers. Two of the members are SRX Series devices or vSRX instances while the other two members are MX Series devices.

The group VPN SAs must be protected by a Phase 1 SA. Therefore, the group VPN configuration must include configuring IKE Phase 1 negotiations on the root-server, the sub-servers, and the group members. IKE configurations are described as follows.

On the root-server:

  • The IKE policy SubSrv is used to establish Phase 1 SAs with each sub-server.

  • An IKE gateway is configured with dead peer detection (DPD) for each sub-server.

  • The server cluster role is root-server and each sub-server is configured as an IKE gateway for the server cluster.

The root-server should be configured to support chassis cluster operation. In the example, redundant Ethernet interfaces on the root-server connect to each of the sub-servers in the server cluster; the entire chassis cluster configuration is not shown.

On each sub-server:

  • Two IKE policies are configured: RootSrv is used to establish a Phase 1 SA with the root-server, and GMs is used to establish Phase 1 SAs with each group member.

    Preshared keys are used to secure the Phase 1 SAs between the root-server and the sub-servers and between the sub-servers and the group members. Ensure that the preshared keys used are strong keys. On the sub-servers, the preshared key configured for the IKE policy RootSrv must match the preshared key configured on the root-server, and the preshared key configured for the IKE policy GMs must match the preshared key configured on the group members.

  • An IKE gateway is configured with DPD for the root-server. In addition, an IKE gateway is configured for each group member.

  • The server cluster role is sub-server and the root-server is configured as the IKE gateway for the server cluster.

On each group member:

  • The IKE policy SubSrv is used to establish Phase 1 SAs with the sub-servers.

  • The IKE gateway configuration includes the addresses for the sub-servers.

On SRX Series devices or vSRX group members, an IPsec policy is configured for the group with the LAN zone as the from-zone (incoming traffic) and the WAN zone as the to-zone (outgoing traffic). A security policy is also needed to allow traffic between the LAN and WAN zones.

The same group identifier must be configured on both the group server and the group members. In this example, the group name is GROUP_ID-0001 and the group identifier is 1. The group policy configured on the server specifies that the SA and key are applied to traffic between subnetworks in the 172.16.0.0/12 range.

Topology

Figure 3 shows the Juniper Networks devices to be configured for this example.

Figure 3: Group VPNv2 Server Cluster with SRX Series or vSRX and MX Series Members
Group VPNv2 Server Cluster with SRX Series or vSRX and MX Series
Members

Configuration

Configuring the Root-Server

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 root-server:

  1. Configure security zones and security policies.
  2. Configure the chassis cluster.
  3. Configure the IKE proposal, policy, and gateway.
  4. Configure the IPsec SA.
  5. Configure the VPN group.
  6. Configure the group policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show chassis cluster, and show security 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 Sub-Server 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 the sub-server in the Group VPNv2 server cluster:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the VPN group.
  5. Configure the group policy.

Results

From configuration mode, confirm your configuration by entering the show interfacesand show security 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 Sub-Server 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 the sub-server in the Group VPNv2 server cluster:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the VPN group.
  5. Configure the group policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show security 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 Sub-Server 3

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 sub-server in the Group VPNv2 server cluster:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the VPN group.
  5. Configure the group policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show security 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 Sub-Server 4

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 sub-server in the Group VPNv2 server cluster:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the VPN group.
  5. Configure the group policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show security 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 GM-0001 (SRX Series Device or vSRX Instance)

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 Group VPNv2 member:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the IPsec policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show security 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 GM-0002 (SRX Series Device or vSRX Instance)

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 Group VPNv2 member:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the IPsec policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show security 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 GM-0003 (MX Series Device)

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 Group VPNv2 member:

  1. Configure the interfaces.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the service filter.
  5. Configure the service set.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security, show services, and show firewall 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 GM-0004 (MX Series Device)

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 Group VPNv2 member:

  1. Configure the interfaces.
  2. Configure the IKE proposal, policy, and gateway.
  3. Configure the IPsec SA.
  4. Configure the service filter.
  5. Configure the service set.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security, show services, and show firewall 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 Server Cluster Operation

Purpose

Verify that devices in the server cluster recognize peer servers in the group. Ensure that the servers are active and roles in the cluster are properly assigned.

Action

From operational mode, enter the show security group-vpn server server-cluster, show security group-vpn server server-cluster detail, and show security group-vpn server statistics commands on the root-server.

user@RootSrv> show security group-vpn server server-cluster
user@RootSrv> show security group-vpn server server-cluster detail
user@RootSrv> show security group-vpn server statistics

From operational mode, enter the show security group-vpn server server-cluster, show security group-vpn server server-cluster detail, and show security group-vpn server statistics commands on each sub-server.

user@SubSrv01> show security group-vpn server server-cluster
user@SubSrv01> show security group-vpn server server-cluster detail
user@SubSrv01> show security group-vpn server statistics

Verifying That SAs Are Distributed to Members

Purpose

Verify that the sub-servers have received SAs for distribution to group members and the group members have received the SAs.

Action

From operational mode, enter the show security group-vpn server kek security-associations and show security group-vpn server kek security-associations detail commands on the root-server.

user@RootSrv> show security group-vpn server kek security-associations
user@RootSrv> show security group-vpn server kek security-associations detail

From operational mode, enter the show security group-vpn server kek security-associations and show security group-vpn server kek security-associations detail commands on each sub-server.

user@SubSrv01> show security group-vpn server kek security-associations
user@SubSrv01> show security group-vpn server kek security-associations detail

From operational mode, enter the show security group-vpn member kek security-associations and show security group-vpn member kek security-associations detail commands on each group member.

For SRX or vSRX group members:

user@GM-0001> show security group-vpn server kek security-associations
user@GM-0001> show security group-vpn server kek security-associations detail

For MX group members:

user@GM-0003> show security group-vpn member kek security-associations
user@GM-0003> show security group-vpn member kek security-associations detail

Verifying IKE SAs on the Servers

Purpose

Display IKE security associations (SAs) on the servers.

Action

From operational mode, enter the show security group-vpn server ike security-associations and show security group-vpn server ike security-associations detail commands on the root-server.

user@RootSrv> show security group-vpn server ike security-associations
user@RootSrv> show security group-vpn server ike security-associations detail

From operational mode, enter the show security group-vpn server ike security-associations and show security group-vpn server ike security-associations detail commands on each sub-server.

user@SubSrv01> show security group-vpn server ike security-associations
user@SubSrv01> show security group-vpn server ike security-associations detail

Verifying IPsec SAs on the Servers and Group Members

Purpose

Display IPsec security associations (SAs) on the servers and group members.

Action

From operational mode, enter the show security group-vpn server ipsec security-associations and show security group-vpn server ipsec security-associations detail commands on the root-server.

user@RootSrv> show security group-vpn server ipsec security-associations
user@RootSrv> show security group-vpn server ipsec security-associations detail

From operational mode, enter the show security group-vpn server ipsec security-associations and show security group-vpn server ipsec security-associations detail commands on each sub-server.

user@SubSrv01> show security group-vpn server ipsec security-associations
user@SubSrv01> show security group-vpn server ipsec security-associations detail

From operational mode, enter the show security group-vpn member ipsec security-associations and show security group-vpn member ipsec security-associations detail commands on each group member

For SRX or vSRX group members:

user@GM-0001> show security group-vpn member ipsec security-associations
user@GM-0001> show security group-vpn member ipsec security-associations detail

For MX group members:

user@GM-0003> show security group-vpn member ipsec security-associations
user@GM-0003> show security group-vpn member ipsec security-associations detail

Verifying IPsec Policies on Group Members

Purpose

Display the IPsec policy on an SRX or vSRX group member.

This command is not available for MX Series group members.

Action

From operational mode, enter the show security group-vpn member policy command on SRX or vSRX group members.

user@GM-0001> show security group-vpn member policy

Related Documentation