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).
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
- Understanding Group VPNv1 Limitations
- Understanding Group VPNv1 Servers and Members
- Understanding Group VPNv1 Server-Member Communication
- Understanding Group VPNv1 Group Key Operations
- Understanding Group VPNv1 Heartbeat Messages
- Understanding Group VPNv1 Server-Member Colocation Mode
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-pullexchange allows a member to request SAs and keys shared by the group from the server.The
groupkey-pushexchange 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-windowcommand.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-thresholdcommand. 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-communicationcommand.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-associationscommand.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:
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.
Upon successful authentication and registration, the member device retrieves group SAs and keys from the server with a GDOI
groupkey-pullexchange.The server adds the member to the membership for the group.
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-retransmissionandretransmission-periodconfiguration 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-delayconfigured 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-pushmessage 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.
See Also
Group VPNv1 Configuration Overview
This topic describes the main tasks for configuring group VPNv1.
On the group server, configure the following:
- 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 . - Phase 2 IPsec SA. See Understanding IPsec SA Configuration for Group VPNv1.
- VPN group. See Group VPNv1 Configuration Overview.
On the group member, configure the following:
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 .Phase 2 IPsec SA. See Understanding IPsec SA Configuration for Group VPNv1.
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-gatewayconfiguration 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
proposalconfiguration 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-saconfiguration 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-gatewayconfiguration statement), and the interface used by the member to connect to the group. The Autokey IKE is configured on the member with theipsec vpnconfiguration 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
tunnelaction 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.
See Also
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.
See Also
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:
Configure the Juniper Networks security devices for network communication.
Configure network interfaces on server and member devices. See Interfaces User Guide for Security Devices.
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.
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.
set interfaces lo0 unit 0 family inet address 20.0.0.1/32 set security group-vpn server ike proposal srv-prop authentication-method pre-shared-keys set security group-vpn server ike proposal srv-prop dh-group group2 set security group-vpn server ike proposal srv-prop authentication-algorithm sha1 set security group-vpn server ike proposal srv-prop encryption-algorithm 3des-cbc set security group-vpn server ike policy srv-pol mode main set security group-vpn server ike policy srv-pol proposals srv-prop set security group-vpn server ike policy srv-pol pre-shared-key ascii-text "$ABC123" set security group-vpn server ike gateway gw1 ike-policy srv-pol set security group-vpn server ike gateway gw1 address 10.1.0.1 set security group-vpn server ike gateway gw2 ike-policy srv-pol set security group-vpn server ike gateway gw2 address 10.2.0.1 set security group-vpn server ipsec proposal group-prop authentication-algorithm hmac-sha1-96 set security group-vpn server ipsec proposal group-prop encryption-algorithm 3des-cbc set security group-vpn server ipsec proposal group-prop lifetime-seconds 3600 set security group-vpn server group grp1 group-id 1 set security group-vpn server group grp1 ike-gateway gw1 set security group-vpn server group grp1 ike-gateway gw2 set security group-vpn server group grp1 anti-replay-time-window 120 set security group-vpn server group grp1 server-address 20.0.0.1 set security group-vpn server group grp1 ipsec-sa group-sa proposal group-prop set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 source 10.1.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 destination 10.2.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 protocol 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 source 10.2.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 destination 10.1.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 protocol 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 source 10.1.1.1/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 destination 239.1.1.1/32 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 protocol 0
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:
Configure the loopback address on the device.
[edit] user@host# edit interfaces user@host# set lo0 unit 0 family inet address 20.0.0.1/32
Configure IKE Phase 1 SA (this configuration must match the Phase 1 SA configured on the group members).
[edit security group-vpn server ike proposal srv-prop] user@host# set authentication-method pre-shared-keys user@host# set dh-group group2 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm 3des-cbc
Define the IKE policy and set the remote gateways.
[edit security group-vpn server ike] user@host# set policy srv-pol mode main proposals srv-prop pre-shared-key ascii-text "$ABC123" user@host# set gateway gw1 ike-policy srv-pol address 10.1.0.1 user@host# set gateway gw2 ike-policy srv-pol address 10.2.0.1
Configure the Phase 2 SA exchange.
[edit security group-vpn server ipsec proposal group-prop] user@host# set authentication-algorithm hmac-sha1–96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 3600
Configure the group identifier and IKE gateway.
[edit security group-vpn server group grp1] user@host# set group-id 1 user@host# set ike-gateway gw1 user@host# set ike-gateway gw2 user@host# set anti-replay-time-window 120 server-address 20.0.0.1
Configure server-to-member communications.
[edit security group-vpn server group grp1] user@host# set server-member-communication communication-type unicast encryption-algorithm aes-128-cbc sig-hash-algorithm md5 certificate “srv-cert”
Configure the group policies to be downloaded to group members.
[edit security group-vpn server group grp1 ipsec-sa group-sa] user@host# set proposal group-prop match-policy p1 source 10.1.0.0/16 destination 10.2.0.0/16 source-port 0 destination-port 0 protocol 0 user@host# set proposal group-prop match-policy p2 source 10.2.0.0/16 destination 10.1.0.0/16 source-port 0 destination-port 0 protocol 0 user@host# set proposal group-prop match-policy p3 source 10.1.1.1/16 destination 239.1.1.1/32 source-port 0 destination-port 0 protocol 0
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.
[edit]
user@host# show security group-vpn server
ike {
proposal srv-prop {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy srv-pol {
mode main;
proposals srv-prop;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway gw1 {
ike-policy srv-pol;
address 10.1.0.1;
}
gateway gw2 {
ike-policy srv-pol;
address 10.2.0.1;
}
}
ipsec {
proposal group-prop {
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
}
group grp1 {
group-id 1;
ike-gateway gw1;
ike-gateway gw2;
anti-replay-time-window 120;
server-address 20.0.0.1;
ipsec-sa group-sa {
proposal group-prop;
match-policy p1 {
source 10.1.0.0/16;
destination 10.2.0.0/16;
source-port 0;
destination-port 0;
protocol 0;
}
match-policy p2 {
source 10.2.0.0/16;
destination 10.1.0.0/16;
source-port 0;
destination-port 0;
protocol 0;
}
match-policy p3 {
source 10.1.1.1/16;
destination 239.1.1.1/32;
source-port 0;
destination-port 0;
protocol 0;
}
}
}
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.
set security group-vpn member ike proposal prop1 authentication-method pre-shared-keys set security group-vpn member ike proposal prop1 dh-group group2 set security group-vpn member ike proposal prop1 authentication-algorithm sha1 set security group-vpn member ike proposal prop1 encryption-algorithm 3des-cbc set security group-vpn member ike policy pol1 mode main set security group-vpn member ike policy pol1 proposals prop1 set security group-vpn member ike policy pol1 pre-shared-key ascii-text "$ABC123" set security group-vpn member ike gateway g1 ike-policy pol1 set security group-vpn member ike gateway g1 address 20.0.0.1 set security group-vpn member ike gateway g1 local-address 10.1.0.1 set security group-vpn member ipsec vpn v1 ike-gateway g1 set security group-vpn member ipsec vpn v1 group-vpn-external-interface ge-0/1/0 set security group-vpn member ipsec vpn v1 group 1 set security address-book book1 address 10_subnet 10.0.0.0/8 set security address-book book1 attach zone trust set security address-book book2 address 10_subnet 10.0.0.0/8 set security address-book book2 attach zone untrust set security policies from-zone trust to-zone untrust policy scope1 match source-address 10_subnet set security policies from-zone trust to-zone untrust policy scope1 match destination-address 10_subnet set security policies from-zone trust to-zone untrust policy scope1 match application any set security policies from-zone trust to-zone untrust policy scope1 then permit tunnel ipsec-group-vpn v1 set security policies from-zone untrust to-zone trust policy scope1 match source-address 10_subnet set security policies from-zone untrust to-zone trust policy scope1 match destination-address 10_subnet set security policies from-zone untrust to-zone trust policy scope1 match application any set security policies from-zone untrust to-zone trust policy scope1 then permit tunnel ipsec-group-vpn v1
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:
Configure Phase 1 SA (this configuration must match the Phase 1 SA configured on the group server).
[edit security group-vpn member ike proposal prop1] user@member1# set authentication-method pre-shared-keys user@member1# set dh-group group2 user@member1# set authentication-algorithm sha1 user@member1# set encryption-algorithm 3des-cbc
Define the IKE policy and set the remote gateways.
[edit security group-vpn member ike] user@member1# set policy pol1 mode main proposals prop1 pre-shared-key ascii-text "$ABC123" user@member1# set gateway g1 ike-policy pol1 address 20.0.0.1 local-address 10.1.0.1
Configure the group identifier, IKE gateway, and interface for member1.
[edit security group-vpn member ipsec] user@member1# set vpn v1 group 1 ike-gateway g1 group-vpn-external-interface ge-0/1/0
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 mtuconfiguration statement to set the MTU size.Create address books and attach zones to them.
[edit security address-book book1] user@member1# set address 10_subnet 10.0.0.0/8 user@member1# set attach zone trust
[edit security address-book book2] user@member1# set address 10_subnet 10.0.0.0/8 user@member1# set attach zone untrust
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.
[edit security policies from-zone trust to-zone untrust] user@member1# set policy scope1 match source-address 10_subnet destination-address 10_subnet application any user@member1# set policy scope1 then permit tunnel ipsec-group-vpn v1
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.
[edit security policies from-zone untrust to-zone trust] user@member1# set policy scope1 match source-address 10_subnet destination-address 10_subnet application any user@member1# set policy scope1 then permit tunnel ipsec-group-vpn v1
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.
[edit]
user@member1# show security group-vpn member
ike {
proposal prop1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy pol1 {
mode main;
proposals prop1;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway g1 {
ike-policy pol1;
address 20.0.0.1;
local-address 10.1.0.1;
}
}
ipsec {
vpn v1 {
ike-gateway g1;
group-vpn-external-interface ge-0/1/0;
group 1;
}
}
[edit]
user@member1# show security policies
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy scope1 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v1;
}
}
}
}
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy scope1 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v1;
}
}
}
}
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
}
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.
set security group-vpn member ike proposal prop2 authentication-method pre-shared-keys set security group-vpn member ike proposal prop2 authentication-method pre-shared-keys set security group-vpn member ike proposal prop2 dh-group group2 set security group-vpn member ike proposal prop2 authentication-algorithm sha1 set security group-vpn member ike proposal prop2 encryption-algorithm 3des-cbc set security group-vpn member ike policy pol2 mode main set security group-vpn member ike policy pol2 proposals prop2 set security group-vpn member ike policy pol2 pre-shared-key ascii-text "$ABC123" set security group-vpn member ike gateway g2 ike-policy pol2 set security group-vpn member ike gateway g2 address 20.0.0.1 set security group-vpn member ike gateway g2 local-address 10.2.0.1 set security group-vpn member ipsec vpn v2 ike-gateway g2 set security group-vpn member ipsec vpn v2 group-vpn-external-interface ge-0/1/0 set security group-vpn member ipsec vpn v2 group 1 set security address-book book1 address 10_subnet 10.0.0.0/8 set security address-book book1 address 10_1_0_0_16 10.1.0.0/16 set security address-book book1 address multicast_net 239.0.0.0/8 set security address-book book1 attach zone trust set security address-book book2 address 10_subnet 10.0.0.0/8 set security address-book book2 address 10_1_0_0_16 10.1.0.0/16 set security address-book book2 address multicast_net 239.0.0.0/8 set security address-book book2 attach zone untrust set security policies from-zone trust to-zone untrust policy deny2 match source-address 10_1_0_0_16 set security policies from-zone trust to-zone untrust policy deny2 match destination-address any set security policies from-zone trust to-zone untrust policy deny2 match application any set security policies from-zone trust to-zone untrust policy deny2 then reject set security policies from-zone trust to-zone untrust policy scope2 match source -address 10_subnet set security policies from-zone trust to-zone untrust policy scope2 match destination-address 10_subnet set security policies from-zone trust to-zone untrust policy scope2 match application any set security policies from-zone trust to-zone untrust policy scope2 then permit tunnel ipsec-group-vpn v2 set security policies from-zone trust to-zone untrust policy multicast-scope2 match source-address 10_subnet set security policies from-zone trust to-zone untrust policy multicast-scope2 match destination-address multicast-net set security policies from-zone trust to-zone untrust policy multicast-scope2 match application any set security policies from-zone trust to-zone untrust policy multicast-scope2 then permit tunnel ipsec-group-vpn v2 set security policies from-zone untrust to-zone trust policy deny2 match source-address any set security policies from-zone untrust to-zone trust policy multicast-scope2 ma tch application any set security policies from-zone untr set security policies from-zone untrust to-zone trust policy deny2 match destination-address 10_1_0_0_16 set security policies from-zone untrust to-zone trust policy deny2 match application any set security policies from-zone untrust to-zone trust policy deny2 then reject set security policies from-zone untrust to-zone trust policy scope2 match source-address 10_subnet set security policies from-zone untrust to-zone trust policy scope2 match destination-address 10_subnet set security policies from-zone untrust to-zone trust policy scope2 match application any set security policies from-zone untrust to-zone trust policy scope2 then permit tunnel ipsec-group-vpn v2 set security policies from-zone untrust to-zone trust policy multicast-scope2 match source-address 10_subnet set security policies from-zone untrust to-zone trust policy multicast-scope2 match destination-address multicast-net set security policies from-zone untrust to-zone trust policy multicast-scope2 match application any set security policies from-zone untrust to-zone trust policy multicast-scope2 then permit tunnel ipsec-group-vpn v2
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:
Configure Phase 1 SA (this configuration must match the Phase 1 SA configured on the group server).
[edit security group-vpn member ike proposal prop2] user@member2# set authentication-method pre-shared-keys user@member2# set dh-group group2 user@member2# set authentication-algorithm sha1 user@member2# set encryption-algorithm 3des-cbc
Define the IKE policy and set the remote gateway.
[edit security group-vpn member ike] user@member2# set policy pol2 mode main proposals prop2 pre-shared-key ascii-text "$ABC123" user@member2# set gateway g2 ike-policy pol2 address 20.0.0.1 local-address 10.2.0.1
Configure the group identifier, IKE gateway, and interface for member2.
[edit security group-vpn member ipsec] user@member2# set vpn v2 group 1 ike-gateway g2 group-vpn-external-interface ge-0/1/0
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 mtuconfiguration statement to set the MTU size.Create an address book and attach it to the trust zone.
[edit security address-book book1] user@member2# set address 10_subnet 10.0.0.0/8 user@member2# set address 10_1_0_0_16 10.1.0.0/16 user@member2# set address multicast_net 239.0.0.0/8 user@member2# set attach zone trust
Create another address book and attach it to the untrust zone.
[edit security address-book book2] user@member2# set address 10_subnet 10.0.0.0/8 user@member2# set address 10_1_0_0_16 10.1.0.0/16 user@member2# set address multicast_net 239.0.0.0/8 user@member2# set attach zone untrust
Configure a scope policy from the trust zone to the untrust zone that blocks traffic from 10.1.0.0/16.
[edit security policies from-zone trust to-zone untrust] user@member2# set policy deny2 match source-address 10_1_0_0_16 destination-address any application any user@member2# set policy deny2 then reject user@member2# set policy scope2 match source-address 10_subnet destination-address 10_subnet application any user@member2# set policy scope2 then permit tunnel ipsec-group-vpn v2 user@member2# set policy multicast-scope2 match source-address 10_subnet destination-address multicast-net application any user@member2# set policy multicast-scope2 then permit tunnel ipsec-group-vpn v2
Configure a scope policy from the untrust zone to the trust zone that blocks traffic to 10.1.0.0/16.
[edit security policies from-zone untrust to-zone trust] user@member2# set policy deny2 match source-address any destination-address 10_1_0_0_16 application any user@member2# set policy deny2 then reject user@member2# set policy scope2 match source-address 10_subnet destination-address 10_subnet application any user@member2# set policy scope2 then permit tunnel ipsec-group-vpn v2 user@member2# set policy multicast-scope2 match source-address 10_subnet destination-address multicast-net application any user@member2# set policy multicast-scope2 then permit tunnel ipsec-group-vpn v2
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.
[edit]
user@member2# show security group-vpn member
ike {
proposal prop2 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy pol2 {
mode main;
proposals prop2;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway g2 {
ike-policy pol2;
address 20.0.0.1;
local-address 10.2.0.1;
}
}
ipsec {
vpn v2 {
ike-gateway g2;
group-vpn-external-interface ge-0/1/0;
group 1;
}
}
[edit]
user@member2# show security policies
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy deny2 {
match {
source-address 10_1_0_0_16;
destination-address any;
application any;
}
then {
reject;
}
}
policy scope2 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v2;
}
}
}
}
policy multicast-scope2 {
match {
source-address 10_subnet;
destination-address multicast-net;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v2;
}
}
}
}
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy deny2 {
match {
source-address any;
destination-address 10_1_0_0_16;
application any;
}
then {
reject;
}
}
policy scope2 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v2;
}
}
}
}
policy multicast-scope2 {
match {
source-address 10_subnet;
destination-address multicast-net;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v2;
}
}
}
}
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
}
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.
user@member1> show security dynamic-policies
Policy: scope1-0001, action-type: permit, State: enabled, Index: 1048580,AI: disabled, Scope Policy: 4
Policy Type: Dynamic
Sequence number: 1
From zone: untrust, To zone: trust
Source addresses: 10.1.0.0/16
Destination addresses: 10.2.0.0/16
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
Policy: scope1–0001, action-type: permit, State: enabled, Index: 1048581,AI: disabled, Scope Policy: 5
Policy Type: Dynamic
Sequence number: 2
From zone: trust, To zone: untrust
Source addresses: 10.1.0.0/16
Destination addresses: 10.2.0.0/16
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
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.
user@member2> show security dynamic-policies
Policy: scope2-0001, action-type: permit, State: enabled, Index: 1048580,AI: disabled, Scope Policy: 4
Policy Type: Dynamic
Sequence number: 1
From zone: untrust, To zone: trust
Source addresses: 10.1.0.0/16
Destination addresses: 10.2.0.0/16
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
Policy: scope2-0001, action-type: permit, State: enabled, Index: 1048580,AI: disabled, Scope Policy: 4
Policy Type: Dynamic
Sequence number: 1
From zone: untrust, To zone: trust
Source addresses: 10.1.1.1/32
Destination addresses: 239.1.1.1/32
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
Policy: scope2–0001, action-type: permit, State: enabled, Index: 1048581,AI: disabled, Scope Policy: 5
Policy Type: Dynamic
Sequence number: 2
From zone: trust, To zone: untrust
Source addresses: 10.2.0.0/16/0
Destination addresses: 10.1.0.0/16
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
Policy: scope2–0001, action-type: permit, State: enabled, Index: 1048581,AI: disabled, Scope Policy: 5
Policy Type: Dynamic
Sequence number: 2
From zone: trust, To zone: untrust
Source addresses: 10.1.1.1/32
Destination addresses: 239.1.1.1/32
Application: Unknown
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Tunnel: INSTANCE-gvpn_133955586, Type: IPSec, Index: 133955586
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
g1on 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:
Set the communications type.
[edit security group-vpn server group g1 server-member-communication] user@host# set communications-type unicast
Set the encryption algorithm.
[edit security group-vpn server group g1 server-member-communication] user@host# set encryption-algorithm 3des-cbc
Set the member authentication.
[edit security group-vpn server group g1 server-member-communication] user@host# set sig-hash-algorithm sha1
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:
Configure the group server and members for IKE Phase 1 negotiation and Phase 2 IPsec SA. See Example: Configuring Group VPNv1 Server and Members or Example: Configuring Group VPNv1 with Server-Member Colocation.
Configure ge-0/0/1.0, which is the interface the server will use for sending multicast messages. See Junos OS Routing Protocols Library.
Configure the multicast group address 226.1.1.1. See Junos OS Routing Protocols Library.
IP multicast protocols must be configured to allow delivery of multicast traffic in the network. This example does not show multicast configuration.
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.
set security group-vpn server group g1 server-member-communication communication-type multicast set security group-vpn server group g1 server-member-communication multicast-group 226.1.1.1 set security group-vpn server group g1 server-member-communication multicast-outgoing-interface ge-0/0/1.0 set security group-vpn server group g1 server-member-communication encryption-algorithm 3des-cbc set security group-vpn server group g1 server-member-communication sig-hash-algorithm sha1
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:
Set the communications type.
[edit security group-vpn server group g1 server-member-communication] user@host# set communication-type multicast
Set the multicast group.
[edit security group-vpn server group g1 server-member-communication] user@host# set multicast-group 226.1.1.1
Set the interface for outgoing multicast messages.
[edit security group-vpn server group g1 server-member-communication] user@host# set multicast-outgoing-interface ge-0/0/1.0
Set the encryption algorithm.
[edit security group-vpn server group g1 server-member-communication] user@host# set encryption-algorithm 3des-cbc
Set the member authentication.
[edit security group-vpn server group g1 server-member-communication] user@host# set sig-hash-algorithm sha1
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.
[edit] user@host# show security group-vpn server group g1 server-member-communication communication-type multicast; multicast-group 226.1.1.1; multicast-outgoing-interface ge-0/0/1.0; encryption-algorithm 3des-cbc; sig-hash-algorithm sha1;
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:
Configure the Juniper Networks security devices for network communication.
Configure network interfaces on server and member devices. See Interfaces User Guide for Security Devices.
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.
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.
set interfaces lo0 unit 0 family inet address 20.0.0.1/32 set interfaces ge-0/1/0 unit 0 family inet address 10.1.0.1/32 set security group-vpn member ike proposal prop1 authentication-method pre-shared-keys set security group-vpn member ike proposal prop1 dh-group group2 set security group-vpn member ike proposal prop1 authentication-algorithm sha1 set security group-vpn member ike proposal prop1 encryption-algorithm 3des-cbc set security group-vpn member ike policy pol1 mode main set security group-vpn member ike policy pol1 proposals prop1 set security group-vpn member ike policy pol1 pre-shared-key ascii-text "$9$c1gr K8-VYZUHX7UHqmF3Sre" set security group-vpn member ike gateway g1 ike-policy pol1 set security group-vpn member ike gateway g1 address 20.0.0.1 set security group-vpn member ike gateway g1 local-address 10.1.0.1 set security group-vpn member ipsec vpn v1 ike-gateway g1 set security group-vpn member ipsec vpn v1 group-vpn-external-interface ge-0/1/0 set security group-vpn member ipsec vpn v1 group 1 set security group-vpn server ike proposal srv-prop authentication-method pre-shared-keys set security group-vpn server ike proposal srv-prop dh-group group2 set security group-vpn server ike proposal srv-prop authentication-algorithm sha1 set security group-vpn server ike proposal srv-prop encryption-algorithm 3des-cbc set security group-vpn server ike policy srv-pol mode main set security group-vpn server ike policy srv-pol proposals srv-prop set security group-vpn server ike policy srv-pol pre-shared-key ascii-text "$9$c 1grK8-VYZUHX7UHqmF3Sre" set security group-vpn server ike gateway gw1 ike-policy srv-pol set security group-vpn server ike gateway gw1 address 10.1.0.1 set security group-vpn server ike gateway gw2 ike-policy srv-pol set security group-vpn server ike gateway gw2 address 10.2.0.1 set security group-vpn server ipsec proposal group-prop authentication-algorithm hmac-sha1-96 set security group-vpn server ipsec proposal group-prop encryption-algorithm 3des-cbc set security group-vpn server ipsec proposal group-prop lifetime-seconds 3600 set security group-vpn server group grp1 group-id 1 set security group-vpn server group grp1 ike-gateway gw1 set security group-vpn server group grp1 ike-gateway gw2 set security group-vpn server group grp1 anti-replay-time-window 120 set security group-vpn server group grp1 server-address 20.0.0.1 set security group-vpn server group grp1 server-member-communication communication-type unicast set security group-vpn server group grp1 server-member-communication encryption-algorithm aes-128-cbc set security group-vpn server group grp1 server-member-communication sig-hash-algorithm md5 set security group-vpn server group grp1 server-member-communication certificate srv-cert set security group-vpn server group grp1 ipsec-sa group-sa proposal group-prop set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 source 10.1.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 destination 10.2.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p1 protocol 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 source 10.2.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 destination 10.1.0.0/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p2 protocol 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 source 10.1.1.1/16 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 destination 239.1.1.1/32 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 source-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 destination-port 0 set security group-vpn server group grp1 ipsec-sa group-sa match-policy p3 protocol 0 set security group-vpn co-location set security group-vpn member ipsec vpn v1 ike-gateway g1 set security group-vpn member ipsec vpn v1 group-vpn-external-interface ge-0/1/0 set security address-book book1 address 10_subnet 10.0.0.0/8 set security address-book book1 attach zone trust set security address-book book2 address 10_subnet 10.0.0.0/8 set security address-book book2 attach zone untrust set security policies from-zone trust to-zone untrust policy scope1 match source-address 10_subnet set security policies from-zone trust to-zone untrust policy scope1 match destination-address 10_subnet set security policies from-zone trust to-zone untrust policy scope1 match application any set security policies from-zone trust to-zone untrust policy scope1 then permit tunnel ipsec-group-vpn v1 set security policies from-zone untrust to-zone trust policy scope1 match source-address 10_subnet set security policies from-zone untrust to-zone trust policy scope1 match destination-address 10_subnet set security policies from-zone untrust to-zone trust policy scope1 match application any set security policies from-zone untrust to-zone trust policy scope1 then permit tunnel ipsec-group-vpn v1
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:
Configure the loopback address on the device.
[edit interfaces] user@host# set lo0 unit 0 family inet address 20.0.0.1/32
Configure the interface that member1 uses to connect to the MPLS network.
[edit interfaces] user@host# set ge-0/1/0 unit 0 family inet address 10.1.0.1/32
Configure group VPN colocation on the device.
[edit security group-vpn] user@host# set co-location
Configure IKE Phase 1 SA for the server (this configuration must match the Phase 1 SA configured on group members).
[edit security group-vpn server ike proposal srv-prop] user@host# set authentication-method pre-shared-keys user@host# set dh-group group2 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm 3des-cbc
Define the IKE policy and set the remote gateways.
[edit security group-vpn server ike] user@host# set policy srv-pol proposals srv-prop mode main pre-shared-key ascii-text "$9$c1grK8-VYZUHX7UHqmF3Sre" user@host# set gateway gw1 ike-policy srv-pol address 10.1.0.1 user@host# set gateway gw2 ike-policy srv-pol address 10.2.0.1
Configure the Phase 2 SA exchange for the server.
[edit security group-vpn server ipsec proposal group-prop] user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 3600
Configure the group identifier, IKE gateway, antireplay time, and server address on the server.
[edit security group-vpn server group grp1] user@host# set group-id 1 anti-replay-time-window 120 server-address 20.0.0.1 user@host#set ike-gateway gw1 user@host#set ike-gateway gw2
Configure server to member communications.
[edit security group-vpn server group grp1] user@host# set server-member-communication communication-type unicast encryption-algorithm aes-128-cbc sig-hash-algorithm md5 certificate “srv-cert”
Configure the group policies to be downloaded to group members.
[edit security group-vpn server group grp1 ipsec-sa group-sa ] user@host# set proposal group-prop match-policy p1 source 10.1.0.0/16 destination 10.2.0.0/16 source-port 0 destination-port 0 protocol 0 user@host# set proposal group-prop match-policy p2 source 10.2.0.0/16 destination 10.1.0.0/16 source-port 0 destination-port 0 protocol 0 user@host# set proposal group-prop match-policy p3 source 10.1.1.1/16 destination 239.1.1.1/32 source-port 0 destination-port 0 protocol 0
Configure Phase 1 SA for member1 (this configuration must match the Phase 1 SA configured for the group server).
[edit security group-vpn member ike proposal prop1] user@host# set authentication-method pre-shared-keys user@host# set dh-group group2 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm 3des-cbc
Define the policy and set the remote gateway for member1.
[edit security group-vpn member ike] user@host# set policy pol1 mode main proposals prop1 pre-shared-key ascii-text "$9$c1grK8-VYZUHX7UHqmF3Sre" user@host# set gateway g1 ike-policy pol1 address 20.0.0.1 local-address 10.1.0.1
Configure the group identifier, IKE gateway, and interface for member1.
[edit security group-vpn member ipsec] user@host# set vpn v1 group 1 ike-gateway g1 group-vpn-external-interface ge-0/1/0
Create address books and attach them to zones.
[edit security address-book book1] user@member1# set address 10_subnet 10.0.0.0/8 user@member1# set attach zone trust
[edit security address-book book2] user@member1# set address 10_subnet 10.0.0.0/8 user@member1# set attach zone untrust
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.
[edit security policies from-zone trust to-zone untrust] user@member1# set policy scope1 match source-address 10_subnet destination-address 10_subnet application any user@member1# set policy scope1 then permit tunnel ipsec-group-vpn v1
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.
[edit security policies from-zone untrust to-zone trust] user@member1# set policy scope1 match source-address 10_subnet destination-address 10_subnet application any user@member1# set policy scope1 then permit tunnel ipsec-group-vpn v1
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.
[edit]
user@host# show security group-vpn
member {
ike {
proposal prop1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy pol1 {
mode main;
proposals prop1;
pre-shared-key ascii-text "$9$c1grK8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
gateway g1 {
ike-policy pol1;
address 20.0.0.1;
local-address 10.1.0.1;
}
}
ipsec {
vpn v1 {
ike-gateway g1;
group-vpn-external-interface ge-0/1/0;
group 1;
}
}
}
server {
ike {
proposal srv-prop {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy srv-pol {
mode main;
proposals srv-prop;
pre-shared-key ascii-text "$9$c1grK8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
gateway gw1 {
ike-policy srv-pol;
address 10.1.0.1;
}
gateway gw2 {
ike-policy srv-pol;
address 10.2.0.1;
}
}
ipsec {
proposal group-prop {
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
}
group grp1 {
group-id 1;
ike-gateway gw1;
ike-gateway gw2;
anti-replay-time-window 120;
server-address 20.0.0.1;
server-member-communication {
communication-type unicast;
encryption-algorithm aes-128-cbc;
sig-hash-algorithm md5;
certificate srv-cert;
}
ipsec-sa group-sa {
proposal group-prop;
match-policy p1 {
source 10.1.0.0/16;
destination 10.2.0.0/16;
source-port 0;
destination-port 0;
protocol 0;
}
match-policy p2 {
source 10.2.0.0/16;
destination 10.1.0.0/16;
source-port 0;
destination-port 0;
protocol 0;
}
match-policy p3 {
source 10.1.1.1/16;
destination 239.1.1.1/32;
source-port 0;
destination-port 0;
protocol 0;
}
}
}
}
co-location;
[edit]
user@host# show security policies
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy scope1 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v1;
}
}
}
}
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
policy scope1 {
match {
source-address 10_subnet;
destination-address 10_subnet;
application any;
}
then {
permit {
tunnel {
ipsec-group-vpn v1;
}
}
}
}
}
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
- Verifying Group VPN Server Security Associations for IKE
- Verifying Group VPN Server Security Associations for IPsec
- Verifying Group VPN Member Security Associations for IKE
- Verifying Group VPN Member Security Associations for IPsec
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.
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.