Firepower VPN Load Balancing

In FTD 7.0 Cisco added VPN load balancing. This is a feature that has been around with the ASA platform for a while and greatly improves the available bandwidth to a VPN deployment. I will be walking through the steps to implement this solution in my lab environment. I will be using an all virtual deployment with a FMCv and two FTDv's. I will be deploying this using Firepower Threat Defense 7.1 with reference to the configuration guide:

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/710/management-center-device-config-71/vpn-remote-access.html

Prerequisites and Helpful information

Network Design

Configuration

Border Firepower - NAT

Verification & Troubleshooting

Prerequisites and Helpful information

The Firepower devices do not need to be the same type.
- - Keep in mind that each model has a total number of VPN users and available crypto bandwidth. If you peer two different models together you might see reduced available bandwidth to some users. For example a 4110 (8 Gbps) and a 2140 (3.6Gbps) have very different bandwidth but each support 10,000 users. The load balancing feature will distribute the load evenly between these two devices resulting in users connected to the 2140 having a much lower VPN bandwidth. You can change this by modifying the number of users available on the lower end platform. More information can be found HERE.
Only the FTD devices that are co-located can be added to a load-balancing group.
When a member or a director device goes down, remote access VPN connections that are served by that device will be dropped. You must initiate the VPN connection again.
Identity certificates on each device must use a wildcard cert or a more specific cert with Subject Alternate Name (SAN) fields for the URL or IP.
Devices that are behind Network Address Translation (NAT) can also be part of a load balancing group.
- - There are some special considerations needed to leverage load balancing behind NAT. A fundamental understanding of NAT is recommended.

Network Design

The network layout is based on the lab capabilities and various designs may be needed to facilitate your individual needs. In my lab environment I have positioned by VPN head ends behind my Firepower border FW which is performing NAT. The user traffic is then sent back through the Firepower device for inspection after leaving the VPN tunnel. The diagram below illustrates the VPN components.

Configuration

I will cover the configuration of the VPN components of this build. I won't go over the underlying FTD configuration for interfaces, management or routing. I will cover the configuration for AnyConnect, Certificates and the NAT configuration on the border Firepower.

Border Firepower - NAT

I have a border FW that handles the NAT translation between the "internet" and the internal network. It translates from a 192.168.185.X subnet to a 10.10.X.X subnet. I leverage Proxy-Arp on the firepower device to answer a variety of IP's in the 192.168.185.0/29 subnet for external communication. When the RAVPN Firepower balances the VPN connections it redirects the TLS session from the VIP to each devices specific URL/IP. Therefore you need to have a separate NAT entry for the VIP and each VPN member. Don't forget that you will need UDP to your designated port in order to allow DTLS. I deployed it to my border Firepower as so:

The primary interface IP is used for the NAT Translations to the RAVPN VIP. I then leverage proxy NAT to tie addresses in the same subnet to the two virtual RAVPN members. You will need to update these NAT addresses into your RAVPN policy in order for the redirection to occur to the Nat address and not the internal device address. The screenshot below shows the details. There is one thing to note here, currently the NAT field does not allow a URL, only an IP. This will cause some issues if your device certificates are not updated with the IP address of the appropriate NAT in the SAN field.

The primary interface IP is used for the NAT Translations to the RAVPN VIP. I then leverage proxy NAT to tie addresses in the same subnet to the two virtual RAVPN members. You will need to update these NAT addresses into your RAVPN policy in order for the redirection to occur to the Nat address and not the internal device address. The screenshot below shows the details Device>Remote Access>VPN-Policy>Advanced. There is one thing to note here, currently the NAT field does not allow a URL, only an IP. This will cause some issues if your device certificates are not updated with the IP address of the appropriate NAT in the SAN field.

FTD

Certificates

Certificates are leveraged in order for trust to be established between the FTD device and the AC endpoint. Normally a root CA certificate and an identity certificate would be all that you need for a connection. With VPN load balancing it becomes a little more complicated. As noted above you will need:

Identity certificates on each device must use a wildcard cert or a more specific cert with Subject Alternate Name (SAN) fields for the URL or IP.

The VIP will present the client with the certificate assigned to your RAVPN policy. Since the load balancing will change the final destination depending on load the certificate will need to include any of the potential load balancing members. That or you can use a wildcard certificate and anything belonging to the specific domain will be trusted. The trade off is really a security vs ease of use/troubleshooting. To be more secure and cover the more difficult deployment I opted into putting the specific addresses into my SAN field in my Identity certificate. Don't forget to add both the URL and IP of each member, you will thank me later.

Let's talk about the FMC and getting a CSR for the individual FTD members. The FMC has a section under PKI labeled "Cert Enrollment" and that can use a variety of methods to create/register certificate authorities to obtain a identity cert. The only issue is that it does not currently have an option to enable custom SAN fields. In our use case we will directly need those and must choose another option to obtain a certificate. Depending on your environment one of these may be easier than the other. OpenSSL has a higher learning curve but is very flexible where as leveraging windows may be easier it might be more difficult to get exactly what you want or the formatting you need it in.

OPENSSL

You will need a device with OpenSSL installed on it or leverage the CLI of FMC. In my case I leveraged Ubuntu on windows, a super handy feature for those that need to quickly swap back and forth.

https://docs.microsoft.com/en-us/windows/wsl/about

Use the command

sudo vi certtemp.conf

Copy and paste the commands below into your template (bold fields need to be changed to fit your needs):

[ req ]

default_bits = 2048

