Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Group VPNv1

Group VPN is a set of features that are necessary to secure IP multicast group traffic or unicast traffic over a private WAN that originates on or flows through a device.

Group VPNv1 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 current VPN implementations, the SA is a point-to-point tunnel between two security devices. Group VPNv1 extends IPsec architecture to support SAs that are shared by a group of security devices (see Figure 1).

Figure 1: Standard IPsec VPN and Group VPNv1Standard IPsec VPN and Group VPNv1

Group VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices. With Group VPNv1, any-to-any connectivity is achieved by preserving the original source and destination IP addresses in the outer header. Secure multicast packets are replicated in the same way as cleartext multicast packets in the core network.

Starting with Junos OS Release 12.3X48-D30, Group VPNv1 members can interoperate with Group VPNv2 servers.

Group VPNv1 has some propriety limitations regarding RFC 6407, The Group Domain of Interpretation (GDOI). To use Group VPN without proprietary limitations, upgrade to Group VPNv2. Group VPNv2 is supported on vSRX Virtual Firewall instances starting with Junos OS Release 15.1X49-D30, SRX Series Firewalls starting with Junos OS Release 15.1X49-D40, and MX Series devices starting with Junos OS Release 15.1r2.

Understanding the GDOI Protocol for Group VPNv1

Group VPNv1 is based on RFC 3547, The Group Domain of Interpretation (GDOI). This RFC describes the protocol between group members and a group server to establish SAs among group members. GDOI messages create, maintain, or delete SAs for a group of devices. The GDOI protocol runs on port 848.

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

With group VPN, 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. In Phase 2, 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 in Phase 2 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.

  • 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 VPNv1 Limitations

The following are not supported in this release for group VPNv1:

  • Non-default routing instances

  • Chassis cluster

  • Server clusters

  • Route-based group VPN

  • Public Internet-based deployment

  • SNMP

  • Deny policy from Cisco GET VPN server

  • J-Web interface for configuration and monitoring

Starting with Junos OS Release 12.3X48-D30, Group VPNv1 members on SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices can interoperate with Group VPNv2 servers. When you configure Group VPNv1 members for use with Group VPNv2 servers, note the following limitations:

  • Group VPNv2 supports the IETF draft specification IP Delivery Delay Detection Protocol for a time-based antireplay mechanism. Therefore, IP delivery delay detection protocol-based antireplay is not supported on Group VPNv1 members and must be disabled on the Group VPNv2 server with the deactivate security group-vpn server group group-name anti-replay-time-window command.

  • The Group VPNv2 server does not support colocation, where the group server and group member functions exist in the same device.

  • The Group VPNv2 server does not support heartbeat transmittals. Heartbeat must be disabled on the Group VPNv1 member with the deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold command. We recommend using Group VPNv2 server clusters to avoid traffic impact due to reboots or other interruptions on the Group VPNv2 server.

  • Groupkey-push messages sent from the Group VPNv2 server are based on RFC 6407, The Group Domain of Interpretation (GDOI) and are not supported on Group VPNv1 members. Therefore, groupkey-push messages must be disabled on the Group VPNv2 server with the deactivate security group-vpn server group group-name server-member-communication command.

    Rekeys are supported with groupkey-pull messages. If there are scaling issues where Group VPNv1 members cannot complete the groupkey-pull operation before the TEK hard lifetime expires, we recommend increasing the TEK lifetime to allow sufficient time for members to complete the groupkey-pull operation. Juniper’s scaling numbers are qualified with a 2 hour TEK lifetime.

  • If the Group VPNv2 server is rebooted or upgraded, or the SAs for the group are cleared, new members cannot be added to the network until the next rekey occurs for existing members. New members cannot send traffic to existing members that have old keys. As a workaround, clear the SAs on the existing Group VPNv1 members with the clear security group-vpn member ipsec security-associations command.

  • Because multicast data traffic is not supported by Group VPNv2 members, multicast data traffic cannot be used when Group VPNv1 and Group VPNv2 members coexist in the network for the same group.

Understanding Group VPNv1 Servers and Members

The center of a group VPN is the group server. The group server performs the following tasks:

  • Controls group membership

  • Generates encryption keys

  • Manages group SAs and keys and distributes them to group 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 65,535. 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 VPN server and member actions:

  1. The group server listens on UDP port 848 for members to register. A member device must provide correct IKE Phase 1 authentication to join the group. Preshared key authentication on a per-member basis is supported.

  2. Upon successful authentication and registration, the member device retrieves group SAs and keys from the server with a GDOI groupkey-pull exchange.

  3. The server adds the member to the membership for the group.

  4. Group members exchange packets encrypted with group SA keys.

