Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Group VPNv2

 

Group VPNv2 introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members share a common security association (SA), also known as a group SA.

Group VPNv2 Overview

An IPsec security association (SA) is a unidirectional agreement between virtual private network (VPN) participants that defines the rules to use for authentication and encryption algorithms, key exchange mechanisms, and secure communications. With many VPN implementations, the SA is a point-to-point tunnel between two security devices (see Figure 1).

Figure 1: Point-to-Point SAs
 Point-to-Point SAs

Group VPNv2 extends IPsec architecture to support SAs that are shared by a group of security devices (see Figure 2). With Group VPNv2, any-to-any connectivity is achieved by preserving the original source and destination IP addresses in the outer header. Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances.

Figure 2: Shared SAs
 Shared SAs
Note

Group VPNv2 is an enhanced version of the group VPN feature introduced in an earlier Junos OS release for SRX Series devices. Group VPNv2 on Juniper devices support RFC 6407, The Group Domain of Interpretation (GDOI), and interoperate with other devices that comply with RFC 6407.

Understanding the GDOI Protocol for Group VPNv2

Group VPNv2 is based on RFC 6407, The Group Domain of Interpretation (GDOI). This RFC describes the protocol between group members and group servers to establish SAs among group members. GDOI messages create, maintain, or delete SAs for a group of devices. Group VPNv2 is supported on vSRX instances and all SRX Series devices except for SRX5400, SRX5600, and SRX5800 devices.

The GDOI protocol runs on UDP port 848. The Internet Security Association and Key Management Protocol (ISAKMP) defines two negotiation phases to establish SAs for an IKE IPsec tunnel. Phase 1 allows two devices to establish an ISAKMP SA for other security protocols, such as GDOI.

With Group VPNv2, Phase 1 ISAKMP SA negotiation is performed between a group server and a group member. The server and member must use the same ISAKMP policy. GDOI exchanges between the server and member establish the SAs that are shared with other group members. A group member does not need to negotiate IPsec with other group members. GDOI exchanges must be protected by ISAKMP Phase 1 SAs.

There are two types of GDOI exchanges:

  • The groupkey-pull exchange allows a member to request SAs and keys shared by the group from the server. Group members must register with a group server through a groupkey-pull exchange.

  • The groupkey-push exchange is a single rekey message that allows the server to send group SAs and keys to members before existing group SAs expire. Rekey messages are unsolicited messages sent from the server to members.

Understanding Group VPNv2 Servers and Members

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. The center of Group VPNv2 is the group controller/key server (GCKS). A server cluster can be used to provide GCKS redundancy.

The GCKS or group server performs the following tasks:

  • Controls group membership.

  • Generates encryption keys.

  • Sends new group SAs and keys to members. Group members encrypt traffic based on the group SAs and keys provided by the group server.

A group server can service multiple groups. A single security device can be a member of multiple groups.

Each group is represented by a group identifier, which is a number between 1 and 4,294,967,295. The group server and group members are linked together by the group identifier. There can be only one group identifier per group, and multiple groups cannot use the same group identifier.

The following is a high-level view of Group VPNv2 server and member actions:

  1. The group server listens on UDP port 848 for members to register.
  2. To register with the group server, the member first establishes an IKE SA with the server. A member device must provide correct IKE Phase 1 authentication to join the group. Preshared key authentication on a per-member basis is supported.
  3. Upon successful authentication and registration, the member device retrieves group SAs and keys for the specified group identifier from the server with a GDOI groupkey-pull exchange.
  4. The server adds the member to the membership for the group.
  5. Group members exchange packets encrypted with group SA keys.

The server sends SA and key refreshes to group members with rekey (GDOI groupkey-push) messages. The server sends rekey messages before SAs expire to ensure that valid keys are available for encrypting traffic between group members.

A rekey message sent by the server requires an acknowledgement (ack) message from each group member. If the server does not receive an ack message from the member, the rekey message is retransmitted at the configured retransmission-period (the default is 10 seconds). If there is no reply from the member after the configured number-of-retransmission (the default is 2 times), the member is removed from the server’s registered members. The IKE SA between the server and member is also removed.

The server also sends rekey messages to provide new keys to members when the group SA has changed.

Understanding Group VPNv2 Limitations

Note

