National Security Agency | Cybersecurity Information

Configuring IPsec Virtual Private Networks

The recent NSA publication “Securing IPsec Virtual Private Networks” [1] lays out the importance of IP Security (IPsec)
Virtual Private Networks (VPNs) and outlines specific recommendations for securing those connections. It is critical that
VPNs use strong cryptography. This guidance goes deeper, providing device administrators specific implementation
instructions and example configurations.1

Maintaining a secure VPN tunnel can be complex and requires regular maintenance. To maintain a secure VPN, network
administrators should perform the following tasks on a regular basis:
 Reduce the VPN gateway attack surface
 Verify that cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant
 Avoid using default VPN settings
 Remove unused or non-compliant cryptography suites
 Apply vendor-provided updates (i.e. patches) for VPN gateways and clients

Reduce the VPN gateway attack surface

VPN gateways tend to be directly accessible from the Internet and are prone to network scanning, brute force attacks, and
zero-day vulnerabilities. To mitigate many of these vulnerabilities, network administrators should implement strict traffic
filtering rules:
 Restrict all traffic to the VPN gateway, limiting access to only UDP port 500, UDP port 4500, and ESP.
 When possible, limit accepted traffic to known VPN peer IP addresses. Remote access VPNs present the issue of
the remote peer IP address being unknown and therefore it cannot be added to a static filtering rule.
 If traffic cannot be filtered to a specific IP address, NSA recommends an Intrusion Prevention System (IPS) in
front of the VPN gateway to monitor for undesired IPsec traffic and inspect IPsec session negotiations.

Examples of recommended ACLs and IPS signatures for obsolete or anomalous VPN traffic are in Appendices A and D.

Verify only CNSSP 15-compliant algorithms are in use

All IPsec VPN configurations require at least two items: (1) the Internet Security Association and Key Management
Protocol (ISAKMP) or Internet Key Exchange (IKE) policy; and (2) the IPsec policy. These policies determine how an
IPsec tunnel will negotiate phase 1 and phase 2 respectively when establishing the tunnel. If either of these phases is
configured to allow obsolete cryptography, the entire VPN will be at risk, and data confidentiality may be lost.

When configuring ISAKMP/IKE, many vendors support having several possible ISAKMP/IKE policies. The device is then
trusted to choose the strongest matching policy between the remote and local ends of the VPN. Some vendors do this
through priority numbers and others through explicit selection. NSA recommends only configuring policies that meet the
minimum level of security and removing any legacy policies. Also, if priority numbers are used, the strongest ISAKMP/IKE
policy should be the highest priority (for many vendors a priority of “1” is the highest priority). Each ISAKMP/IKE policy
includes at least three key components. These components are the Diffie-Hellman algorithm/group, encryption algorithm,
and hashing algorithm.

The following is an example of the minimum recommended ISAKMP/IKE settings per CNSSP 15 as of June 2020 [2]:
 Diffie-Hellman Group: 16
 Encryption: AES-256
 Hash: SHA-384

1 For proprietary application layer VPN best practices, refer to NSA’s Cybersecurity Advisory “Mitigating Recent VPN Vulnerabilities.”

U/OO/148260-20 | PP-20-0504 | Jul 2020

 NSA | Configuring IPsec Virtual Private Networks

Many vendors also support configuring multiple IPsec policies; however, these policies are normally explicitly configured
for a specific VPN. NSA recommends utilizing the strongest cryptography suites supported by the network device. Similar
to ISAKMP/IKE, the IPsec policy contains three key components: (1) the encryption algorithm; (2) hashing algorithm; and
(3) the block cipher mode. The following is an example of the minimum recommended IPsec settings per CNSSP 15 as of
June 2020 [2]:
 Encryption: AES-256
 Hash: SHA-384
 Block Cipher Mode: CBC

Configuration examples for recommended ISAKMP/IKE and IPsec policies on several common vendor devices are
included in Appendix B.