The server periodically 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 when the group SA has changed.

Understanding Group VPNv1 Server-Member Communication

Group VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices. Server-member communication allows the server to send GDOI groupkey-push 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 rekey 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:

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

  • Authentication algorithm (md5 or sha1) used to authenticate the member to the server. There is no default algorithm.

  • Whether the server sends unicast or multicast rekey messages to group members and parameters related to the communication type.

  • Interval at which the server sends heartbeat messages to the group member. This allows the member to determine whether the server has rebooted, which would require the member to reregister with the server. The default is 300 seconds.

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

Configuring server-member communication is necessary for the group server to send rekey messages to members, but there might be situations in which this behavior is not desired. For example, if group members are dynamic peers (such as in a home office), the devices are not always up and the IP address of a device might be different each time it is powered up. Configuring server-member communication for a group of dynamic peers can result in unnecessary transmissions by the server. If you want IKE Phase 1 SA negotiation to always be performed to protect GDOI negotiation, do not configure server-member communication.

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. If the communication type is configured as unicast, the show security group-vpn server registered-members command shows only active members. If the communication type is configured as multicast, the show security group-vpn server registered-members command shows members who have registered with the server after the configuration; the membership list does not necessarily represent active members because members might drop out after registration.

Understanding Group VPNv1 Group Key Operations

This topic contains the following sections:

Group Keys

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 rekey messages. 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 scope policy configured on the member. An accepted key is installed for the group VPN, whereas a rejected key is discarded.

Rekey Messages

If the group is configured for server-member communications, the server periodically 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. These options specify the type of message and the intervals at which the messages are sent, as explained in the following sections:

There are two types of rekey messages:

  • Unicast rekey messages—The group server sends one copy of the 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.

  • Multicast rekey messages—The group server sends one copy of the rekey message from the specified outgoing interface to the configured multicast group address. Members do not send acknowledgment of receipt of multicast rekey messages. The registered membership list does not necessarily represent active members because members might drop out after initial registration. All members of the group must be configured to support multicast messages.

    IP multicast protocols must be configured to allow delivery of multicast traffic in the network. For detailed information about configuring multicast protocols on Juniper Networks devices, see Multicast Protocols User Guide .

The interval at which the server sends rekey messages is calculated based on the values of the lifetime-seconds and activation-time-delay configuration statements at the [edit security group-vpn server group] hierarchy. The interval is calculated as lifetime-seconds minus 4*(activation-time-delay).

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. The activation-time-delay is configured for the group on the server; the default is 15 seconds. Using the default values for lifetime-seconds and activation-time-delay, the interval at which the server sends rekey messages is 3600 minus 4*15, or 3540 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. In this case, the interval at which the server sends rekey messages is calculated as follows: lifetime-seconds minus 3*(activation-time-delay). Using the default values for lifetime-seconds and activation-time-delay, the interval at which the server sends rekey messages is 3600 minus 3*15, or 3555 seconds.

Member reregistration can occur for the following reasons:

  • The member detects a server reboot by the absence of heartbeats received from the server.

  • The rekey message from the group server is lost or delayed, and the TEK lifetime has expired.

Key Activation

When a member receives a new key from the server, it waits a period of time before using the key for encryption. This period of time is determined by the activation-time-delay configuration statement and whether the key is received through a rekey message sent from the server or as a result of the member reregistering with the server.

If the key is received through a rekey message sent from the server, the member waits 2*(activation-time-delay) seconds before using the key. If the key is received through member reregistration, the member waits the number of seconds specified by the activation-time-delay value.

A member retains the two most recent keys sent from the server for each group SA installed on the member. Both keys can be used for decryption, while the most recent key is used for encryption. The previous key is removed the number of seconds specified by the activation-time-delay value after the new key is activated.

The default for the activation-time-delay configuration statement is 15 seconds. Setting this time period too small can result in a packet being dropped at a remote group member before the new key is installed. Consider the network topology and system transport delays when you change the activation-time-delay value. For unicast transmissions, the system transport delay is proportional to the number of group members.

