Virtual Firepower (FTDv) automation deployment

While for long time firewall has typically been something associated with large metal appliances sitting on the outskirts of an infrastructure. More and more are looking into virtualizing also this part of their infrastructure.

The applications of running on virtual NGFW are many. The most obvious ones are usually:

  • Firewall as a Service (FWaaS) use-cases
  • Multi-tenancy
  • Strong virtualization desires
  • Pay-as-you-go cost
  • Flexible licensing
  • Lab uses
  • Very good scale-out possibilities

Utilizing virtualization comes with many benefits and only a few drawbacks. From Firepower Threat Defense (FTD) version 6.4 is is possible to add up to 16 cores (4, 8 and 12 being the supported configs) for the FTDv where it earlier was limited to a fixed number of 4.

This of course gives quite the boost in capable performance and thus the possible use-cases.

Datasheet for the Virtual Firepower models

Be aware that it may not be all VMware native features which can be supported. Most prevalent missing is the VMware native Fault Tolerance. Here you would need to rely on HA on the FTDv, or simply the native VMware resilience. There are support for vMotion however.

VMware feature support for the FTDv

The caveats of virtualized firewalls is mostly located around physical hardware offloading capabilities which for good reason are not there on a generic x86 platform. These amongst others counts features such as flow offloading to ASIC and SSL acceleration.

Due to these caveat most large deployments will most likely still be hybrids as we may well want dedicated hardware at certain places of our perimeter.

The old way

So how are we going to spin up 10x FTDv in an easy manner? Of course we could do it one at a time…

  1. Deploy each through our vCenter
  2. Login to FTD CLI and setup IPs and FMC address
  3. Register the new device in the FMCs GUI
  4. etc. and then repeat 10 times

Or we could do a bit of automagic… Now begins the fun part 🙂

Automating deploying to VMware

In the file containing the software from CCO (Cisco_Firepower_Threat_Defense_Virtual-6.5.0-115.tar.gz or similar). There is both at ESX ovf template and a VI template. You want to use the VI template when deploying with vCenter as this allows for additional properties (aka zero touch deployment). Even if you are manually deploying a single OVF template it can still easily be zero touch provisioned through the deployment wizard on vCenter. But we want to do more…

OVF properties populated at deploy time @vCenter

VMware supports an utility called OVFtool. This can be used to script the entire process of deploying a FTDv. (Note. you will need vCenter for OVF props to work). Below is a sample command for deploying a single FTDv fully configured (of course you will want to change IPs etc).

ovftool \
--noSSLVerify \
--allowExtraConfig \
--deploymentOption=4Core8GB \
--name="Tenant_01_FTDv" \
--diskMode=thin \
--datastore="datastore1" \
--net:"Management0-0"="VM Network" \
--net:"Diagnostic"="VM Network" \
--net:"GigabitEthernet0-0"="VM Network" \
--net:"GigabitEthernet0-1"="VM Network" \
--net:"GigabitEthernet0-2"="VM Network" \
--net:"GigabitEthernet0-3"="VM Network" \
--net:"GigabitEthernet0-4"="VM Network" \
--net:"GigabitEthernet0-5"="VM Network" \
--net:"GigabitEthernet0-6"="VM Network" \
--net:"GigabitEthernet0-7"="VM Network" \
--acceptAllEulas \
--prop:fqdn="tenant_01_FTDv.seclab.local" \
--prop:pw="Admin123" \
--prop:ipv4.how="Manual" \
--prop:ipv4.addr="10.10.10.41" \
--prop:ipv4.mask="255.255.255.0" \
--prop:ipv4.gw="10.10.10.200" \
--prop:dns1="10.101.255.100" \
--prop:searchdomains="seclab.local" \
--prop:firewallmode="routed" \
--prop:manageLocally="No" \
--prop:mgr="10.101.255.241" \
--prop:regkey="secret" \
--prop:firewallmode="routed" \
"Cisco_Firepower_Threat_Defense_Virtual-VI-6.5.0-115.ovf" \
"vi://username:password@10.10.10.210:443/Datacenter/host/10.10.10.212/"

Registering with FMC