Group VPNv2 servers only operate with Group VPNv2 members that support RFC 6407, The Group Domain of Interpretation (GDOI).

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. The following are not supported in this release for Group VPNv2:

  • SNMP.

  • Deny policy from Cisco GET VPN server.

  • PKI support for Phase 1 IKE authentication.

  • Colocation of group server and member, where server and member functions coexist in the same physical device.

  • Group members configured as chassis clusters.

  • J-Web interface for configuration and monitoring.

  • Multicast data traffic.

Group VPNv2 is not supported in deployments where IP addresses cannot be preserved—for example, across the Internet where NAT is used.

Understanding Group VPNv2 Server-Member Communication

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. Server-member communication allows the server to send GDOI groupkey-push (rekey) messages to members. If server-member communication is not configured for the group, members can send GDOI groupkey-pull messages to register and reregister with the server, but the server is not able to send groupkey-push messages to members.

Server-member communication is configured for the group by using the server-member-communication configuration statement at the [edit security group-vpn server] hierarchy. The following options can be defined:

  • Authentication algorithm (sha-256 or sha-384) used to authenticate the member to the server. There is no default algorithm.

  • Encryption algorithm used for communications between the server and member. You can specify aes-128-cbc, aes-192-cbc, or aes-256-cbc. There is no default algorithm.

  • Unicast communication type for rekey messages sent to group members.

  • Lifetime for the key encryption key (KEK). The default is 3600 seconds.

  • Number of times the group server retransmits groupkey-push messages to a group member without a response (the default is 2 times) and the period of time between retransmissions (the default is 10 seconds).

If server-member communication for a group is not configured, the membership list displayed by the show security group-vpn server registered-members command shows group members who have registered with the server; members can be active or not. When server-member communication for a group is configured, the group membership list is cleared. For unicast communication type, the show security group-vpn server registered-members command shows only active members.

Understanding Group VPNv2 Key Operations

This topic contains the following sections:

Group Keys

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. The group server maintains a database to track the relationship among VPN groups, group members, and group keys. There are two kinds of group keys that the server downloads to members:

  • Key Encryption Key (KEK)—Used to encrypt SA rekey (GDOI groupkey-push) exchanges. One KEK is supported per group.

  • Traffic Encryption Key (TEK)—Used to encrypt and decrypt IPsec data traffic between group members.

The key associated with an SA is accepted by a group member only if there is a matching policy configured on the member. An accepted key is installed for the group, whereas a rejected key is discarded.

Rekey Messages

If the group is configured for server-member communications, the server sends SA and key refreshes to group members with rekey (GDOI groupkey-push) messages. Rekey messages are sent before SAs expire; this ensures that valid keys are available for encrypting traffic between group members.

The server also sends rekey messages to provide new keys to members when there is a change in group membership or the group SA has changed (for example, a group policy is added or deleted).

Server-member communications options must be configured on the server to allow the server to send rekey messages to group members.

The group server sends one copy of the unicast rekey message to each group member. Upon receipt of the rekey message, members must send an acknowledgment (ACK) to the server. If the server does not receive an ACK from a member (including retransmission of rekey messages), the server considers the member to be inactive and removes it from the membership list. The server stops sending rekey messages to the member.

The number-of-retransmission and retransmission-period configuration statements for server-member communications control the resending of rekey messages by the server when no ACK is received from a member.

The interval at which the server sends rekey messages is based on the value of the lifetime-seconds configuration statement at the [edit security group-vpn server group group-name] hierarchy. New keys are generated before the expiration of the KEK and TEK keys.

The lifetime-seconds for the KEK is configured as part of the server-member communications; the default is 3600 seconds. The lifetime-seconds for the TEK is configured for the IPsec proposal; the default is 3600 seconds.

Member Registration

If a group member does not receive a new SA key from the server before the current key expires, the member must reregister with the server and obtain updated keys with a GDOI groupkey-pull exchange.

Group VPNv2 Configuration Overview

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. This topic describes the main tasks for configuring Group VPNv2.

Note

The group controller/key server (GCKS) manages Group VPNv2 security associations (SAs), and generates encryption keys and distributes them to group members. You can use a Group VPNv2 server cluster to provide GCKS redundancy. See Understanding Group VPNv2 Server Clusters.

