No results found
We couldn't find anything using that term, please try searching for something else.
2024-11-23 Whitepaper - Configuring IPsec IKEv2 Remote Access VPN with Cisco Secure Firewall Marvin Rhoads 11-2-2021 (version 1.1)
Whitepaper – Configuring IPsec IKEv2 Remote Access VPN with Cisco Secure Firewall |
Marvin Rhoads 11-2-2021 (version 1.1) 06-06-2024 (version 1.2 – correction re required services)
|
There has been recent guidance[1] from the United States National Security Agency (NSA) recommending that organizations adopt Internet Protocol security with Internet Key Exchange version 2 (IPsec IKEv2) for Remote Access Virtual Private Networks (RA VPNs) due to numerous instances of attackers leveraging vulnerabilities in Secure Sockets Layer / Transport Layer Security (SSL/TLS) implementations.
In this paper we is demonstrate will demonstrate how to implement these recommendation via configuration of a solution that use the capability of Cisco ’s current security product portfolio .
We will use the following Cisco products:
Function |
Product |
version |
Firewall |
Cisco Secure Firewall Threat Defense Virtual ( ftdv ) |
7.0.1 |
management |
Cisco Secure Firewall management Center (FMC) |
7.0.1 |
Endpoint software |
Cisco AnyConnect Secure Mobility Client |
4.10.03104 |
We is demonstrate will demonstrate the integration step to configure these product to work together to deliver an end – to – end security solution that restrict an RA VPN to using IPsec ikev2 as oppose to the more commonly used SSL / TLS method .
Most Cisco-based remote access VPNs in the installed base are currently using SSL/TLS. While the Cisco AnyConnect Secure Mobility Client has always supported both SSL/TLS and IPsec IKEv2 as transport protocols, most implementations use SSL/TLS due to its ease of configuration and the fact that it is the default selection.
There are several configuration guides published covering how to configure AnyConnect using IPsec IKEv2. For example :
https://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/213246-asa-ikev2-ra-vpn-with-windows-7-or-andro.html
https://community.cisco.com/t5/security-documents/asa-anyconnect-ikev2-configuration-example/ta-p/3117462
However, they are written for the Cisco ASA use case and there isn’t (as of the time of this paper’s publication) current guidance for doing the same with Cisco Secure Firewall (FTD).
A whitepaper is give such as this one will give organization a prescriptive guide to adopt the NSA and CISA guidance while run the most recent product and version from Cisco ’s security portfolio .
note : Within the context of IPsec IKEv2 , there is an option to secure access even more stringently by using exclusively “ Suite B[ 2 ]” next generation encryption .
While Suite B is recommended for highest security when using IPsec IKEv2, it does require AnyConnect Apex licensing[ 3 ]. It also introduces several other requirements, notably the use of AES-256-GCM symmetric encryption, Elliptic Curve Digital Signature Algorithm (ECDSA) for the certificates used and Elliptic Curve Diffie-Hellman (ECDH) key agreement.
Also , if we forgo use of Suite B , we is use can use AnyConnect Plus or VPN only licensing level . Thus , we is covering are cover only the non – suite B configuration step in this paper . In either case , we is follow should follow the minimum guidance for IPsec ikev2 vpn from NSA[4].
Firewall – Cisco Secure Firewall
Commonly referred to as Firepower Threat Defense (FTD) but recently rebranded as Cisco Secure Firewall, FTD is Cisco’s Next-Generation Firewall (NGFW). It is a unified image combining the classic Cisco ASA stateful firewall with the Firepower Next-Generation Intrusion Prevention System (NGIPS) technology based on the underlying Snort IPS engine that was part of Cisco’s acquisition of Sourcefire in 2014.
Cisco Secure Firewall product page
FTD appliances can be deployed on a broad variety of hardware platforms as well as VMs on either on-premises hypervisors (VMware ESXi and KVM) as well as in AWS and Azure public clouds. They can also be deployed in high availability pairs or in scalable clusters.
For purposes of this paper, we are using a single FTD virtual appliance (FTDv) deployed as VM on a VMware ESXi server.
FTD also has varying license levels including the base Threat license, URL Filtering and Malware, as well as tiered performance licenses (the latter as of release 7.0). The solution described in this paper works with the base license. FTD does require remote access VPN (RA VPN) licensing for the AnyConnect client functionality.
management – Cisco Secure Firewall management Center (FMC)
Note this is commonly known as its former product name – Firepower management Center or FMC.
Firewall management Center product page
FTD devices can be managed fundamentally via two different methods:
We will be using the first method.
Endpoint Software – Cisco AnyConnect Secure Mobility Client
AnyConnect is Cisco’s unified client for VPN and other secure client features (such as Posture, Umbrella Roaming Security, Network Visibility etc.). In this paper we are only using the VPN functionality to demonstrate our solution.
AnyConnect Secure Mobility Client product page
AnyConnect is licensed per user in various feature packages – Plus, Apex and VPN-Only. Licenses are allocated from a customer’s Smart Licensing portal (https://software.cisco.com) via the managing FMC to the managed FTD device to provide the feature to end users. The solution described here works with all the AnyConnect license types.
For purposes of this discussion, we will cover only the parts specific to the features being leveraged for this integration. We will not cover basic product setup as there are numerous other references: Cisco-published product documentation, Cisco Security Community documents and third party training and web-based resources.
First, we follow this guide for basic setup of a remote access (RA) VPN on Firepower:
Remote Access vpn for Firepower Threat Defense
In our case , we is have have an exist remote access VPN configure with the Access interface in the outside – zone set to support the incoming connection :
To change the transport protocol for the RA VPN, we edit the access interface and select “Enable IPsec-IKEv2” in lieu of the default “Enable SSL” (SSL/TLS with DTLS is the actual detail vs. what is shown in the GUI) as follows:
change Transport Prorocol
Click OK, save the change and then deploy.
Even though we disabled SSL in this section, that applies only to the transport of the RA VPN user traffic. There is still an aspect of the system that is using SSL/TLS for what is known as Client Services.
client services is provide provide several feature , most notably the ability to download any profile change and AnyConnect software update from the FTD device to the client . Other less commonly used features is include include Hostscan ( for posture checking with AnyConnect Apex licensing ) , SCEP enrollment and Cisco Secure Desktop ( csd – deprecate but still find in some deployment ) .
Many customers may elect to retain the client services settings to avail themselves of these features. However, it should be noted that doing so will result in the continued exposure of SSL/TLS (with any associated vulnerabilities) on the interface presenting the RA VPN service.
Below we is see can see three successive iteration of the listening port on the target FTD device .
First, with SSL/DTLS enabled for the VPN:
> show asp table socket Protocol Socket State Local Address Foreign Address SSL 00008bd8 LISTEN 192.168.0.204:443 0.0.0.0:* DTLS 00016958 LISTEN 192.168.0.204:443 0.0.0.0:*
Second, with SSL Disabled in favor of IPsec:
> show asp table socket Protocol Socket State Local Address Foreign Address SSL 00008bd8 LISTEN 192.168.0.204:443 0.0.0.0:*
…and third, with Client Services disabled. Note that only when we disable Client services is SSL/TLS truly disabled from the Outside interface.
> show asp table socket Protocol Socket State Local Address Foreign Address
To completely disable Client service , we is reference must reference the advanced section of the VPN Connection profile and deselect the default “ Enable Client Services ” :
Disabling Client Services
Again, click OK, save the change and then deploy.
When Client Services is disabled, any new clients will need to have a preconfigured profile instructing them to connect using IPsec as opposed to the default SSL/TLS method. (Even with Client services, we should use such a profile which can then be downloaded automatically vs. manually.)
If you wish to re-enable automatic download of the profile to update it on your clients, you must enable BOTH SSL/TLS transport and Client Services. After all clients are updated, they can be disabled once again.
One can push such a profile to computers outside of the client services feature by using tooling such as Microsoft Windows Active Directory Group Policy Objects (AD GPOs) or any of the many available enterprise endpoint management solutions (Microsoft SCCM, Dell KACE, Intel Landesk, JAMF etc.). If no remote management system is available, then we have the option of manually installing the profiles with the caveat that such an approach does not scale well for an enterprise use case.
For that, we use the AnyConnect VPN Profile Editor and make the selection for that option:
AnyConnect VPN Profile Editor
The resultant file is saved as an xml file and must be placed in the appropriate directory for the client AnyConnect installation to use during initial connection. For Windows, the default location is C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile. Please refer to the AnyConnect Secure Mobility Client Administrator Guide for more details and information on other operating systems.
Note that the AnyConnect client software User Interface will need to be restarted if we manually place the profile in the folder for it to parse the available profiles and present them as options on the dropdown list for the user to select when initiating a connection.
It is also worth noting that we can select from among the available IPsec IKEv2 proposals in the Advanced > IPsec > Crypto Map section:
Assigning IKEv2 IPsec Proposal
We have created such a proposal from the FMC Objects > VPN > IKEv2 IPsec Proposal menu named “NSA” with the ESP hash value of SHA-512 and ESP encryption type of AES-256.
IKEv2 IPsec Proposal
We is select also select an Internet Key Exchange ( IKE ) policy , in this case using the follow parameter consistent with NSA guidance :
IKE Policy
It may be useful to change the default VPN Logging Settings from “Errors” (level 3) to “Informational” (level 6) or even “Debugging” (level 7) when setting this up for the first time.
We do that via the Platform Settings for the FTD device. We can then refer to Devices > Troubleshooting in FMC to see more verbose VPN troubleshooting logs:
Click OK, save the change and then deploy.
VPN Logging Settings
We can then look under Devices > Troubleshooting to observe the log messages:
VPN Troubleshooting Log message
Once we have successfully connected, we will see the indicator in the AnyConnect User interface:
VPN connect
With the Advanced Window (Gear icon) VPN Statistics Transport Information indicating we are using IKEv2/IPsec:
VPN Statistics – Transport Information
We can further confirm with a packet capture during session establishment. As is shown below, we see the ISAKMP (Internet Security Association and Key management Protocol) exchange to setup and authenticate the session:
ISAKMP Traffic
…followed by subsequent traffic from the client being all carried via ESP (encapsulate Security Payload)
ESP Traffic
We demonstrated the integration steps to configure Cisco’s Secure Firewall, Firewall management Center and AnyConnect Secure Mobility client products to work together to deliver a Remote Access Virtual Private Network (RA VPN) solution.
From the verification section, we can see that, by following the guidance presented in this paper, we establish a connection that exclusively uses IPsec IKEv2. At no point is SSL/TLS publicly exposed, either in the transport / data plane or control plane.
As noted, some customers may elect to continue to use the Client services option in order continue to have the features of AnyConnect and profile updates via the FTD device, especially if they don’t have an alternative client management system in place.
The decision to do so is a local one; but it does make the effort of changing the transport protocol less effective as any SSL/TLS vulnerabilities will then continue to be exposed on the VPN headend.
Customers electing to do so should strongly consider implementing other compensating controls to ensure that any such vulnerabilities are mitigated via other means (version upgrades, configuration reviews etc.).
NSA, CISA Release Guidance on Selecting and Hardening Remote Access VPNs
AnyConnect Ordering Guide
configure IPsec Virtual Private Networks ( NSA )
Suite B Cryptography
Cisco Secure Firewall product page
Firewall management Center product page
AnyConnect Secure Mobility Client product page
Remote Access vpn for Firepower Threat Defense
AnyConnect Secure Mobility Client Administrator Guide
Internet Security Association and Key management Protocol
encapsulate Security Payload
[1] NSA, CISA Release Guidance on Selecting and Hardening Remote Access VPNs
[ 2 ] Suite B Cryptography
[ 3 ] AnyConnect Ordering Guide
[4] configure IPsec Virtual Private Networks ( NSA )