A group VPNv1 server can send multiple traffic encryption keys (TEKs) to a group VPNv1 member in response to a groupkey-pull request. The following describes how the group VPNv1 member handles the existing TEK and the TEKs it receives from the server:

  • If the group VPNv1 member receives two or more TEKs, it holds the most recent two TEKs and deletes the existing TEK. Of the two held TEKs, the older TEK is activated immediately, and the newer TEK is activated after the activation-time-delay configured on the group VPNv1 server has elapsed (the default is 15 seconds).

  • If the group VPNv1 member receives only one TEK, or if it receives a TEK through a groupkey-push message from the server, the existing TEK is not deleted until the hard lifetime expires. The lifetime is not shortened for the existing TEK.

The group VPNv1 member still installs a received TEK even if the TEK lifetime is less than two times the activation-time-delay value.

Understanding Group VPNv1 Heartbeat Messages

When server-member communication is configured, the group VPNv1 server sends heartbeat messages to members at specified intervals (the default interval is 300 seconds). The heartbeat mechanism allows members to reregister with the server if the specified number of heartbeats is not received. For example, members will not receive heartbeat messages during a server reboot. When the server has rebooted, members reregister with the server.

Heartbeats are transmitted through groupkey-push messages. The sequence number is incremented on each heartbeat message, which protects members from reply attacks. Unlike rekey messages, heartbeat messages are not acknowledged by recipients and are not retransmitted by the server.

Heartbeat messages contain the following information:

  • Current state and configuration of the keys on the server

  • Relative time, if antireplay is enabled

By comparing the information in the heartbeats, a member can detect whether it has missed server information or rekey messages. The member reregisters to synchronize itself with the server.

Heartbeat messages can increase network congestion and cause unnecessary member reregistrations. Thus, heartbeat detection can be disabled on the member if necessary.

Understanding Group VPNv1 Server-Member Colocation Mode

Group server and group member functions are separate and do not overlap. The server and member functions can coexist in the same physical device, which is referred as colocation mode. In colocation mode, there is no change in terms of functionality and behavior of the server or a member, but the server and member each need to be assigned different IP addresses so that packets can be delivered properly. In colocation mode, there can be only one IP address assigned to the server and one IP address assigned to the member across groups.

Group VPNv1 Configuration Overview

This topic describes the main tasks for configuring group VPNv1.

On the group server, configure the following:

  1. IKE Phase 1 negotiation. Use the [edit security group-vpn server ike] hierarchy to configure the IKE Phase 1 SA. See Understanding IKE Phase 1 Configuration for Group VPNv2 .
  2. Phase 2 IPsec SA. See Understanding IPsec SA Configuration for Group VPNv1.
  3. VPN group. See Group VPNv1 Configuration Overview.

On the group member, configure the following:

  1. IKE Phase 1 negotiation. Use the [edit security group-vpn member ike] hierarchy to configure IKE Phase 1 SA. See Understanding IKE Phase 1 Configuration for Group VPNv1 .

  2. Phase 2 IPsec SA. See Understanding IPsec SA Configuration for Group VPNv1.

  3. Scope policy that determines which group policies are installed on the member. See Understanding Dynamic Policies for Group VPNv1.

To prevent packet fragmentation issues, we recommend that the interface used by the group member to connect to the MPLS network be configured for a maximum transmission unit (MTU) size no larger than 1400 bytes. Use the set interface mtu configuration statement to set the MTU size.

The VPN 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 between 1 and 65,535 that identifies the VPN group. The same group identifier must be configured on the group member for Autokey IKE.

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

  • IP address of the server (the loopback interface address is recommended).

  • Group policies—Policies that are to be downloaded to members. Group policies describe the traffic to which the SA and keys apply. See Understanding Dynamic Policies for Group VPNv1.

  • Server-member communication—Optional configuration that allows the server to send rekey messages to members. See Group VPNv1 Overview.

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

Understanding IKE Phase 1 Configuration for Group VPNv1

An IKE Phase 1 SA between the 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 VPNv1, the IKE Phase 1 SA configuration is similar to the configuration for standard IPsec VPNs, but is performed at the [edit security group-vpn] hierarchy.

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 (main or aggressive) 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.

Because Group VPNv2 only supports strong algorithms, the sha-256 authentication algorithm option is supported for Group VPNv1 members on SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices. When Group VPNv1 members interoperate with Group VPNv2 servers, this option must be configured on the Group VPNv1 members with the edit security group-vpn member ike proposal proposal-name authentication-algorithm sha-256 command. On the Group VPNv2 server, authentication-algorithm sha-256 must be configured for IKE proposals and authentication-algorithm hmac-sha-256-128 must be configured for IPsec proposals.