Now we just need to add it to our FMC (ok if you choose manageLocally=”Yes” you would have a locally managed FDM version and be done now). Registering it to the FMC is also done programmatic through restAPI. The following method is the one we want (can also be done through the API explorer https://FMC-IP/api/api-explorer/). Curl version further down.

post /api/fmc_config/v1/domain/$UUID/devices/devicerecords
{
"name": "Tenant_01_FTDv",
"hostName": "10.10.10.41",
"regKey":"secret",
"license_caps": [
"BASE",
"MALWARE",
"URLFilter",
"THREAT"
]
}

Great stuff. Now we are rolling. But say we wanted to have like 5 x FTDv? That can easily be archived with a simple loop and a few variable.

Putting it together

Below are my crude loop. First it deploys 5 FTDv to the vCenter, secondly it registers the newly created FTDs in the FMC.

for i in {1..5}
do
./ftdv_ovftool_deploy.sh $i
done
for i in {1..5}
do
./register_fmc.sh UUID AUTHTOKEN $i
done

Of course our code from above, now referenced as ftdv_ovftool_deploy.sh and register_fmc.sh also needs to be variablized.

ovftool \
--noSSLVerify \
--allowExtraConfig \
--deploymentOption=4Core8GB \
--name="Tenant_0${1}_FTDv" \
--diskMode=thin \
--datastore="datastore1" \
--net:"Management0-0"="VM Network" \
--net:"Diagnostic"="VM Network" \
--net:"GigabitEthernet0-0"="VM Network" \
--net:"GigabitEthernet0-1"="VM Network" \
--net:"GigabitEthernet0-2"="VM Network" \
--net:"GigabitEthernet0-3"="VM Network" \
--net:"GigabitEthernet0-4"="VM Network" \
--net:"GigabitEthernet0-5"="VM Network" \
--net:"GigabitEthernet0-6"="VM Network" \
--net:"GigabitEthernet0-7"="VM Network" \
--acceptAllEulas \
--prop:fqdn="tenant_0${1}_FTDv.seclab.dk" \
--prop:pw="Admin123" \
--prop:ipv4.how="Manual" \
--prop:ipv4.addr="10.10.10.4${1}" \
--prop:ipv4.mask="255.255.255.0" \
--prop:ipv4.gw="10.10.10.200" \
--prop:dns1="10.101.255.100" \
--prop:searchdomains="seclab.local" \
--prop:firewallmode="routed" \
--prop:manageLocally="No" \
--prop:mgr="10.101.255.241" \
--prop:regkey="secret" \
--prop:firewallmode="routed" \
"Cisco_Firepower_Threat_Defense_Virtual-VI-6.5.0-11.ovf" \
"vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/"

You will need to fetch the X-auth-access-token and UUID for the FMC before hand for this example. This can also be done with a bit of more CURL calls, but for sake of simplicity it is omitted here.

curl -k -X POST "https://10.101.255.241/api/fmc_config/v1/domain/%{1}/devices/devicerecords" -H "accept: application/json" -H "Content-Type: application/json" -H "X-auth-access-token: %{2}/9" -d "{ \"name\": \"Tenant_0%{3}/_FTDv\", \"hostName\": \"10.10.10.4%{3}\", \"regKey\":\"secret\", \"license_caps\": [ \"BASE\", \"MALWARE\", \"URLFilter\", \"THREAT\" ]}"

And that is actually it… Then you can manipulate rules and/or create a hierarchy of ACP policies depending on your use-case.

Results

Running this script yields an output like below and UI in FMC and cVenter shows we have deployed our 5 x FTDv

…
Opening OVF source: Cisco_Firepower_Threat_Defense_Virtual-VI-6.5.0-11.ovf
The manifest validates
Opening VI target: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Deploying to VI: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Transfer Completed
Powering on VM: Tenant_03_FTDv
Task Completed
Completed successfully
Opening OVF source: Cisco_Firepower_Threat_Defense_Virtual-VI-6.5.0-11.ovf
The manifest validates
Opening VI target: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Deploying to VI: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Transfer Completed
Powering on VM: Tenant_04_FTDv
Task Completed
Completed successfully
Opening OVF source: Cisco_Firepower_Threat_Defense_Virtual-VI-6.5.0-11.ovf
The manifest validates
Opening VI target: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Deploying to VI: vi://administrator@10.10.10.210:443/Datacenter/host/10.10.10.212/
Transfer Completed
Powering on VM: Tenant_05_FTDv
Task Completed
Completed successfully
$

If it was a FWaaS model the FMC ACP policies can be setup with different domains (for multi-tenancy within FMC) and with inheritance in the policy structure. With the inheritance it is possible for the ‘service provider’ to maintain a ‘minimum compliance policy’ which will then be enforced throughout the tenants, while still allowing for individual rulesets for each FTDv.

FMC ACP policy for a FWaaS use-case

The code examples given in this short article most likely needs to be manipulated somewhat depending on the needs. But is should be fairly simple to do as all the pieces of the puzzle are included herein.

One last note when mass deploying firewalls as described here is also doing considerations as regards to logging. FMC can of course be used but if connections logs are required in massive amounts it needs to be separately handled (retention times etc.). This article is about using a Elasticsearch/Logstash/Kibana for digesting logs from such an distributed environment.

Enjoy going virtual! 🙂

Other references

Cisco Live presentation on orchestrating ASAv and NGFW for on-prem workloads https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2018/pdf/BRKSEC-2062.pdf

FTDv quick start https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/vmware/ftdv/ftdv-vmware-gsg/ftdv-vmware-intro.html

Public cloud template https://github.com/cisco/firepower-ngfw

Be the first to comment on "Virtual Firepower (FTDv) automation deployment"

Leave a comment

Your email address will not be published.


*