FTD 6.2 and Remote Access VPN (anyconnect) configuration

With Firepower Threat Defense (FTD) version 6.2 Cisco has introduced the remote access VPN functionality from the ASA firewall software. For an overview of the differences, you could read a previous post. With FTD 6.2.2 (released in september) this feature is now also avaialble on the ASA platforms. With a week of PTO planned, it was time to configure and test RA VPN on my home environment.

Requirements, limitations

Remote Access VPN for FTD is based on the anyconnect images, so it is possible to do IKEv2 and SSL VPN tunnels. In this blog, I’ll only configure the anyconnect SSL features, as this has become my most common deployment configuration.

Although anyconnect is now supported, not all featurs common to anyconnect on the ASA are available. So there are some requirements, restrictions that need to be followed:

• Smart Licenses
  With FTD, only smart licenses are supported. So it is important to have either Anyconnect Plus or Apex licenses assigned to your smart license account. The transfer of my existing ASA classic license to Smart went without a real glitch.
  
  
• Certificates, Radius or AD server
  Local authentication is not possible with FTD, you need to have a PKI, Radius server or AD server available for authentication purposes. This is a thing you really need to keep in mind for those pesky VPN setups used by IT staff in case of emergencies..
• Public Access
  Naturally you also need a public ip with tcp and udp port 443 assigned to your FTD appliance
• Certificate
  Of course a trusted certificate is required so that a TLS connection can be established from the anyconnect client to FTD. I initially used a self signed certificate and later replaced it with a lets encrypt certificate. I will probably write that experience down a bit later and to spoil the result, it has become much easier compared to ASA..
• Anyconnect images
  You need to have at least one anyconnect image to be able to run the setup wizard, otherwise you won’t be able to continue and deploy the RA VPN policies onto your FTD device
• Clustering
  RA VPN is not supported if you run a clustered FTD deployment. A regular HA setup (active/passive) is supported though.

For more information about what is required, check the configuration guide for Remote Access VPN on  FTD 6.2.2

Configuration

For this blog I’ve setup my environment based on the following network diagram.

There is a Radius server on 10.0.4.200 and FMC / FTD talk with each other via the dedicated management interface. The router that connects to the Internet has been configured to forward TCP and UDP (for DTLS) port 443 to the FTD outside interface.

Radius configuration

As I run a test server with CentOS it was quite easy to setup the radius server. FreeRadius comes in a standard package and there is quite some good information on the Internet about FreeRadius on CentOS. I’ve used this guide from the wiki and adopted it to my setup.

Just follow those steps to configure Radius

1. Install FreeRadius by using the command root@my-server@yum install freeradius
2. After succesfull installation, configure freeradius for both the radius client and your users. Be aware that FTD uses its internal routing table and not the management address for Radius authentication..To define a radius client, edit the file /etc/raddb/clients.conf and add the following construct (with the proper values)client my-ftd-device {
       ipaddr = 10.0.4.2
       secret = my-super-secret-key-for-radius-traffic-which-is-completely-different-in-real-life
   }For testing purposes, I also had added the same client based on the management ip address of FTD, but it appears that IP address is not used, either because of routing table, or the radius server is in a directly connected subnet.To add users to the local database, edit the file /etc/raddb/users and add your uses with the following construct (again, with the proper values). Place the users just below the first headermy-vpn-userCleartext-Password := “thePassword”
   my-vpn-user2Cleartext-Password := “someOtherPass”as the passwords appear to be stored in clear text, make sure only radius can read the users file by using the command chmod 600 /etc/raddb/users and chown radiusd /etc/raddb/users 
3. Now that FreeRadius is configured, just enable its service and start it with the commands
   
    root@my-server#chkconfig –add radiusd
   root@my-server#/etc/init.d/radiusd startYour radius server should now run. You can look at the wiki for testing and debugging options.

FTD configuration

I will give this one completely to Cisco. The configuration wizard is really really self-explaining and easy to configure. Just make sure you have all the required information by hand. I’ve created the following table as a summary