If an IKE gateway on a Group VPNv1 member is configured with more than one gateway address, the error message “Only one remote address is allowed to be configured per IKE gateway configuration” is displayed when the configuration is committed.

The IKE Phase 1 configuration on the group server must match the IKE Phase 1 configuration on group members.

Understanding IPsec SA Configuration for Group VPNv1

After the server and member have established a secure and authenticated channel in Phase 1 negotiation, they proceed through Phase 2. Phase 2 negotiation establishes the IPsec SAs that are shared by group members to secure data that is transmitted among members. While the IPsec SA configuration for group VPN is similar to the configuration for standard VPNs, a group member does not need to negotiate the SA with other group members.

Phase 2 IPsec configuration for group VPNv1 consists of the following information:

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

  • A group policy that references the proposal. A group policy specifies the traffic (protocol, source address, source port, destination address, and destination port) to which the SA and keys apply. The group policy is configured on the server with the ipsec-sa configuration statement at the [edit security group-vpn server group ] hierarchy.

  • An Autokey IKE 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 the group. The Autokey IKE is configured on the member with the ipsec vpn configuration statement at the [edit security group-vpn member] hierarchy.

Understanding Dynamic Policies for Group VPNv1

The group server distributes group SAs and keys to members of a specified group. All members that belong to the same group can share the same set of IPsec SAs. But not all SAs configured for a group are installed on every group member. The SA installed on a specific member is determined by the policy associated with the group SA and the security policies configured on the member.

In a VPN group, each group SA and key that the server pushes to a member is 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.

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 is the case, you must delete one of the identical group policies.

On a group member, a scope policy must be configured that defines the scope of the group policy downloaded from the server. A group policy distributed from the server is compared against the scope policies configured on the member. For a group policy to be installed on the member, the following conditions must be met:

  • Any addresses specified in the group policy must be within the range of addresses specified in the scope policy.

  • The source port, destination port, and protocol specified in the group policy must match those configured in the scope policy.

A group policy that is installed on a member is called a dynamic policy.

A scope policy can be part of an ordered list of security policies for a specific from-zone and to-zone context. Junos OS performs a security policy lookup on incoming packets starting from the top of the ordered list.

Depending on the position of the scope policy within the ordered list of security policies, there are several possibilities for dynamic policy lookup:

  • If the incoming packet matches a security policy before the scope policy is considered, dynamic policy lookup does not occur.

  • If an incoming policy matches a scope policy, the search process continues for a matching dynamic policy. If there is a matching dynamic policy, that policy action (permit) is performed. If there is no matching dynamic policy, the search process continues to search the policies below the scope policy.

    In this release, only the tunnel action is allowed for a scope policy. Other actions are not supported.

You configure a scope policy on a group member by using the policies configuration statement at the [edit security] hierarchy. Use the ipsec-group-vpn configuration statement in the permit tunnel rule to reference the group VPN; this allows group members to share a single SA.

Understanding Antireplay for Group VPNv1

Antireplay is an IPsec feature that can detect when a packet is intercepted and then replayed by attackers. Antireplay is enabled by default for group VPNs but can be disabled for a group with the no-anti-replay configuration statement.

When antireplay is enabled, the group server synchronizes the time between the group members. Each IPsec packet contains a timestamp. The group member checks whether the packet’s timestamp falls within the configured anti-replay-time-window value (the default is 100 seconds). A packet is dropped if the timestamp exceeds the value.

Example: Configuring Group VPNv1 Server and Members

This example shows how to configure group VPNv1 to extend IPsec architecture to support SAs that are shared by a group of security devices. Group VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices.

Requirements

Before you begin:

Overview

In Figure 2, a group VPN consists of two member devices (member1 and member2) and a group server (the IP address of the loopback interface on the server is 20.0.0.1). The group identifier is 1.

Figure 2: Server-Member Configuration ExampleServer-Member Configuration Example

The Phase 2 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. In addition, the same group identifier must be configured on both the group server and the group members.