On the group server(s), configure the following:

  1. IKE Phase 1 SA. See Understanding IKE Phase 1 Configuration for Group VPNv2 .
  2. IPsec SA. See Understanding IPsec SA Configuration for Group VPNv2.
  3. VPN group information, including the group identifier, IKE gateways for group members, the maximum number of members in the group, and server-member communications. Group configuration includes a group policy that defines the traffic to which the SA and keys apply. Server cluster and antireplay time window can optionally be configured. See Group VPNv2 Configuration Overview and Understanding Group VPNv2 Traffic Steering.

On the group member, configure the following:

  1. IKE Phase 1 SA. See Understanding IKE Phase 1 Configuration for Group VPNv2 .
  2. IPsec SA. See Understanding IPsec SA Configuration for Group VPNv2.
  3. IPsec policy that defines the incoming zone (usually a protected LAN), outgoing zone (usually a WAN) and the VPN group to which the policy applies. Exclude or fail-open rules can also be specified. See Understanding Group VPNv2 Traffic Steering.
  4. Security policy to allow group VPN traffic between the zones specified in the IPsec policy.
Note

Group VPNv2 operation requires a working routing topology that allows client devices to reach their intended sites throughout the network.

The group is configured on the server with the group configuration statement at the [edit security group-vpn server] hierarchy.

The group information consists of the following information:

  • Group identifier—A value that identifies the VPN group. The same group identifier must be configured on the group member.

  • Each group member is configured with the ike-gateway configuration statement. There can be multiple instances of this configuration statement, one for each member of the group.

  • Group policies—Policies that are to be downloaded to members. Group policies describe the traffic to which the SA and keys apply. See Understanding Group VPNv2 Traffic Steering.

  • Member threshold—The maximum number of members in the group. After the member threshold for a group is reached, a server stops responding to groupkey-pull initiations from new members. See Understanding Group VPNv2 Server Clusters.

  • Server-member communication—Optional configuration that allows the server to send groupkey-push rekey messages to members.

  • Server cluster—Optional configuration that supports group controller/key server (GCKS) redundancy. See Understanding Group VPNv2 Server Clusters.

  • Antireplay—Optional configuration that detects packet interception and replay. See Understanding Group VPNv2 Antireplay.

Understanding IKE Phase 1 Configuration for Group VPNv2

An IKE Phase 1 SA between a group server and a group member establishes a secure channel in which to negotiate IPsec SAs that are shared by a group. For standard IPsec VPNs on Juniper Networks security devices, Phase 1 SA configuration consists of specifying an IKE proposal, policy, and gateway.

For Group VPNv2, the IKE Phase 1 SA configuration is similar to the configuration for standard IPsec VPNs, but is performed at the [edit security group-vpn server ike] and [edit security group-vpn member ike] hierarchies. Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances.

In the IKE proposal configuration, you set the authentication method and the authentication and encryption algorithms that will be used to open a secure channel between participants. In the IKE policy configuration, you set the mode in which the Phase 1 channel will be negotiated, specify the type of key exchange to be used, and reference the Phase 1 proposal. In the IKE gateway configuration, you reference the Phase 1 policy.

The IKE proposal and policy configuration on the group server must match the IKE proposal and policy configuration on group members. On a group server, an IKE gateway is configured for each group member. On a group member, up to four server addresses can be specified in the IKE gateway configuration.

Understanding IPsec SA Configuration for Group VPNv2

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. After the server and member have established a secure and authenticated channel in Phase 1 negotiation, they proceed to establish the IPsec SAs that are shared by group members to secure data that is transmitted among members. While the IPsec SA configuration for Group VPNv2 is similar to the configuration for standard VPNs, a group member does not need to negotiate the SA with other group members.

IPsec configuration for Group VPNv2 consists of the following information:

  • On the group server, an IPsec proposal is configured for the security protocol, authentication, and encryption algorithm to be used for the SA. The IPsec SA proposal is configured on the group server with the proposal configuration statement at the [edit security group-vpn server ipsec] hierarchy.

  • On the group member, an Autokey IKE is configured that references the group identifier, the group server (configured with the ike-gateway configuration statement), and the interface used by the member to connect to group peers. The Autokey IKE is configured on the member with the vpn configuration statement at the [edit security group-vpn member ipsec] hierarchy.

Understanding Group VPNv2 Traffic Steering

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. The group server distributes IPsec security associations (SAs) and keys to members of a specified group. All members that belong to the same group share the same set of IPsec SAs. The SA that is installed on a specific group member is determined by the policy associated with the group SA and the IPsec policy that is configured on the group member.

Group Policies Configured on Group Servers