The best way to verify that existing VPN configurations are utilizing approved cryptographic algorithms is to review the
current ISAKMP/IKE and IPsec security associations (SAs). Appendix C provides a set of common vendor commands to
show the current SAs and which cryptographic algorithms were negotiated.

NSA recommends using this approach when reviewing ISAKMP/IKE and IPsec configurations because it will display the
exact cryptography settings that were negotiated. On the other hand, if this approach is not followed, reviewing a device’s
configuration file may miss where a device is selecting a non-compliant algorithm that was a device default or left over
from a previous VPN configuration.

If SAs are identified with non-compliant algorithms, administrators should immediately investigate why the VPN negotiated
a lower cryptography standard and make appropriate configuration changes. Also, if pre-shared keys are being used for
VPN authentication, NSA recommends that all keys be replaced as they may have been compromised due to the use of
weak cryptography.

Many organizations can detect or even block the use of certain common outdated cryptographic algorithms in IPsec, such
as the Data Encryption Standard (DES), Triple DES (3DES), and Diffie-Hellman groups 1, 2, and 5, within their networks
using an IPS. NSA has also observed related scanning activity that includes anomalous ISAKMP packets, which most
networks should be able to block without affecting normal VPN traffic. IPS signatures for some common obsolete
cryptographic algorithms and the anomalous packets are provided in Appendix D.

Cryptography standards continue to change over time as the computing environment evolves and new weaknesses in
algorithms are identified. Administrators should prepare for cryptographic agility and periodically check CNSSP and NIST
guidance for the latest cryptography requirements, standards, and recommendations.

Avoid using default settings

Due to the complexity of establishing a VPN, many vendors provide default configurations, automated configuration
scripts, or graphical user interface wizards to aid in the deployment of VPNs. These tools take care of setting up the
various aspects of a VPN to include ISAKMP/IKE and IPsec policies. However, many will configure a wide range of
cryptography suites to ensure compatibility with the remote side of a VPN.

NSA recommends that administrators avoid using these tools as they may allow more than the desired cryptography
suites. If these tools are used, then be sure to evaluate all configuration settings that the tool deployed. Administrators
should then remove any non-compliant ISAKMP/IKE and IPsec policies. As a best practice, administrators should not
utilize any default settings and ensure that all ISAKMP/IKE and IPsec policies are explicitly configured for the CNSSP 15-
compliant algorithms.

Remove unused or non-compliant cryptography suites

As previously described, many vendors support having several ISAKMP/IKE and IPsec policies configured on a single
device. It is also very common for vendors to include extra ISAKMP/IKE and IPsec policies for compatibility by default or
when using automatic configuration tools; however, these extra policies may include non-compliant cryptographic

U/OO/148260-20 | PP-20-0504 | Jul 2020 2

 NSA | Configuring IPsec Virtual Private Networks

algorithms. Leaving extra ISAKMP/IKE and IPsec policies as acceptable ISAKMP/IKE and IPsec policies creates a
vulnerability known as a downgrade attack. This type of attack is where a malicious user or Man-in-the-Middle only offers
weak cryptography suites and forces the VPN endpoints to negotiate non-compliant cryptography suites.

Negotiating non-compliant cryptography leaves the encrypted VPN vulnerable to exploitation, including potential
decryption, data modification, and adversarial system access. To mitigate this vulnerability, administrators should validate
that only compliant ISAKMP/IKE and IPsec policies are configured and all unused or non-compliant policies are explicitly
removed from the configuration. NSA also recommends periodically validating that only compliant policies are configured
as the use of automated tools, graphical interfaces, or user error could reintroduce non-compliant policies.

Apply vendor-provided updates

After ensuring that all configuration settings are utilizing compliant cryptography suites and that all non-compliant suites
are removed, a robust patch management procedure must be implemented. Over the past several years, multiple
vulnerabilities have been released related to IPsec VPNs. Many of these vulnerabilities are only mitigated by applying
vendor-provided patches. Applying patches to VPN gateways and clients needs to be a part of a regular routine. In
addition, it provides a mechanism to receive alerts when new major vulnerabilities are released. Many network equipment
vendors allow customers to sign up for notification emails of new security alerts. These notifications are an excellent way
to stay up-to-date on relevant out-of-cycle patches.

