Supported encryption algorithms for IPsec VPNs

Encryption algorithms scramble data, so that it is not viewable while in transit.

Table 1. Supported encryption methods
Method	Description
AES-128	Advanced Encryption Standard (also referred to as Rijndael) with a 128-bit/192-bit/256- bit encryption key. The AES-128 option uses 128-bit keys by default, but accepts stronger 192-bit or 256-bit keys if requested by the other gateway. All VPN devices must support this algorithm to be fully IPsec-compliant. Reference: RFC 3602.
AES-256
AES-GCM-128	Advanced Encryption Standard (also referred to as Rijndael) in GCM (galois/counter mode), uses a 16-octet ICV (integrity check value). AES-GCM-128 uses a 128-bit encryption key, and AES-GCM-256 uses a 256-bit encryption key. Provides both authentication and encryption. These methods replace the selected message digest algorithm. In high-performance networks, these encryption methods are recommended. All VPN devices must support this algorithm to be fully IPsec-compliant. Reference: RFC 4106.
AES-GCM-256
DES	Data Encryption Standard (also referred to as the Data Encryption Algorithm, DEA) uses a 56-bit encryption key. Do not use DES if you can avoid it. DES has been largely abandoned because the short key makes it vulnerable to attacks. If you must use DES, make sure that PFS is enabled and that the encryption keys are frequently renegotiated. Many IPsec-compliant VPN devices still support this method, but it is not considered secure and should not be used unless required for compatibility with legacy devices. Reference: RFC 2405.
Blowfish	Uses up to 448-bit keys. Policy-based VPNs use 128-bit keys by default, but accept up to 448-bit keys if requested by the other gateway. Many IPsec-compatible VPN devices do not support this method. Reference: RFC 2451.
3DES	Triple-DES (also referred to as TDES or TDEA, Triple Data Encryption Algorithm), uses 168-bit encryption achieved with three different 56-bit encryption keys. 3DES is processor-intensive compared to the level of protection it offers and is therefore not the most efficient method. It might not be optimal for VPNs that handle large traffic volumes or systems that otherwise have a high load. Most IPsec-compliant VPN devices support this method. Reference: RFC 2451.
Null	No encryption. Traffic is sent as cleartext just like any non-VPN traffic. Anyone who intercepts the VPN traffic in transit can view the traffic. Null encryption is useful only in special cases. Do not select it for any VPN that requires protected data transfer. Most IPsec-compliant VPN devices support this method. Reference: RFC 2410.