I was looking for ways to setup FTD for remote site deployment and after some time of gathering different information from other sources(1,2,3), I thought of writing this post to show what worked best for me in this setup.
If remote site has a single Internet connection deploying ASA with FirePOWER is not an issue as transport for the IPS module to communicate with FMC is separated and if you mess up IPS configuration if will not be affected. But with FTD it is a different story.
Once FTD is joined to FMC and policy is pushed it is fully dependent on the communication link to FMC. Also, if we pre-configure FTD and ship it ready to connect what is the best way to deal if we have to change FTD ISP IP address?
After reviewing design limitations and other suggestions I had to address the following.
- configure FTD at the staging site with limited onsite availability
- ssh remote-access after shipping to the remote site
- recovery in case of FTD/FMC communication failure
Step 1 – Design overview.
I was entertaining the idea of managing FTD over VPN tunnel but after careful consideration, I’ve decided that FTD communication with FMC has to be over public IP. This minimizes the risk of VPN tunnel misconfiguration/bug from an FTD perspective (this happened to me in testing when renaming IKE policy on FMC removed it on FTD after policy push, essentially breaking the IPSEC tunnel). I was working with FTD1010 so E1/1 – ISP, E1/4 loop to Mgmt for FTD management (any interface can be picked). E1/7-8 are PoE so they can be used for wireless AP or IP Phone. Any other port can be wired as needed.
Step 2 -Staging.
Figure out easy staging assuming limited involvement of onsite personal. The picture below is color-coded based on the Vlan assignment. The switch is a staging switch. Ports 1, 4, and Mgmt are connected to the staging switch. Also, the staging public Internet circuit is extended to the same switch either directly or over trunked Vlan. We will need 1 public IP available for connectivity and testing. From the Vlan perspective, Mgmt and the Internet need to be on the same Vlan (black). E1/1 and E1/4 can be any other Vlan for now.
If FTD came with an ASA image then convert it to FTD. Management port is set to DHCP by default so it will pull IP if DHCP is available. Otherwise assign it manually.
ciscoasa# copy ftp://usern:pass@FTP_IP/cisco-ftd-fp1k.6.6.1-91.SPA disk0:/cisco-ftd-fp1k.6.6.1-91.SPA flash:
ciscoasa# configure terminal
ciscoasa(config)# boot system disk0:/cisco-ftd-fp1k.6.6.1-91.SPA
Use the following commands to upgrade from fabric.
Assign IP in FTD mode.
connect ftd
configure network ipv4 manual MgmtIP MgmtSbnt MgmtGw
Exit FTD mode. FTP download will use assigned IP to download new image.
scope firmware
download image ftp://username@FTP_IP/cisco-ftd-“version”.SPA
Check with show commands on download status.
show download-task
show package
scope auto-install
Execute install.
install security-pack version “version”
Next, join FTD to FMC. FMC needs a pubic IP NAT. You can restrict access to it by port TCP/8305.
On FTD CLI assign public IP to Management interface. When adding manager use the public IP of FMC and do not forget NAT key id.
configure manager add FMC_PUB_IP password NATid
Complete FTD provisioning on FMC by adding it as a new device with matching credentials.
Step 3 – FMC FTD IP configuration.
On FMC apply for smart licenses and re-apply policies as without initial full deployment you may not be able to make additional configuration changes or run code upgrades from FMC to FTD (very important in HA setup). Re-use Health Policy but do create a separate Platform Policy for FTD devices. Make sure and allow ssh from trusted public IP addresses in Platform Policy.
Under Devices > Device Management > FTD_name > Interfaces configure interfaces IP information. Assign the same staging public IP to the Outside interface and do not forget the default route to the staging gateway. This way we can test our complete setup before applying real public IP information.
Do not forget to configure a port (in my case port 4) for the Mgmt interface. This is where the Mgmt port will loop to in the final setup. At this time FTD private management IP needs to be selected. I prefer to dedicate a Layer 3 interface (had issues with a bridged port).
Select DHCP tab to assign IP pools. Unfortunately in version 6.6.1, only global DNS servers can be set up so if you have a guest network it will have to use your corporate DNS servers. Because of that guest traffic will have to traverse VPN tunnel and proper rules need to be applied to restrict access in Access Policy. When done apply configuration and monitor for any errors.
Step 4 – FMC FTD NAT configuration.
If your ISP provisioned /29 or larger public IP range then you can pick the next available IP to assign for FTD management as a NATed translation. However most likely this will be a /30 range. In that case, PAT is needed to translate FMC/FTD communication ports as IP will be shared with the Outside interface. Below are 2 bidirectional PAT rules to translate incoming and outgoing packets to port TCP/8305.
The rest are standard no-NAT rules to push traffic into the tunnel. Guest NAT can be restricted to DNS servers IP. The last one is PAT catch-all.
To manage FTD over private management interface IP for SNMP and SSH add no-NAT statement to allow it going over the VPN tunnel. Do not forget to add management station IPs to the Platform Settings Policy.
When done apply configuration and monitor for any errors.
Step 5 – FMC FTD VPN configuration.
This step is easy. FMC has a VPN wizard to assist. IKEv2 is preferred for tunnel setup. In case one of the nodes is an Extranet device I’d build custom IKE and IPsec policies for easy tracking. Once changes applied grab them from ASA mode config (system support diagnostic-cli to enter ASA mode) and paste them to the Extranet device (if it is an ASA for example).
Note, IKEv1 does not support DH group 14. This is incompatible with FTD as FTD does not support anything less. So if you are still using ikev1 it is time to switch to ikev2.
asa(config)# crypto ikev1 policy 10
asa(config-ikev1-policy)# group ?
ikev1-policy mode commands/options:
1 Diffie-Hellman group 1
2 Diffie-Hellman group 2
5 Diffie-Hellman group 5
7 Diffie-Hellman group 7 (DEPRECATED)
Step 6 – FMC FTD Access Policy configuration.
FirePOWER Access policies are not compatible with FTD Access Policies so if this is the first FTD device then Policies need to be cloned or build from scratch. You need to apply your base policies and do not forget to allow:
- FMC public IP inbound/outbound. Can be restricted to only TCP/8305 if needed.
- Guest traffic to Corporate DNS servers.
When done push configuration and monitor for any errors.
Step 7 – FTD testing.
At this point, FTD should have a complete configuration with staging public IP information to perform NAT/VPN/Access Policy testing.
Change staging switch port configuration. This time move ISP and FTD Outside ports into the same VLAN (black) and FTD port 4 and Mgmt into a different VLAN (yellow). Note this is done without onsite help.
Next, change FTD Mgmt interface IP to private IP assigned earlier. This is done from the console in FTD CLI mode.
> configure network ipv4 manual FTD_Private_IP MASK GW
This is important as I’ve tried to SSH to outside while Mgmt was down but still had same public IP and it did not work. Public was removed from Mgmt and ssh to Outside started working.
Ping gateway (port 4 IP) and any public IP. Verify you can ssh to public staging IP from trusted public subnet. If not troubleshoot physical and routing connectivity.
If ssh is a success then update the routing table with manage_procs.pl as root. Select option 4 to flush the routing table and restart communication with options 1,2 and 3.
> expert
admin@FTD:~$ sudo su
Password:
root@FTD:/home/admin# manage_procs.pl
**************** Configuration Utility **************
1 Reconfigure Correlator
2 Reconfigure and flush Correlator
3 Restart Comm. channel
4 Update routes
5 Reset all routes
6 Validate Network
0 Exit
**************************************************************
Enter choice:
Check communication status with sftunnel_status.pl. You will find a reference to connected channels A and B.
root@FTD:/home/admin# sftunnel_status.pl
<SNIP>
Cipher used = AES256-GCM-SHA384 (strength:256 bits)
ChannelA Connected: Yes, Interface eth0
Cipher used = AES256-GCM-SHA384 (strength:256 bits)
ChannelB Connected: Yes, Interface eth0
Registration: Completed.
Switch to ASA CLI and perform packet-trace to test VPN tunnel. Confirm tunnel is established.
Some helpful troubleshooting commands:
sudo tail -f /ngfw/var/log/messages | grep -i sftunnel – FTD to FMC tunnel logs
sudo tail -f /etc/sf/sftunnel.conf – display the manager registration information
sudo pigtail | grep <FMC_Public_IP> – tail logs for messages from FMC
sudo pigtail deploy – tail logs related to FMC deployment issues
pmtool restartbyid ngfwManager – restart Manager connection
manage_procs.pl – restart FTD processes from sudo
pmtool restartbyid sfipproxy – restart FTD tunnel to FMC
sftunnel_status.pl – check sftunnel status from sudo
> sftunnel-status-brief – check sftunnel status from login
/etc/rc.d/init.d/nscd restart – flush dns cache
DBCheck.pl – check DB status
/etc/rc.d/init.d/sensor restart – restart sensor process
Step 8 – FTD final configuration.
Now we need to apply production Public IP and Gateway to FTD. Under Devices > Device Management > FTD_name > Interfaces configure production IP information for Outside interface. Under the Routing tab change the default route to production gateway. No changes under NAT as we are using the interface itself. For VPN update Remote/Extranet node with FTD production public IP.
When done push configuration and monitor for any errors. Verify new IP and routing information in ASA CLI mode. Verify SSH access is allowed from trusted IPs on the outside interface.
On FMC under Devices > Device Management > FTD_name > Device > Management update staging public IP with production public IP.
When FTD is shipped and connected to the Internet all should work as designed. If VPN is down you should still have ssh and FMC connectivity to troubleshoot FTD. Worth case if you have incorrect ISP information. In that case, you will need a console or PC with IP on the management subnet connected to the Mgmt interface. Assign correct public IP to the Mgmt interface and connect ISP to it. Reset sftunnel, FMC to FTD connectivity should restore to make necessary changes and push new IP changes. Revert to the original Mgmt IP once new changes were applied.
2 comments On Cisco FTD: setup for remote site deployment
Excellent post!
Thanks for posting this. I’ve been faced with dilemma multiple times and have done a lot of different options. The worst is definitely having the remote ftd mgmt going through a s2s vpn through itself to the fmc. Too much room for error. I’ve configured the mgmt ip with a public ip (with access lists), and that works pretty well. I’ve also used nat-id with no public ip.
In your article, you mention “ Verify SSH access is allowed from trusted IPs on the outside interface” and that “ If VPN is down you should still have ssh and FMC connectivity to troubleshoot FTD.”. I must be missing something. In your design, how are you able to ssh to the mgmt interface of the remote ftd? Do you have a PAT for ssh from the outside to the remote ftd mgmt interface? Thanks and keep up the hard work!