Once all information is at hand, start the wizard within FMC, go to Devices -> VPN -> Remote Access and click the add button to start the wizard

Once the wizard is started, five steps are needed for the VPN configuration

Policy assignment

Provide a name  or this remote access VPN policy within FMC/FTD, define the protocols, assign the policy to your FTD device and click next

Connection profile

So this is where all your required info will be used. I’ve attached a screen shot with my values (for blog purpose)

• Connection Profile Name:The name you want your users to see as VPN profile name
• Authentication Method: Use AAA Only
• Authentication Server: THis would be your radius server. As this is most problaby not configued, use the “plus” button to add a new Radius Server Group to open up a new panel that allows you to configure your radius server configuration.Only minor dissapointment I had is that I couldn’t pre-test the Radius server from this screen. On ASA’s that is really an excellent feature to test the Radius setup and I use it a lot for misconfiguration eliminiation in troubleshooting. Cisco, please add this feature, ok? 
• IP Address Pools:Just click the pencil to see all IPv4 pools and use the one you need via the “add” button. Again, use the green plus to create a new one (really cool, neat and consistent feature within FMC)
• Group policy:I rarely use the Default Group Policy, so I always us the “plus” to create a group policy for this specific remote access configuration. Use the “edit group policy” to tune the details, like DNS settings, split tunnel settings, etc..

Anyconnect

Use the green button to upload anyconnect images and then use the checkbox to determine which images you want to copy to the FTD

Access & Certificate

This is where you define which interface you want to bind the RA Profile on and assign the certificate.

Once finished click next and a summary of your configuration will be shown.

Once you click Finish, FMC will execute the configuration. But wait with deploying the configuration to your FTD..

Policies

So yes, the wizard is very easy to create a Remote Access configuration, but FTD is more than just that. There is also a policy that needs to be configured. Of course you could use FlexConfig to setup “sysopt connection permit-vpn” or prefilter “trust” option to bypass all policies for your newly created VPN configuration. But in my opinion with the current cyber security requirements, that is not really a valid option anymore as usually these VPN’s are also used for contractors and external support suppliers for which you do not have control of the connecting endpoint.

I’ve created a category within my access policy named pol-vpn-traffic that will contain all access rules that are related to VPN traffic.

Just create two rules (one ingress and one egress) for your IP pools to the networks you configured for which access is provided. I use two distinct rules as egress (from internal network to vpn clients) could be a different set of rules than the ingress (from anyconnect clients to internal network). Configure the rule and policies as needed.

Hairpin NAT & traffic

It is possible to execute hairpin NAT on FTD. Just configure an auto-nat rule (because of troubleshooting, I’ve used a NAT rules after) with a source zone outside to zone outside to perform the PAT.

As traffic needs to match the policy and i have default deny, you do need to create access policy rules for hairpin NAT traffic as well. It would seem logical that in those policy rules you would configure the outside zone as both the source and destination zone, as it is a hairpin solution. It took me quite some troubleshooting time to find out that this is not completely true. With packet-trace on the FTD appliance it would suggest that the traffic is matched and thus permitted, but in effect it isn’t.

I found that using only source zone outside with the source IP object group created a working solution. My educated guess would be a caveat, but it is something you need to be aware off.

By default I always add a deny rule at the end of a block to prevent unwanted matched rules at a later stage.

Now that everything is configured, hit deploy and test the VPN setup. Current connected VPN users are visible under Analysis -> Users -> Active Sessions .

Summary

The wizard is really easy to use for the creation of a remote access VPN policy. Just make sure that all requirements are met and the required information is available beforehand.

I must say that, after working mostly with the VPN  based solely on mobile (3G/4G) connections on a passenger vessel and sometimes at fixed locations, I am very happy on the stability of the connection. Connections are made fast and stable, both the split-tunnel configuration I explained in this blog as well as the tunnelall with hairpin nat.

Only real thing that you need to be aware of is the policy rule configuration for the hairpin nat solutions.

There is of course much more to write about specific VPN configurations, like adding extra profiles, using aliases, etc, but that would be something for the future.