prompt = no

encrypt_key = no

default_md = sha256

distinguished_name = dn

req_extensions = req_ext

[ dn ]

CN = FPR-RAVPN.RASLabs.net

O = RASLABS

OU = VPN Services

L = New York

ST = NY

C = US

[ req_ext ]

subjectAltName = DNS: FPR-RAVPN.RASLABS.Net, DNS: FPR-RAVPN-1.RASLABS.Net, DNS: FPR-RAVPN-2.RASLABS.Net, IP: 192.168.185.5, IP: 192.168.185.2, IP: 192.168.185.4

Save and quit the VI environment using: :wq!
Now to generate the CSR.

Create a private key and the CSR using the template you just made:

openssl req -new -config certtemp.conf -keyout RAVPN.key -out RAVPN.csr

Time to send the CSR file to certificate authority you use for signing.
Once you have received the signed certificate I rename the cer file for easier syntax.
Place the new RAVPN.cer file and the root CA file onto your Ubuntu server.
We will now create a bundle (PKCS12) for all the certificate information we can upload to our FMC.

openssl pkcs12 -export -out RAVPN.pfx -inkey RAVPN.key -in RAVPN.cer -certfile ROOTCA.cer

It will prompt you for a passhprase which you will need to use on the FMC to decrypt everything.
Now you have your bundle to upload to FMC.

Head to Objects>Object Management>PKI>Cert Enrollment.

Add Cert Enrollment

Fill out a name, select PKCS12 file and browse to the file location.

Enter the passphrase from your creation and click save.

The certificates are now loaded on the FMC but will still need to be deployed to the individual FTD devices.

Devices>Certificates

Click add in the upper right corner.

Select the device you need to add the certificate to.

Select the appropriate certificate you uploaded from the PKCS12 file.

You will need to add this certificate to each FTD load balancing member.

Windows Certificate Authority

If you just leverage windows local CA then you can leverage a CSR file and add the SAN values directly through the "Additional Attributes" field.

Add SAN to secure Lightweight Directory Access Protocol (LDAP) certificate - Windows Server | Microsoft Docs

I added both the additional URL's and IP addresses with these commands:

san:dns=FPR-RAVPN.RASLabs.Net&dns=FPR-RAVPN-2.RASLabs.Net&dns=FPR-RAVPN-1.RASLabs.Net&ipaddress=192.168.185.2&ipaddress=192.168.185.4&ipaddress=192.168.185.5

You may find that your local CA will not accept the additional attribute values. There is a flag that needs to be enabled on the certserv for this to work.

Open a RDP to your Windows CA.
Open a CMD prompt and use the command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Stop and restart the certserv:

net stop certsvc

net start certsvc

Try the submittal again and you should find that it now carries the additional SAN values.

VPN Pool

The Firepower can either use a DHCP server or IP pools to assign IP addresses to VPN clients. When you have a single VPN head end this is a simple method of setting up a simple pool. However, when you use a VPN load balancing you will need to decide best how to distribute the addresses. You can distribute separate pools to each member or use one pool with device overrides. With device overrides we can assign subsets of the pool to each member.

We will need to create a VPN Pool that we can leverage in our VPN policy.
- In the FMC open object management Objects>Object Management>Address Pools>IPv4 Pools
- Add IPv4 Pools
- Give the pool a name, address range and enable Allow Overrides
- Add an override for each member of your LB group.

Note: By default the Firepower has Reverse Route Injection enabled. This means that each device will inject a /32 route for each VPN IP address assigned. You can leverage this method to not use overrides but it can get complicated depending on your routing. The better suggestion is to set up specific override pools and summarize each routes to the corresponding VPN member.

Authentication

FTD supports a variety of methods of authentication depending on your needs. Currently in my lab environment I am leveraging multiple certificate validation. I validate both the individual users certificate and the machine certificate. I can also leverage a Yubi Key/PIV card to operate for the user certificate.

Additional information on multiple certificates can be found Here. This documentation is for ASA but operates in the same manner on FTD.

The key to multiple certificate validation lies in the AnyConnect Profile and having the appropriate administrative rights for the certificate data stores. We will cover that in the AnyConnect section. I am not going to go into detail on the certificate templates or how to deploy them as that is more of a Windows GPO or MDM story. In my lab environment I leverage Windows Server 2019 for my CA. We will need to provide the root CA for my users identity certificates in order to validate trust.

In the FMC open object management Objects>PKI>Trusted CAs
- Click Add Trusted CA
- Give the certificate a name, add the certificate information and password if needed.

We are also going to need the ISE server in order to do Authorization. I am going to add that now.
- In the FMC open object management Objects>AAA Server>Radius Server Group
  - Click Add Radius Server Group
  - Fill in the name and description
  - Enable interim account update
    - - Enable interim account update and Interval—Enables the generation of RADIUS interim-accounting-update messages in order to inform the RADIUS server of newly assigned IP addresses. Set the length, in hours, of the interval between periodic accounting updates in the Interval field.
  - Enable dynamic authorization for CoA (default port is 1700).

- - Now we need to add the Radius Server
    - Assign the IP address and Radius key
    - I define the specific interface as my inside interface for the communication source.
    - Define the REDIRECT ACL.
      - This is the name of the ACL defined in Firepower Threat Defense to decide the traffic to be redirected. The Redirect ACL name here must be the same as the redirect-acl name in ISE server. When you configure the ACL object, ensure that you select Block action for ISE and DNS servers, and Allow action for the rest of the servers.