This document will explain how to deploy Cisco GETVPN if you are new to GETVPN then first go through Cisco GETVPN Concept Explained this covers the basic fundamentals of GETVPN to help you understand the concept easily.
GETVPN Deployment Configuration
COOP Server Exportable RSA Keys
The preceding configuration is sufficient for a standalone KS in an enterprise network. This section describes the configuration of a COOP KS. Before deploying COOP KS configurations, consider the following:
- Generate RSA keys in the primary KS (as required for rekeys) and export both private and public keys to all the COOP KSs. This is required in case the primary KS goes down; the rekeys sent by the newly elected primary KS will still be properly verified by the GM.
- Election between the KSs is based on the highest-priority value configured. If they are same, it is based on highest IP address. It is suggested to configure priorities for selecting the primary KS for easy setup and troubleshooting.
- Periodic ISAKMP keep-alive (dead peer detection, or DPD) must be configured on the COOP KSs so that the primary KS can track the secondary KS state.
- Rekey configuration, policies, and anti-replay configurations must be the same for all KSs. This is not done automatically in the current phase of GETVPN. The user must manually track configurations.
- Exporting RSA Key from Key Server to Group Member:
- Public key generated in the RSA key pair, is sent to the GM at the registration.
- The re-keys are signed by the private key of the KS and GM verifies the signature in the re-key with the public key of the KS.
- Exporting RSA Key between Key Servers:
- One of the key server in the redundancy group should generate the exportable RSA keys and copy those keys to other key servers.
KS Configuration using Pre-shared key
GM Configuration
GETVPN Platform Support
Scalability & Performance
- GETVPN Provides complete segregation of control and data plane.
- Key Server is responsible to maintain the control plane (key management) and GM is responsible to handle the data plane (actual user traffic).
- KS and GM cannot be configured on same IOS device.
- KS should be properly sized for number of branches (scale) in the network.
- GM should be properly sized for traffic throughput at each branch.
GETVPN Policy Considerations
What should not be protected with Group Security?
- Control Plane
- Internet Key Exchange/Group Domain of Interpretation
- Routing Exchanges with Service Provider routers (OSPF, BGP)
- Diagnostic or troubleshooting traffic (ICMP)
What needs to be protected with Group Security?
- Data Plane
- Enterprise Transactions
- Enterprise Sensitive Multicast Streams
What may already be protected?
- Management Plane
- SSH, TACACS, HTTPS
Deployment Best Practices
IKE/IPSec
- Use specific pre-shared keys for all the GMs and KSs instead of using default key
KS
- Always use COOP KSs
- Set the huge buffer to 65535 and add 10 buffers to permanent buffer list
- Configure periodic DPDs between the COOP KSs
- Enable GM authorization
Policy
- Aggregate the permit access-list entries to reduce the entries
- Enable Time-Based Anti-Replay
- Avoid re-encrypting traffic which is already encrypted (SSH, HTTPS)
Registration
- Distribute GM registration to multiple KSs by arranging the KS order in the configuration
Rekey Timers
- Set TEK lifetime to 7200 Seconds
- Set KEK lifetime to 86400 Seconds
Refer the following links if you are preparing for an interview.
Cisco ISE basic interview question and answer
Cisco FirePower (FTD) Interview Questions and Answers