Group VPN Interoperability with Cisco’s GET VPN

Cisco’s implementation of GDOI is called Group Encryption Transport (GET) VPN. While group VPN in Junos OS and Cisco's GET VPN are both based on RFC 3547, The Group Domain of Interpretation, there are some implementation differences that you need to be aware of when deploying GDOI in a networking environment that includes both Juniper Networks security devices and Cisco routers. This topic discusses important items to note when using Cisco routers with GET VPN and Juniper Networks security devices with group VPN.

Group servers and group members on Juniper Networks security devices cannot interoperate with Cisco GET VPN members. Group members on Juniper Networks security devices can interoperate with Cisco GET VPN servers, with the following caveats:

The group VPN in Release 10.3 of Junos OS has been tested with Cisco GET VPN servers running Version 12.4(22)T and Version 12.4(24)T.

To avoid traffic disruption, do not enable rekey on a Cisco server when the VPN group includes a Juniper Networks security device. The Cisco GET VPN server implements a proprietary ACK for unicast rekey messages. If a group member does not respond to the unicast rekey messages, the group member is removed from the group and is not able to receive rekeys. An out-of-date key causes the remote peer to treat IPsec packets as bad SPIs. The Juniper Networks security device can recover from this situation by reregistering with the server to download the new key.

Antireplay must be disabled on the Cisco server when a VPN group of more than two members includes a Juniper security device. The Cisco server supports time-based antireplay by default. A Juniper Networks security device will not be able to interoperate with a Cisco group member if time-based antireplay is used since the timestamp in the IPsec packet is proprietary. Juniper Networks security devices are not able to synchronize time with the Cisco GET VPN server and Cisco GET VPN members as the sync payload is also proprietary. Counter-based antireplay can be enabled if there are only two group members.

According to Cisco documentation, the Cisco GET VPN server triggers rekeys 90 seconds before a key expires and the Cisco GET VPN member triggers rekeys 60 seconds before a key expires. When interacting with a Cisco GET VPN server, a Juniper Networks security device member would match Cisco behavior.

A Cisco GET VPN member accepts all keys downloaded from the GET VPN server. Policies associated with the keys are dynamically installed. A policy does not have to be configured on a Cisco GET VPN member locally, but a deny policy can optionally be configured to prevent certain traffic from passing through the security policies set by the server. For example, the server can set a policy to have traffic between subnet A and subnet B be encrypted by key 1. The member can set a deny policy to allow OSPF traffic between subnet A and subnet B not be encrypted by key 1. However, the member cannot set a permit policy to allow more traffic to be protected by the key. The centralized security policy configuration does not apply to the Juniper Networks security device.

On a Juniper Networks security device, the ipsec-group-vpn configuration statement in the permit tunnel rule in a scope policy references the group VPN. This allows multiple policies referencing a VPN to share an SA. This configuration is required to interoperate with Cisco GET VPN servers.

Logical key hierarchy (LKH), a method for adding and removing group members, is not supported with group VPN on Juniper Networks security devices.

GET VPN members can be configured for cooperative key servers (COOP KSs), an ordered list of servers with which the member can register or reregister. Multiple group servers cannot be configured on group VPN members.