Conclusion
VPNs are essential for enabling remote access and connecting remote sites securely. However, without the proper
configuration, patch management, and hardening, VPNs are vulnerable to many different types of attacks. To ensure that
the confidentiality and integrity of a VPN is protected, reduce the VPN gateway attack surface, always use CNSSP 15-
compliant cryptography suites, avoid using vendor defaults, disable all other cryptography suites, and apply patches in a
timely manner. Following the steps identified in this paper will ensure the most secure VPN configurations.

Works Cited
[1] “Securing IPsec Virtual Private Networks.” National Security Agency, July 2020. [Online] Available at: www.nsa.gov/cybersecurity-guidance
[2] “Use of Public Standards for Secure Information Sharing.” Committee on National Security Systems, 20 October 2016. [Online] Available at:
https://www.cnss.gov/CNSS/issuances/Policies.cfm

Related Guidance
 “Mitigating Recent VPN Vulnerabilities.” National Security Agency, 2019. [Online] Available at:
https://media.defense.gov/2019/Oct/07/2002191601/-1/-1/0/CSA-MITIGATING-RECENT-VPN-VULNERABILITIES.PDF

Disclaimer of Endorsement
The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific
commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement,
recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Contact
Client Requirements / General Cybersecurity Inquiries: Cybersecurity Requirements Center, 410-854-4200, Cybersecurity_Requests@nsa.gov
Media inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov

U/OO/148260-20 | PP-20-0504 | Jul 2020 3

 NSA | Configuring IPsec Virtual Private Networks

Appendix A: Reducing VPN Gateway Attack Surface Examples

ACL Examples to Limit ISAKMP Traffic to Only Known Peers

Cisco ASA®2:
Access-list deny-ike extended permit udp <source_peer_ip> <destination_peer_ip> eq isakmp
Access-list deny-ike extended permit udp <source_peer_ip> <destination_peer_ip> eq 4500
Access-list deny-ike extended permit esp <source_peer_ip> <destination_peer_ip>
Access-list deny-ike extended deny udp any <destination_peer_ip> eq isakmp
Access-list deny-ike extended deny udp any <destination_peer_ip> eq 4500
Access-list deny-ike extended deny esp any <destination_peer_ip>

Juniper SRX®3:
[edit security policies from-zone untrust to-zone trust]
Policy <permit-policy-name> {
Match {
source-address <source-peer-ip>;
destination-address <destination-peer-ip>;
Application [junos-ike junos-ike-nat];
}
Then {
Permit;
}
}
Policy <deny-policy-name> {
Match {
source-address any
destination-address <destination-peer-ip>;
Application [junos-ike junos-ike-nat];
}
Then {
deny;
}
}

Palo Alto Firewalls:

[edit rulebase security]
Security {
Rules
<permit-rule-name> {
From untrust;
To trust;
Source <source-peer-ip>;
Destination <destination-peer-ip>;
Service application-default;
Application [ike ipsec-esp-udp]
Action allow;
}
<deny-rule-name> {
From untrust;
To trust;
Source any;
Destination <destination-peer-ip>;
Service application-default;
Application [ike ipsec-esp-udp]
Action deny;
}

2 Cisco® is a registered trademark of Cisco Systems, Inc.

3 Juniper® is a registered trademark of Juniper Networks, Inc.

U/OO/148260-20 | PP-20-0504 | Jul 2020 4

 NSA | Configuring IPsec Virtual Private Networks

}
}

IPS Signature Examples to Restrict Protocols That Are Not Used

Reducing the attack surface can include restricting protocols that are not in use. If IKEv1 or IKEv2 is not used at all, then
the following rules can be used to block all IKEv1 or IKEv2 traffic. If IKEv1 or IKEv2 is used, do not use the corresponding
rule or else legitimate traffic will be blocked.

