Threat Defense VPN IPsec Options
Note | Settings in this dialog apply to the entire topology, all tunnels, and all managed devices. |
- Crypto-Map Type
- A crypto map combines all the components required to set up IPsec security associations (SA). When two peers try to establish an SA, they must each have at least one compatible crypto map entry. The IPsec security negotiation uses the proposals defined in the crypto map entry to protect the data flows specified by that crypto map’s IPsec rules. Choose static or dynamic for this deployment's crypto-map:
-
Static—Use a static crypto map in a point-to-point or full mesh VPN topology.
-
Dynamic—Dynamic crypto-maps essentially create a crypto map entry without all the parameters configured. The missing parameters are later dynamically configured (as the result of an IPsec negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies are applicable to both hub-and-spoke and point-to-point VPN topologies. To apply these policies, specify a dynamic IP address for one of the peers in the topology and ensure that the dynamic crypto-map is enabled on this topology. In a full mesh VPN topology, you can apply only static crypto map policies.
-
- IKEv2 Mode
-
For IPsec IKEv2 only, specify the encapsulation mode for applying ESP encryption and authentication to the tunnel. This determines what part of the original IP packet has ESP applied.
-
Tunnel mode—(default) Encapsulation mode is set to tunnel mode. Tunnel mode applies ESP encryption and authentication to the entire original IP packet (IP header and data), hiding the ultimate source and destination addresses and becoming the payload in a new IP packet.
The major advantage of tunnel mode is that you don’t need to modify the end systems to receive the benefits of IPsec. This mode allows a network device, such as a router, to act as an IPsec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPsec tunnel. The destination router decrypts the original IP datagram and forwards it onto the destination system. Tunnel mode also protects against traffic analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.
-
Transport preferred—Encapsulation mode is set to transport mode with an option to fall back to tunnel mode if the peer doesn’t support it. In transport mode only the IP payload is encrypted, and the original IP headers are left intact. Therefore, the admin must select a protected network that matches the VPN interface IP address.
This mode has the advantages of adding only a few bytes to each packet and allowing devices on the public network to see the final source and destination of the packet. With transport mode, you can enable special processing (for example, QoS) on the intermediate network based on the information in the IP header. However, the layer 4 header is encrypted, which limits examination of the packet.
-
Transport required— Encapsulation mode is set to transport mode only, falling back to tunnel mode is allowed. If the endpoints can’t successfully negotiate transport mode, due to one endpoint not supporting it, the VPN connection is not made.
-
- Proposals
- Click Edit (
) to specify the proposals for your chosen IKEv1 or IKEv2 method. Select from the available IKEv1 IPsec Proposals or IKEv2 IPsec Proposals objects, or create and then select a new one. See Configure IKEv1 IPsec Proposal Objects and Configure IKEv2 IPsec Proposal Objects for details. - Enable Security Association (SA) Strength Enforcement
-
Enabling this option ensures that the encryption algorithm used by the child IPsec SA isn’t stronger (in terms of the number of bits in the key) than the parent IKE SA.
- Enable Reverse Route Injection
- Reverse Route Injection (RRI) enables static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint.
- Enable Perfect Forward Secrecy
- Whether to use Perfect Forward Secrecy (PFS) to generate and use a unique session key for each encrypted exchange. The unique session key protects the exchange from subsequent decryption, even if the entire exchange was recorded and the attacker has obtained the preshared or private keys used by the endpoint devices. If you select this option, also select the Diffie-Hellman key derivation algorithm to use when generating the PFS session key in the Modulus Group list.
- Modulus Group
- The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. For a full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.
- Lifetime Duration
- The number of seconds a security association exists before expiring. The default is 28,800 seconds.
- Lifetime Size
- The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association before it expires. The default is 4,608,000 kilobytes. Infinite data isn’t allowed.
- ESPv3 Settings
-
- Validate incoming ICMP error messages
- Choose whether to validate ICMP error messages received through an IPsec tunnel and destined for an interior host on the private network.
- Enable 'Do Not Fragment' Policy
- Define how the IPsec subsystem handles large packets that have the do-not-fragment (DF) bit set in the IP header.
- Policy
-
-
Copy DF bit—Maintains the DF bit.
-
Clear DF bit—Ignores the DF bit.
-
Set DF bit—Sets and uses the DF bit.
-
- Enable Traffic Flow Confidentiality (TFC) Packets
- Enable dummy TFC packets that mask the traffic profile which traverses the tunnel. Use the Burst, Payload Size, and Timeout parameters to generate random length packets at random intervals across the specified SA.