Cisco FTD: setup for remote site deployment

 

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.

  1. configure FTD at the staging site with limited onsite availability
  2. ssh remote-access after shipping to the remote site
  3. recovery in case of FTD/FMC communication failure

Step 1 – Design overview.

I was entertaining 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 braking 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 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). 1 and 5 can be any other Vlan for now.

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 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 but it can be a bridged port also. 

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.

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 drop into ASA mode) and paste them to Extranet device (if it is an ASA for example). 

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

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 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/logs/messages – various 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

sftunnel_status.pl – check sftunnel status

/etc/rc.d/init.d/nscd restart – flush dns cache

/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 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. After new device IP is updated on FMC, FMC to FTD connectivity should restore to make necessary changes and push new policies. Revert to the original setup once new policies were applied.

Leave a reply:

Your email address will not be published.

Site Footer

Sliding Sidebar