In a VPN group, each group SA and key that the server pushes to a member are associated with a group policy. The group policy describes the traffic on which the key should be used, including protocol, source address, source port, destination address, and destination port. On the server, the group policy is configured with the match-policy policy-name options at the [edit security group-vpn server group name ipsec-sa name] hierarchy level.

Note

Group policies that are identical (configured with the same source address, destination address, source port, destination port, and protocol values) cannot exist for a single group. An error is returned if you attempt to commit a configuration that contains identical group policies for a group. If this occurs, you must delete one of the identical group policies before you can commit the configuration.

IPsec Policies Configured on Group Members

On the group member, an IPsec policy consists of the following information:

  • Incoming zone (from-zone) for group traffic.

  • Outgoing zone (to-zone) for group traffic.

  • The name of the group to which the IPsec policy applies. Only one Group VPNv2 name can be referenced by a specific from-zone/to-zone pair.

Note

The interface that is used by the group member to connect to the Group VPNv2 must belong to the outgoing zone. This interface is specified with the group-vpn-external-interface statement at the [edit security group-vpn member ipsec vpn vpn-name] hierarchy level.

On the group member, the IPsec policy is configured at the [edit security ipsec-policy] hierarchy level. Traffic that matches the IPsec policy is further checked against exclude and fail-open rules that are configured for the group.

Fail-Close

By default, traffic that does not match exclude or fail-open rules or group policies received from the group server is blocked; this is known as fail-close.

Exclude and Fail-Open Rules

On group members, the following types of rules can be configured for each group:

  • Traffic that is excluded from VPN encryption. Examples of this type of traffic can include BGP or OSPF routing protocols. To exclude traffic from a group, use the set security group-vpn member ipsec vpn vpn-name exclude rule configuration. A maximum of 10 exclude rules can be configured.

  • Traffic that is critical to the customer’s operation and must be sent in cleartext (unencrypted) if the group member has not received a valid traffic encryption key (TEK) for the IPsec SA. Fail-open rules allow this traffic flow while all other traffic is blocked. Enable fail-open with the set security group-vpn member ipsec vpn vpn-name fail-open rule configuration. A maximum of 10 fail-open rules can be configured.

Priorities of IPsec Policies and Rules

IPsec policies and rules have the following priorities on the group member:

  1. Exclude rules that define traffic to be excluded from VPN encryption.
  2. Group policies that are downloaded from the group server.
  3. Fail-open rules that define traffic that is sent in cleartext if there is no valid TEK for the SA.
  4. Fail-close policy that blocks traffic. This is the default if traffic does not match exclude or fail-open rules or group policies.

Understanding the Group VPNv2 Recovery Probe Process

Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances. Two situations could indicate that a group member is out of synchronization with the group server and other group members:

  • The group member receives an Encapsulating Security Payload (ESP) packet with an unrecognized Security Parameter Index (SPI).

  • There is outgoing IPsec traffic but no incoming IPsec traffic on the group member.

When either situation is detected, a recovery probe process can be triggered on the group member. The recovery probe process initiates GDOI groupkey-pull exchanges at specific intervals to update the member’s SA from the group server. If there is a DoS attack of bad SPI packets or if the sender itself is out of synchronization, the out-of-synchronization indication on the group member might be a false alarm. To avoid overloading the system, the groupkey-pull initiation is retried at intervals of 10, 20, 40, 80, 160, and 320 seconds.

The recovery probe process is disabled by default. To enable the recovery probe process, configure recovery-probe at the [edit security group-vpn member ipsec vpn vpn-name] hierarchy level.

Understanding Group VPNv2 Antireplay

Group VPNv2 antireplay is supported on vSRX instances and all SRX Series devices except for SRX5400, SRX5600, and SRX5800 devices. Antireplay is an IPsec feature that can detect when a packet is intercepted and then replayed by attackers. Antireplay is disabled by default for a group.

Each IPsec packet contains a timestamp. The group member checks whether the packet’s timestamp falls within the configured anti-replay-time-window value. A packet is dropped if the timestamp exceeds the value.

We recommend that NTP be configured on all devices that support Group VPNv2 antireplay.

Note

Group members that are running on vSRX instances on a host machine where the hypervisor is running under a heavy load can experience issues that can be corrected by reconfiguring the anti-replay-time-window value. If data that matches the IPsec policy on the group member is not being transferred, check the show security group-vpn member ipsec statistics output for D3P errors. Make sure that NTP is operating correctly. If there are errors, adjust the anti-replay-time-window value.