Group policies are configured on the group server. All group policies configured for a group are downloaded to group members. Scope policies configured on a group member determine which group policies are actually installed on the member. In this example, the following group policies are configured on the group server for downloading to all group members:

  • p1—Allows all traffic from 10.1.0.0/16 to 10.2.0.0./16

  • p2—Allows all traffic from 10.2.0.0./16 to 10.1.0.0/16

  • p3—Allows multicast traffic from 10.1.1.1/32

The member1 device is configured with scope policies that allow all unicast traffic to and from the 10.0.0.0/8 subnetwork. There is no scope policy configured on member1 to allow multicast traffic; therefore, the SA policy p3 is not installed on member1.

The member2 device is configured with scope policies that drop traffic from 10.1.0.0/16 from the trust zone to the untrust zone and to 10.1.0.0/16 from the untrust zone to the trust zone. Therefore the SA policy p2 is not installed on member2.

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.

To configure the group server:

  1. Configure the loopback address on the device.

  2. Configure IKE Phase 1 SA (this configuration must match the Phase 1 SA configured on the group members).

  3. Define the IKE policy and set the remote gateways.

  4. Configure the Phase 2 SA exchange.

  5. Configure the group identifier and IKE gateway.

  6. Configure server-to-member communications.

  7. Configure the group policies to be downloaded to group members.

Results

From configuration mode, confirm your configuration by entering the show security group-vpn server command. 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 Member1

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

  1. Configure Phase 1 SA (this configuration must match the Phase 1 SA configured on the group server).

  2. Define the IKE policy and set the remote gateways.

  3. Configure the group identifier, IKE gateway, and interface for member1.

    To prevent packet fragmentation issues, we recommend that the interface used by the group members to connect to the MPLS network be configured for an MTU size no larger than 1400 bytes. Use the set interface mtu configuration statement to set the MTU size.

  4. Create address books and attach zones to them.

  5. Configure a scope policy from the trust zone to the untrust zone that allows unicast traffic to and from the 10.0.0.0/8 subnetwork.

  6. Configure a scope policy from the untrust zone to the trust zone that allows unicast traffic to and from the 10.0.0.0/8 subnetwork.

Results

From configuration mode, confirm your configuration by entering the show security group-vpn member and show security policies 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 Member2

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

  1. Configure Phase 1 SA (this configuration must match the Phase 1 SA configured on the group server).

  2. Define the IKE policy and set the remote gateway.

  3. Configure the group identifier, IKE gateway, and interface for member2.

    To prevent packet fragmentation issues, we recommend that the interface used by the group members to connect to the MPLS network be configured for an MTU size no larger than 1400 bytes. Use the set interface mtu configuration statement to set the MTU size.

  4. Create an address book and attach it to the trust zone.

  5. Create another address book and attach it to the untrust zone.

  6. Configure a scope policy from the trust zone to the untrust zone that blocks traffic from 10.1.0.0/16.

  7. Configure a scope policy from the untrust zone to the trust zone that blocks traffic to 10.1.0.0/16.

Results

From configuration mode, confirm your configuration by entering the show security group-vpn member and show security policies 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

To confirm that the configuration is working properly, perform this task:

Verifying Dynamic Policies for Member1

Purpose

View the dynamic policies installed on member1.

Action

After the group server downloads keys to member1, enter the show security dynamic-policies command from operational mode.

Meaning

The multicast policy p3 from the server is not installed on member1 because there is no scope policy configured on member1 that allows multicast traffic.

Verifying Dynamic Policies for Member2

Purpose

View the dynamic policies installed on member 2.

Action

After the group server downloads keys to member2, enter the show security dynamic-policies command from operational mode.

Meaning

The policy p2 (for traffic from 10.1.0.0/16 to 10.2.0.0/16) from the server is not installed on member2, because it matches the deny2 security policy configured on member2.

Example: Configuring Group VPNv1 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 VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices.

Requirements

Before you begin:

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

  • Configure the group server and members for Phase 2 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.

  • 3des-cbc is used to encrypt traffic between the server and members.

  • sha1 is used for member authentication.

Default values are used for server heartbeats, KEK lifetime, and retransmissions.

Configuration

Procedure

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.

Example: Configuring Group VPNv1 Server-Member Communication for Multicast Rekey Messages

This example shows how to enable the server to send multicast rekey messages to group members to ensure that valid keys are available for encrypting traffic between group members. Group VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices.

Requirements

Before you begin:

Overview

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

  • The server sends multicast rekey messages to group members by means of multicast address 226.1.1.1 and interface ge-0/0/1.0.

  • 3des-cbc is used to encrypt traffic between the server and members.

  • sha1 is used for member authentication.

