Virtual private network (VPN) connections establish secure tunnels between endpoints through public networks, such as Internet.

This chapter applies only to site-to-site VPN. on Firepower threat defense devices.

It describes the Internet protocol security association and key management protocol (ISAKMP or IKE) and SSL standard for building site-to-site VPN. Site-to-site VPN, on 7000 and 8000 series devices is described in gateway VPN as gateway VPN or Firepower VPN. in the Firepower management cente

VPN Types

VPN Basics

VPN Packet Flow

VPN Licensing

How Secure Should a VPN Connection Be?

The Firepower Management Center supports the following types of VPN connections: site-to-site VPN.

on Firepower threat defense devices Site-to-site VPN connects to networks in different geographical locations. You can create site-to-site IPsec connections between managed devices and other Cisco or third-party counterparts that meet all relevant standards. These peers can have any combination of internal and external IPv4 and IPv6 addresses. Site-to-site tunnels are setup by using Internet Protocol Security (IPsec) protocol suite and IKEv1 or IKEv2.

After the VPN connection is established, the host behind the local gateway can connect to the host behind the remote gateway through a secure VPN tunnel.Site-to-site VPNs on 7000 and 8000 Series devices.

These site-to-site VPN are called gateways VPN or Firepower VPN. in the Firepower management center For information about such VPN connections, see Gateway VPN.

VPN Basics

Tunnels can use public TCP / IP networks, such as Internet, to create secure connections between remote users and private enterprise networks. Each secure connection is called a tunnel.

VPN technology based on IPsec uses Internet security association and key management protocol (ISAKMP or IKE) and IPsec tunnel standard to build and manage tunnels. ISAKMP and IPsec complete the following tasks:

Negotiate tunnel parameters.

Establish tunnels.

Authenticate users and data.

Manage security keys.

Encrypt and decrypt data.

Manage data transfer across the tunnel.

To Manage data transfer inbound and outbound as a tunnel endpoint or router.

The device in the VPN acts as a two-way tunnel endpoint. It receives normal packets from a private network, then encapsulate them, create a tunnel, and send them to the other end of the tunnel where they are not encapsulated and sent to their final destination. It can also receive the encapsulated data packets from the public network and decapsulate them and send them to the final destination on the private network.

After establishing a site-to-site VPN connection, the host behind the local gateway can connect to the host behind the remote gateway through a secure VPN tunnel. The connection consists of the IP address and hostname of the two gateways, the subnet behind them, and the method of mutual verification between the two gateways.

Internet Key Exchange (IKE)

IPsec

Internet Key Exchange (IKE)

Internet key Exchange (IKE) is a key management protocol for authentication of IPsec peers, negotiation and distribution of IPsec encryption keys, and automatic establishment of IPsec security associations (SA).

IKE negotiation consists of two stages. Stage 1 negotiates the security association between the two IKE peers, which enables the peer to communicate securely in stage 2. During phase 2 negotiations, IKE establishes SA. for other applications, such as IPsec Proposals are used in both stages when negotiating connections.

The IKE policy is a set of algorithms that two peers are used to protect the IKE negotiation between them. IKE negotiation begins with a common (shared) IKE policy for each peer. This policy describes which security parameters to protect the subsequent IKE negotiation. For IKE version 1 (IKEv1), the IKE policy contains a set of algorithms and an array of modes. Unlike IKEv1, in the IKEv2 policy, you can select multiple algorithms and model arrays, which you can select during the first phase of the negotiation. While you may want to use different policies to provide a higher priority for your most desirable options, you can create a single IKE policy. For site-to-site VPNs, you can create a single IKE policy.

To define an IKE policy, specify:

Unique priority (1 to 65,543, highest priority 1).

The encryption method negotiated by IKE is used to protect data and ensure privacy.

The hash message authentication code (HMAC) method (called integrity algorithm in IKEv2) ensures the identity of the sender and that the message is not modified during transmission.

For IKEv2, a separate pseudorandom function(PRF)is used as an algorithm to derive the key materials and hash operations required for IKEv2 tunnel encryption. The options are the same as for the hash algorithm.

The diffie-hellman group is used to determine the strength of the encryption key determination algorithm.

Devices use this algorithm to derive encryption and hash keys.

An authentication method used to ensure the identity of peers

Note

Only preshared keys are used for authentication.

The time limit for the device to use the encryption key before replacement.

When the IKE negotiation begins, the peer to initiate the negotiation sends all of its policies to the remote peer, and the remote peer searches for a match with its own policy in order of priority. If the IKE policy has the same encryption, the hash (the integrity of IKEv2 and the PRF), the authentication, and the Diffie-Hellman value, and the SA lifetime is less than or equal to the lifetime in the transmitted policy, there is a match between the IKE policies. If the life cycle is not the same, the shorter the life cycle-the policy from the remote peer-applies. By default, the Firepower Management Center deploys the lowest priority IKEv1 policy for all VPN endpoints to ensure successful negotiation.