Example: Configuring a Group VPNv2 Server and Members

This example shows how to configure a Group VPNv2 server to provide group controller/key server (GCKS) support 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:

  • A supported SRX Series device or vSRX instance running Junos OS Release 15.1X49-D30 or later that supports Group VPNv2. This SRX Series device or vSRX instance operates as a Group VPNv2 server.

  • Two supported SRX Series devices or vSRX instances running Junos OS Release 15.1X49-D30 or later that support Group VPNv2. These 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 device. We recommend that NTP also be configured on each device.

Note

Group VPNv2 operation requires a working routing topology that allows client devices to reach their intended sites throughout the network. This examples focuses on the Group VPNv2 configuration; the routing configuration is not described.

Overview

In this example, the Group VPNv2 network consists of a server and four members. Two of the members are SRX Series devices or vSRX instances while the other two members are MX Series devices. The shared group VPN SAs secure traffic between group members.

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 both the group server and the group members.

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.

On SRX 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.

Topology

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

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

Configuration

Configuring the Group 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 Group VPNv2 server:

  1. Configure interfaces, security zones, and security policies.
  2. Configure the static routes.
  3. Configure the IKE proposal, policy, and gateways.
  4. Configure the IPsec proposal.
  5. Configure the group.
  6. Configure server-to-member communications.
  7. Configure the group policy to be downloaded to the group members.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 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 Group Member 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 static routes.
  3. Configure the IKE proposal, policy, and gateway.
  4. Configure the IPsec SA.
  5. Configure the IPsec policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 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 Group Member 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 static routes.
  3. Configure the IKE proposal, policy, and gateway.
  4. Configure the IPsec SA.
  5. Configure the IPsec policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 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 Group Member 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

To configure the Group VPNv2 member:

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

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 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.

Configuring Group Member 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

To configure the Group VPNv2 member:

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

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 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.

Verification

Confirm that the configuration is working properly.

Verifying Group Member Registration

Purpose

Verify that group members are registered on the server.

Action

From operational mode, enter the show security group-vpn server registered-members and show security group-vpn server registered-members detail commands on the server.

user@host> show security group-vpn server registered-members
user@host> show security group-vpn server registered-members detail

Verifying That Group Keys Are Distributed

Purpose

Verify that group keys are distributed to members.

Action

From operational mode, enter the show security group-vpn server statistics command on the group server.

user@host> show security group-vpn server statistics

Verifying Group VPN SAs on the Group Server

Purpose

Verify Group VPN SAs on the group server.

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 group server.

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

Verifying Group VPN SAs on Group Members

Purpose

Verify Group VPN SAs on the group members.

Action

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 the SRX or vSRX group member.

user@host> show security group-vpn member kek security-associations
user@host> show security group-vpn member 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 the MX Series group member.

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

Verifying IPsec SAs on the Group Server

Purpose

Verify IPsec SAs on the group server.

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 group server.

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

Verifying IPsec SAs on the Group Members

Purpose

Verify IPsec SAs on the group members.

Action

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 the SRX or vSRX group member.

user@host> show security group-vpn member ipsec security-associations
user@host> show security group-vpn member 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 the MX Series group member.

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

Verifying Group Policies (SRX or vSRX Group Members Only)

Purpose

Verify group policies on SRX or vSRX group members.

Action

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

user@host> show security group-vpn member policy

Example: Configuring Group VPNv2 Server-Member Communication for Unicast Rekey Messages

This example shows how to enable the server to send unicast rekey messages to group members to ensure that valid keys are available for encrypting traffic between group members. Group VPNv2 is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX instances.

Requirements

Before you begin:

  • Configure the group server and members for IKE Phase 1 negotiation.

  • Configure the group server and members for IPsec SA.

  • Configure the group g1 on the group server.

Overview

In this example, you specify the following server-member communication parameters for group g1:

  • The server sends unicast rekey messages to group members.

  • aes-128-cbc is used to encrypt traffic between the server and members.

  • sha-256 is used for member authentication.

Default values are used for KEK lifetime and retransmissions.

Configuration

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 server-member communication:

  1. Set the communications type.
  2. Set the encryption algorithm.
  3. Set the member authentication.

Verification

To verify the configuration is working properly, enter the show security group-vpn server group g1 server-member-communication command.