Default values are used for server heartbeats, KEK lifetime, and retransmissions.

Configuration

Procedure

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 configure server-member communication for multicast rekey messages:

  1. Set the communications type.

  2. Set the multicast group.

  3. Set the interface for outgoing multicast messages.

  4. Set the encryption algorithm.

  5. Set the member authentication.

Results

From configuration mode, confirm your configuration by entering the show security group-vpn server group g1 server-member-communication command. 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

To confirm that the configuration is working properly, perform these tasks:

Verifying Server-Member Communication for Multicast Rekey Messages

Purpose

Verify that server-member communication parameters for multicast rekey message are configured properly to ensure that valid keys are available for encrypting traffic between group members.

Action

From operational mode, enter the show security group-vpn server group g1 server-member-communication command.

Example: Configuring Group VPNv1 with Server-Member Colocation

This example shows how to configure a device for colocation mode, which allows server and member functions to coexist on the same physical device. Group VPNv1 is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices.

Requirements

Before you begin:

Overview

When colocation mode is configured, group server and group member functions can coexist in the same device. In colocation mode, the server and member must have different IP addresses so that packets are delivered properly.

In Figure 3, a group VPN (group identifier is 1) consists of two members (member1 and member2) and a group server (the IP address of the loopback interface is 20.0.0.1). Note that member1 coexists in the same device as the group server. In this example, the interface that member1 uses to connect to the MPLS network (ge-0/1/0) is assigned the IP address 10.1.0.1/32.

Figure 3: Server-Member Colocation ExampleServer-Member Colocation Example

The configuration instructions in this topic describe how to configure the group server-member1 device for colocation mode. To configure member2, see Example: Configuring Group VPNv1 Server and Members.

To prevent packet fragmentation issues, we recommend that the interface used by the group member to connect to the MPLS network be configured for an MTU size no larger than 1400 bytes. Use the set interface mtu configuration statement to set the MTU size.

Configuration

Procedure

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 group VPN with server-member colocation:

  1. Configure the loopback address on the device.

  2. Configure the interface that member1 uses to connect to the MPLS network.

  3. Configure group VPN colocation on the device.

  4. Configure IKE Phase 1 SA for the server (this configuration must match the Phase 1 SA configured on group members).

  5. Define the IKE policy and set the remote gateways.

  6. Configure the Phase 2 SA exchange for the server.

  7. Configure the group identifier, IKE gateway, antireplay time, and server address on the server.

  8. Configure server to member communications.

  9. Configure the group policies to be downloaded to group members.

  10. Configure Phase 1 SA for member1 (this configuration must match the Phase 1 SA configured for the group server).

  11. Define the policy and set the remote gateway for member1.

  12. Configure the group identifier, IKE gateway, and interface for member1.

  13. Create address books and attach them to zones.

  14. Configure a scope policy from the trust zone to the untrust zone that allows unicast traffic to and from the 10.0.0.0/8 subnetwork.

  15. Configure a scope policy from the untrust zone to the trust zone that allows unicast traffic to and from the 10.0.0.0/8 subnetwork.

Results

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

In the list of configured security policies, make sure that the scope policies are listed before the default policies.

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

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying Group VPN Member Registration

Purpose

Verify that the group VPN members are registered correctly.

Action

From operational mode, enter the show security group-vpn registered-members command.

Verifying Group VPN Server Security Associations for IKE

Purpose

Verify the SAs for the group VPN server for IKE.

Action

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

Verifying Group VPN Server Security Associations for IPsec

Purpose

Verify the SAs for the group VPN server for IPsec.

Action

From operational mode, enter the show security group-vpn server ipsec security-associations command.

Verifying Group VPN Member Security Associations for IKE

Purpose

Verify the SAs for the group VPN members for IKE.

Action

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

Verifying Group VPN Member Security Associations for IPsec

Purpose

Verify the SAs for the group VPN members for IPsec.

Action

From operational mode, enter the show security group-vpn member ipsec security-associations command.

Change History Table

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

Release
Description
12.3X48-D30
Starting with Junos OS Release 12.3X48-D30, Group VPNv1 members can interoperate with Group VPNv2 servers.
12.3X48-D30
Starting with Junos OS Release 12.3X48-D30, Group VPNv1 members on SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices can interoperate with Group VPNv2 servers.