IPsec

IPsec is one of the safest ways to set up VPN. IPsec provides data encryption at the IP packet level and provides powerful standards-based security solutions. Use IPsec, data to transmit over a public network through a tunnel. Tunnel is a secure logical communication path between two peers. The flow into IPsec tunnel is protected by the combination of security protocol and algorithm.

The IPsec proposal policy defines the settings required for the IPsec tunnel. The IPsec proposal is a collection of one or more encryption maps that are applied to the VPN interface on the device. Encryption mapping combines all the components required to set up IPsec security associations, including:

The proposal (or transformation set) is a combination of security protocols and algorithms to protect traffic in IPsec tunnels. During the IPsec security association (SA) negotiation, peers search for the same proposal at both peers. When found, it will be applied to create a SA, to protect the data flow in the access list of the encrypted map, thereby protecting traffic in the VPN. IKEv1 and IKEv2 have separate IPsec proposals. In the IKEv1 proposal (or transformation set), you can set a value for each parameter. For IKEv2 proposals, you can configure multiple encryption and integration algorithms for a single proposal.

Encryption mappings combine all the components required to set up IPsec security associations(SA), including IPsec rules, proposals, remote peers, and other parameters required to define IPsecSA. When two peers attempt to establish SA, they must each have at least one compatible cryptographic mapping entry.

When an unknown remote peer attempts to start a IPsec security association with the local center, the dynamic password mapping policy will be used in the site-to-site VPN. The hub cannot initiate security association negotiation. Dynamic cryptography policy allows remote nodes to exchange IPsec communication with local centers, even if the hub does not know the identity of the remote nodes. A dynamic password mapping policy essentially creates a password mapping entry without configuring all the parameters. The lost parameters are then dynamically configured (as a result of IPSec negotiations) to match the needs of remote peers.

The dynamic encryption mapping strategy is only suitable for central radiation and full mesh VPN topology. In a point-to-point or full-mesh VPN topology, you can only apply static encryption mapping policies. By using two devices to create a central radiation topology, the dynamic encryption mapping is simulated in a point-to-point topology. Specify a dynamic IP address for the spoke and enable dynamic encryption mapping on this topology.

VPN Packet Flow

On Firepower threat defense devices, by default, no traffic is allowed to pass access control without explicit permission. VPN tunnel traffic is also not passed to the endpoint until it passes through Snort. Incoming tunnel packets are decrypted before they are sent to the Snort process. Snort processes outgoing packets before encryption.

The access control of the protected network that identifies each endpoint node of the VPN tunnel determines which traffic passes through the Firepower threat defense device and reaches the endpoint.

In addition, the system does not send tunnel traffic to the public source when the tunnel is down.

VPN Licensing

There is no specific licensing for enabling Firepower Threat Defense VPN, it is available by default.

The Firepower management center determines whether to allow or prevent the use of strong encryption on the Firepower threat defense device based on the attributes provided by the smart license server.

This is controlled by selecting the export control feature on the Allow device when you register with the Cisco Smart License Manager. Strong encryption cannot be used if you are using an evaluation license or if the export control feature is not enabled.

How Secure Should a VPN Connection Be?

Because the VPN tunnel typically traverses the public network, itundefineds probably the Internet, so you need to encrypt the connection to protect traffic. You can use the IKE policy and IPsec proposal to define the encryption and other security technologies to apply.

If your device license allows you to apply strong encryption, you can select various encryption and hash algorithms and DiffieHellman groups. However, as a general rule, the stronger the encryption applied to the tunnel, the worse the system performance. Balance between security and performance and provide adequate protection without affecting efficiency.

We are unable to provide specific guidance on which options to choose. If you operate within a larger company or other organization, you may have defined the standards you need to meet. If not, take the time to study options.

The following topics explain the available options.

Deciding Which Encryption Algorithm to Use

Deciding Which Hash Algorithms to Use

Deciding Which Diffie-Hellman Modulus Group to Use

Deciding Which Encryption Algorithm to Use

When deciding which encryption algorithms to use for the IKE policy or IPsec proposal, your choice is limited to algorithms supported by the devices in the VPN.

You can configure a variety of encryption algorithms for IKEv2,. The system sets the order from the safest to the least secure and uses that order to negotiate with peers. You can only select one option for IKEv1.

For IPsec proposals, the algorithm is used by Encapsulated Security Protocol(ESP), which provides authentication, encryption, and back-replay services. ESP is IP protocol type 50. In IKEv1IPsec proposal, the algorithm name is prefixed with ESP.

If your device license qualifies for strong encryption, you can choose from the following encryption algorithms. If you are not qualified for strong encryption, you can select DES only.

