Below is a good template to use when creating a Site-to-Site VPN Form but the settings are something you want to implement. I have a spreadsheet that has what you see below in it but environments are different so you can make whatever changes are need to fit your environment.
I’m not going to get into each option. There’s alot of great material out there that will explain each one.
I’ll start with IKEv1 but this should not be used but if you have to use it, use these settings to be the most secure.
#IKEv1
Phase 1 – IKEv1 Properties | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
Phase 2 – IPSec Properties | ||||||||||||||||||||||||
|
#IKEv2
This is the option you should always use.
Note for IKEv2, there’s a Legacy Suite because there are devices out there that don’t support the NGE Suite. Also if you see different options listed it’s because either there are devices out there that don’t support it or clients didn’t support it so you have to be backwards compatible. The most imporant thing is be as secure as possible.
IKEv2 Policies | ||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||
IKEv2 IPSec Proposals | ||||||||||||||||||||||||||||||||
|
#Cisco Config
V2:
crypto ikev2 policy 1 encryption aes-gcm-256 group 21 20 19 24 prf sha512 sha384 sha256 lifetime seconds 86400 crypto ikev2 policy 2 encryption aes-256 integrity sha512 sha384 sha256 group 24 14 prf sha512 sha384 sha256 lifetime seconds 86400 crypto ipsec ikev2 ipsec-proposal ESP-AES-GCM-256-SHA protocol esp encryption aes-gcm-256 protocol esp integrity sha-512 sha-384 sha-256 crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA protocol esp encryption aes-256 protocol esp integrity sha-512 sha-384 sha-256 crypto map outside_map XX set ikev2 transform-set ESP-AES-GCM-256-SHA crypto map outside_map XX set security-association lifetime seconds 3600 crypto map outside_map XX set pfs group5 group-policy XXXXXPolicy attributes vpn-filter value XXXXX_FILTER vpn-tunnel-protocol ikev2
V1:
crypto ikev1 policy 1 authentication pre-share encryption aes-256 hash sha group 5 lifetime 3600 crypto map outside_map XX set ikev1 transform-set ESP-AES-256-SHA crypto map outside_map XX set security-association lifetime seconds 3600 crypto map outside_map XX set pfs group5 crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
#Diffie Helman Groups
Diffie-Hellman group 1 – 768 bit modulus – AVOID
Diffie-Hellman group 2 – 1024 bit modulus – AVOID
Diffie-Hellman group 5 – 1536 bit modulus – AVOID (except when using IKEv1, this should be used)
Diffie-Hellman group 14 – 2048 bit modulus – MINIMUM ACCEPTABLE
Diffie-Hellman group 19 – 256 bit elliptic curve – ACCEPTABLE
Diffie-Hellman group 20 – 384 bit elliptic curve – Next Generation Encryption
Diffie-Hellman group 21 – 521 bit elliptic curve – Next Generation Encryption
Diffie-Hellman group 24 – 2048-bit modulus & 256-bit prime order subgroup – Next Generation Encryption
For 128-bit key encryption or authentication algorithms use Diffie-Hellman groups 5, 14, 19, 20 or 24
For 256-bit key encryption or authentication algorithms use use Diffie-Hellman group 21 or 24
# Recommendations for Cryptographic Algorithms – From Cisco
Algorithm | Operation | Status | Alternative | QCR1 | Mitigation |
---|---|---|---|---|---|
DES | Encryption | Avoid | AES | — | — |
3DES | Encryption | Legacy | AES | — | Short key lifetime |
RC4 | Encryption | Avoid | AES | — | — |
AES-CBC mode
AES-GCM mode |
Encryption
Authenticated encryption |
Acceptable
NGE2 |
AES-GCM
— |
✓ (256-bit)
✓ (256-bit) |
—
— |
DH-768, -1024
RSA-768, -1024 DSA-768, -1024 |
Key exchange
Encryption Authentication |
Avoid | DH-3072 (Group 15)
RSA-3072 DSA-3072 |
—
— — |
—
— — |
DH-2048
RSA-2048 DSA-2048 |
Key exchange
Encryption Authentication |
Acceptable | ECDH-256
— ECDSA-256 |
—
— — |
—
— — |
DH-3072
RSA-3072 DSA-3072 |
Key exchange
Encryption Authentication |
Acceptable | ECDH-256
— ECDSA-256 |
—
— — |
—
— — |
MD5 | Integrity | Avoid | SHA-256 | — | — |
SHA-1 | Integrity | Legacy | SHA-256 | — | — |
SHA-256
SHA-384 SHA-512 |
Integrity | NGE | SHA-384
— — |
—
✓ ✓ |
—
— — |
HMAC-MD5 | Integrity | Legacy | HMAC-SHA-256 | — | Short key lifetime |
HMAC-SHA-1 | Integrity | Acceptable | HMAC-SHA-256 | — | — |
HMAC-SHA-256 | Integrity | NGE | — | ✓ | — |
ECDH-256
ECDSA-256 |
Key exchange
Authentication |
Acceptable | ECDH-384
ECDSA-384 |
—
— |
—
— |
ECDH-384
ECDSA-384 |
Key exchange
Authentication |
NGE | —
— |
—
— |
—
— |
1. QCR = quantum computer resistant. |
Avoid: Algorithms that are marked as Avoid do not provide adequate security against modern threats and should not be used to protect sensitive information. It is recommended that these algorithms be replaced with stronger algorithms.
Legacy: Legacy algorithms provide a marginal but acceptable security level. They should be used only when no better alternatives are available, such as when interoperating with legacy equipment. It is recommended that these legacy algorithms be phased out and replaced with stronger algorithms.
Acceptable: Acceptable algorithms provide adequate security.
Next generation encryption (NGE): NGE algorithms are expected to meet the security and scalability requirements of the next two decades. For more information, see Next Generation Encryption.
Quantum computer resistant (QCR): As of October 2015, there has been attention on quantum computers (QCs) and their potential impact on current cryptography standards. Although practical QCs would pose a threat to crypto standards for public-key infrastructure (PKI) key exchange and encryption, no one has demonstrated a practical quantum computer yet. It is an area of active research and growing interest. Although it is possible, it can’t be said with certainty whether practical QCs will be built in the future. An algorithm that would be secure even after a QC is built is said to have postquantum security or be quantum computer resistant (QCR). AES-256, SHA-384, and SHA-512 are believed to have postquantum security. There are public key algorithms that are believed to have postquantum security too, but there are no standards for their use in Internet protocols yet.
Cisco is committed to providing the best cryptographic standards to our customers. NGE still includes the best standards that one can implement today to meet the security and scalability requirements for network security in the years to come or to interoperate with the cryptography that will be deployed in that time frame. The biggest threat to crypto nowadays is another high-impact implementation issue, not a QC. So while we need to get smart about postquantum crypto, we need to do it in a way that doesn’t create more complexity and less robustness. Cisco will remain actively involved in quantum resistant cryptography and will provide updates as postquantum secure algorithms are standardized.
Short key lifetime: Use of a short key lifetime improves the security of legacy ciphers that are used on high-speed connections. In IPsec, a 24-hour lifetime is typical. A 30-minute lifetime improves the security of legacy algorithms and is recommended.