Block all IKEv1 traffic (only use for devices that do not use any IKEv1)
alert udp any any -> any [500,4500] (msg:"All IKEv1"; content:"|00 00 00 00 00 00 00 00 01 10 02 00
00 00 00 00 |"; offset: 8; sid:1; rev:1;)

Block all IKEv2 traffic (only use for devices that do not use any IKEv2)
alert udp any any -> any [500,4500] (msg:"All IKEv2"; content:"|00 00 00 00 00 00 00 00 21 20 22 08
00 00 00 00 |"; offset: 8; sid:2; rev:1;)

U/OO/148260-20 | PP-20-0504 | Jul 2020 5

 NSA | Configuring IPsec Virtual Private Networks

Appendix B: ISAKMP/IKE and IPsec Configuration Examples

In an effort to provide clear guidance on implementing strong IPsec VPNs, this document includes examples of the
ISAKMP/IKE and IPsec, also known as phase 1 and 2, configurations for multiple vendors and devices. When deploying a
remote access IPsec VPN, administrators must also ensure that all VPN clients are also configured properly. For further
guidance on deploying VPNs on specific devices or VPN clients, appropriate vender documentation should be followed.

CISCO IOS ROUTERS®4

ISAKMP:

IKEv1:
crypto isakmp policy 1
encryption aes 256
group [16|20]
hash [sha384|sha512]

IKEv2:
crypto ikev2 proposal <proposal name>
encryption aes-cbc-256
integrity [sha384|sha512]
group [16|20]

IPsec:
crypto ipsec transform-set <transform name> esp-256-aes [esp-sha-hmac|esp-sha384-hmac|esp-sha512-
hmac]

CISCO ASA

ISAKMP:
For Cisco ASA devices, NSA recommends IKEv2, since the IKEv1 implementation only supports SHA1.

IKEv2:
crypto ikev2 policy 1
encryption [aes-256|aes-gcm-256]
integrity [sha384|sha512]
group [16|20]

IPsec:
crypto ipsec ikev2 ipsec-proposal <proposal name>
protocol esp encryption [aes-256|aes-gcm-256]
protocol esp integrity [sha-384|sha512]

Juniper SRX

ISAKMP/IKEv1 and IKEv2:

[edit security ike]
proposal ike-proposal {
dh-group [group16|group20];
authentication-algorithm [sha-384|sha512]

4 IOS® is a registered trademark of Cisco Systems, Inc. in the United States and other countries and is used under license to Apple, Inc.

U/OO/148260-20 | PP-20-0504 | Jul 2020 6

 NSA | Configuring IPsec Virtual Private Networks

encryption-algorithm [aes-256-cbc|aes-256-gcm]
}
policy ike-policy {
mode main;
proposals ike-proposal;
}
gateway <gw name> {
ike-policy ike-policy;
version v2-only; #For IKEv2 otherwise SRX defaults to IKEv1
}

IPsec:
[edit security ipsec]
proposal <proposal name> {
protocol esp;
authentication-algorithm [hmac-sha-384|hmac-sha-512]
encryption-algorithm [aes256-cbc|aes256-gcm]
}

Palo Alto Firewalls®5

ISAKMP/IKEv1 and IKEv2:

IPsec:
[edit network ike crypto-profiles]
ipsec-crypto-proiles <profile name> {
dh-group group 20;
esp;
authentication [sha384|sha512];
encryption [aes-256-cbc|aes-256-gcm];
}

Aruba®6

ISAKMP/IKEv1 and IKEv2:

crypto isakmp policy 1
encryption aes256
group 20
version [v1|v2]
hash sha2-384-192

IPsec:
crypto ipsec mtu <max-mtu> transform-set <transform-set-name> [esp-aes256|esp-aes256-gcm]

5 Palo Alto® is a registered trademark of Palo Alto Networks.

6 Aruba® is a registered trademark of Hewlett Packard Corporation.

U/OO/148260-20 | PP-20-0504 | Jul 2020 7

 NSA | Configuring IPsec Virtual Private Networks

Apriva®7
Apriva does not provide extensive documentation for configuring their devices online. The following configuration snippet
was created using NIAP configuration guidance. Based on the documentation provided, the ISAKMP/IKE and IPsec
configuration is co-located.

vpn-suite <suite name> copy suiteb-rsa{

algorithm [AES-256|AES-GCM-256]
algorithm ike sha2 [SHA-384|SHA-512]
algorithm ipsec sha2 [SHA-384|SHA-512]
group ike [16|20]

7 Apriva® is a registered trademark of Apiva LLC.

U/OO/148260-20 | PP-20-0504 | Jul 2020 8

 NSA | Configuring IPsec Virtual Private Networks

Appendix C: Security Association "show" Command Examples

This appendix lists several common vendors and the available commands to show ISAKMP/IKE and IPsec connection
details. For the purpose of this appendix, only common vendors that provide the cryptographic algorithms negotiated are
listed.

Cisco IOS Routers and ASAs:

ISAKMP/IKE:
show crypto isakmp sa detail

IPSEC:
show crypto ipsec sa

Juniper SRX:

ISAKMP/IKE:
show ike security-associations details

IPSEC:
show security ipsec security-associations detail

Palo Alto Firewalls:

ISAKMP/IKE:
show vpn ike-sa

IPSEC:
show vpn ipsec-sa

Aruba:

ISAKMP/IKE:
Aruba provides the following command to show ISAKMP SAs however it does not provide cryptography details

show crypto isakmp sa

IPSEC:
show crypto ipsec sa

U/OO/148260-20 | PP-20-0504 | Jul 2020 9

 NSA | Configuring IPsec Virtual Private Networks

Appendix D: Examples of ISAKMP/IKE Traffic Signatures

IPS Signatures for Obsolete Diffie-Hellman Groups (1, 2, or 5)

These signatures can be used to detect weak IKEv1 connections. From a defensive perspective, this can be used to
identify VPN endpoints using obsolete Diffie-Hellman groups or to outright block these connections thereby ensuring
policy compliance.

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 01 80 04 00 01|"; within: 80; sid: 1;
rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 01 80 04 00 02|"; within: 80; sid: 2;
rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 01 80 04 00 05|"; within: 80; sid: 3;
rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 02 80 04 00 01|"; within: 80; sid: 4;
rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 02 80 04 00 02|"; within: 80; sid: 5;
rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE group detected"; content:!"|00 00
00 00 00 00 00 00|"; offset: 36; depth: 8; content:"|80 02 00 02 80 04 00 05|"; within: 80; sid: 6;
rev: 1;)

IPS Signatures for DES/3DES

These signatures can be used to detect devices attempting to use obsolete encryption.

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE DES Encryption Used"; content:"|00
00 08 01 00 00 02|"; offset:41; depth: 7; sid: 7; rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE DES Encryption Used"; content:"|00
00 08 01 00 00 03|"; offset:41; depth: 7; sid: 8; rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE DES Encryption Used"; content:"|00
00 08 01 00 00 09|"; offset:41; depth: 7; sid: 9; rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE DES Encryption Used"; content:"|00
00 08 01 00 00 11|"; offset:41; depth: 7; sid: 10; rev: 1;)

alert udp $HOME_NET 500 -> $EXTERNAL_NET any (msg:"Obsolete IKE DES Encryption Used"; content:"|00
00 08 01 00 00 21|"; offset:41; depth: 7; sid: 11; rev: 1;)

IPS Signature of Anomalous ISAKMP/IKE Traffic

NSA has identified scanning activity that generates anomalous ISAKMP traffic. The following rule is designed to block that
anomalous traffic.

alert udp any any -> any 500 (msg:"Anomalous ISAKMP"; content:"|00 00 00 00 00 00 00 00 21 20 22 08
00 00 00 00 |"; offset: 8; content:"|03 00 00 0e 01 00 00 00 00 00|"; distance:16; sid: 12;
rev:1;)

U/OO/148260-20 | PP-20-0504 | Jul 2020 10