28-25
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Troubleshooting GET VPN Configurations
Step 6 In the Site-to-Site VPN Manager, select the GET VPN topology, then select Group Encryption Policy.
Deselect Receive Only. This turns off SA receive-only mode at the topology level.
Step 7 Deploy the configuration changes to all devices in the VPN. Now the GET VPN should be operating in
fully encrypted mode for the original group members that you tested. Any new members that you added
with passive SA mode enabled should be receiving encrypted traffic and sending clear text traffic.
Step 8 Use the following process to verify the new devices and to turn off passive mode. You can follow this
process for all new devices at once, or you can do smaller groups of them at a time. You can also use this
process for new group members as you extend your network. Iterate the following steps as appropriate:
a. Verify that the new group members are functioning properly using the same techniques that you used
to verify the original group members.
b. When you are ready to move a set of group members to fully-encrypted mode, in the Site-to-Site
VPN Manager, select the GET VPN topology and select Group Members.
c. Select all passive mode group members that should use full encryption, right-click and select Edit
Passive SA Mode. Deselect the Enable Passive SA Mode option and click OK.
d. Deploy configurations to all devices in the VPN, not just the ones whose passive mode you changed.
Normally, you should not deploy to less than all devices in a VPN.
Troubleshooting GET VPN Configurations
If after provisioning and deploying GET VPN using Security Manager, the GET VPN is not working,
check the following:
•Ensure that the RSA key is synchronized among all cooperative key servers (that is, the RSA key is
the same). For information on how to synchronize keys, see Generating and Synchronizing RSA
Keys, page 28-13.
•If desired traffic is not being encrypted, make sure the key server security policy ACL (security
association) has a permit ACE for the desired traffic. For asymmetric ACEs (where the source and
destination addresses are different), ensure that there is a mirrored ACE (with the source and
destination addresses reversed). For more information, see Understanding the GET VPN Security
Policy and Security Associations, page 28-10.
•For multicast rekey, make sure that the network is multicast enabled and that all key servers and most
group members are configured to enable multicast. You must enable multicast on the devices
directly; Security Manager does not provision the commands required to enable multicast. For more
information, see Choosing the Rekey Transport Mechanism, page 28-6.
•When using multicast rekey, check whether there is a deny ACE in the key server security ACL for
the multicast group address to prevent encryption of multicast rekey messages.
•Check that the local security ACL on the group member has only deny ACEs. If you include a permit
statement in an attempt to identify traffic that should be encrypted, the matching traffic is actually
dropped because there is no corresponding IPsec SA. Because the permit entry is defined in the
group member, the key server is not aware of it and cannot generate the required IPsec SA. For more
information, see Understanding the GET VPN Security Policy and Security Associations,
page 28-10.
•For group member authorization using certificates, check that the ISAKMP authentication uses
certificates and that a PKI policy is configured. ISAKMP identity on the group member and key
server should be set to use the distinguished name (dn).