The advanced encryption standard in AES-GCM- (IKEv2. only) Galois / Counter mode is a block cipher operation mode, which provides confidentiality and data source authentication, and provides higher security than AES.

AES-GCM offers three different key advantages: 128-bit, 192-bit and 256-bit keys. Longer keys provide higher security, but performance degrades. GCM is the AES mode needed to support NSA Suite B. NSA Suite B is a set of encryption algorithms that devices must support in order to meet the federal encryption strength standard. .

AES-GMAC- (IKEv2 IPsec proposal only.) Advanced encryption standard Galois message authentication code is a block password operation mode, which only provides data source authentication. It is a variant of AES-GCM that allows data authentication without encrypting data.

AES-GMAC offers three different key advantages: 128-bit, 192-bit and 256-bit keys.

AES-Advanced Encryption Standard is a symmetric cryptography algorithm, which provides higher security than DES and is more efficient than 3DES in computation. AES offers three different key advantages: 128-bit, 192-bit and 256-bit keys. Longer keys provide higher security, but performance degrades. 3DES-Triple DES uses a 56-bit key to encrypt three times, which is more secure than DES because it uses a different key to process each block three times. However, it uses more system resources and is slower than DES.

DES-Data Encryption Standard uses 56-bit key encryption, which is a symmetric key block algorithm. It is faster than 3DES and uses fewer system resources, but it is not very secure either. If you do not need strong data confidentiality and need to consider system resources or speed, select DES.

Null-A null encryption algorithm provides unencrypted authentication. This is usually used only for testing purposes. Decide which hash algorithm to use in the IKE policy, the hash algorithm creates a message digest to ensure message integrity.

In IKEv2, the hash algorithm is divided into two options, one for integrity algorithm and the other for pseudorandom function (PRF). In the IPsec proposal, the encapsulation security protocol (ESP) uses hash algorithm for authentication. In IKEv2 IPsec Proposals, this is called an integrity hash.

In the IKEv1 IPsec proposal, the algorithm name is prefixed with ESP- and there is a-HMAC suffix (for hash method authentication code). You can configure multiple hash algorithms for IKEv2. The system sets the order from the safest to the least secure and uses that order to negotiate with peers. You can only select one option for IKEv1.

You can choose from the following hash algorithms.

SHA (Secure Hash Algorithm)-generates a 160-bit summary. SHA is more resistant to violent attacks than MD5. However, it is also more resource-intensive than MD5. For implementations that require the highest security level, use the SHA Hash algorithm.

Standard SHA (SHA1) produces a 160-bit summary. The following SHA-2 options are more secure and available for the IKEv2 configuration. If you are implementing the NSA Suite B encryption specification, select one of them.

SHA256-Specifies the secure hash algorithm SHA 2 with a 256-bit digest.

SH3 sequencer 84-The secure hash algorithm SHA 2 is specified using a 384-bit digest. SHA512-Specifies the secure hash algorithm SHA 2 with a 512-bit digest. MD5 (Message Digest 5)-A 128-bit summary is generated.

MD5 uses less processing time to achieve faster overall performance than SHA, but it is considered weaker than SHA.

Null or None (NULL, ESP-NONE)-(IPsec only). ) An empty hash algorithm; this is typically used for test purposes only.

However, if one of the AES-GCM/ GMAC options is selected as an encryption algorithm, an empty integrity algorithm should be selected. Even if you select a non-null option, the integrity hash of these encryption standards is ignored.

deciding which Diffie-Hellman model array to use You can generate an IPsec Security Association (SA) key using the following Diffie-Hellman key derivation algorithm.

Each group has a different size modulus. A larger modulus provides higher security, but requires more processing time. You must have a matching mode array on both peers.

If AES encryption is selected to support the large key size required by the AES, the Diffie-Hellman (DH) Group 5 or later should be used. The IKEv1 policy only allows groups 1,2, and 5. To implement the NSA Suite B encryption specification, use IKEv2 and select one of the elliptic curve Diffie-Hellman (ECDH) options:19,20, or 21.

The elliptic curve option and the group using the 2048-bit modulus are less attacked and the like as the logjam. For IKEv2, you can configure multiple groups. The system will set the order from the most secure to the most unsecure and use the order to negotiate with the peer. For IKEv1, you can only select one option.

1—Diffie-Hellman Group 1: 768-bit modulus.

2—Diffie-Hellman Group 2: 1024-bit modulus.

5—Diffie-Hellman Group 5: 1536-bit modulus. Considered good protection for 128-bit keys.

14—Diffie-Hellman Group 14: 2048 bit modulus. Considered good protection for 192-bit keys.

19—Diffie-Hellman Group 19: 256 bit elliptic curve.

20—Diffie-Hellman Group 20: 384 bit elliptic curve.

21—Diffie-Hellman Group 21: 521 bit elliptic curve.

24—Diffie-Hellman Group 24: 2048-bit modulus and 256-bit prime order subgroup