First look

When you first log into the FTD for FDM with a browser you will see a nice graphical interface of the units with proper color coding (i.e. green means good and orange mean bad/warning). The GUI does not need flash nor java or any other obnoxious plugins.

My first though when seeing the network diagram was that it felt pretty but also somewhat “hard coded”, meaning that its good for standard perimeter SMB deployment but may not be what you want for an enterprise deployment (where granted you would be using the FMC console instead).

Is default configuration and hard coded diagrams bad then? Not really! Keeping in mind that the scope for FTD on FDM deployment is SMB and even smaller SOHOs the chances are that the pre-configured setup is the one you want.

Security Policies

When the device is properly setup with interfaces and routing (note only routing mode is available with the FTD on FDM. This is very seldom a problem however), it is time for configuring some rules (note that the old ACL style rule no longer exists). All policies are made with a Wizard approach, which means that you are guided through most of the options. This is very convenient for administrators not having a  CCIE in security or similar and is very fitting for the target segment.

Two essential pieces of configuration is needed for a skeleton perimeter firewall.

1. A dynamic PAT (Port address translation) rule to source NAT all outbound traffic
2. A security rule allowing for outbound traffic

The following describes the lazy mans approach (or lab approach). The all famous Permit-Any-Any (note that when using it like this it is a both inbound and outbound permit!)… Adding security scanning (URL/AV/IPS) is trivial as the feature are simple enabled on a per rule basis. I could imagine quite a few configurations will be made over time with this simple setup.

Creating a security rule on the FTD is very straight forward and looks more or less the same as on all NGFWs. Cisco FTD has also embraced the zone based interface concepts which is particular nice. The (optional expandable) rule diagram may suit some however I prefer to keep it off.The PAT rule is also easily done, through the Wizard and ends up looking like this.

One thing to remember is that whenever changes are made to the ASA they need to be actively deployed to the device (top right corner).

Setting up auxiliary services

The FTD will allow you for setting up a bread-and-butter DHCP server for the internal network. It does not however provide capabilities for DHCP options (not even gateway, which has to be the ASA itself). This is not a problem for most people, but for more enterprise environments it will properly be to basic for the task. There is no DNS server on the box itself, but the DHCP server has the option of choosing Cisco Umbrella as the resolver (basically just setting the Umbrella IPs for the DNS servers in the DHCP response).

VPN and Remote Access VPN (Anyconnect)

VPN are supported for Site-2-Site connectivity. They are still policy based (as they were in the old ASA) and not route-based, but I guess it is a matter of taste. It was a disappointment to find out that Remote Access VPN is not supported on FTD with a ASA platform.

 

Monitoring the Device

There is an entire tab dedicated to monitoring the device. They are roughly divided into two areas

1. Dashboards, which provide summery and statistics with various angels.
2. Event, which is the ‘realtime log’ with all the relevant data (which serves as the data source for the dashboards). This page is a huge step up compared to an ordinary ASA as historic logs for local troubleshooting is also available.

The monitor offerings of the FDM is of course very limited compared to the enterprise FMC. But it does provide necessary tools for people without an enterprise console and is a good step up for smaller installations. Log forwarding to other systems is also fairly limited in the FDM deployment.

Wait… what about CLI?

Until now I have only spoken on the GUI. This is for a good reason. The CLI for the FTD is unfortunately very limited. There is still most of the ASA show commands but as far as configuration goes is has very little to speak of. This was actually led to quite some frustration in my lab as I could not manipulate routing on the data interfaces through CLI (only management routing can be done). This will hopefully change down the road, but arguably CLI is mostly used during the setup phase of an implementation, and may thus not be a big deal for everybody.

Final though

Overall I find myself liking the FDM for FTD. It does have a narrowed feel to it when you are trying advanced stuff but when you think of it, this is not what (I think) it has been designed for! It is not meant to be enterprise grade management with all the features needed here. The FDM is more targeted a more limited deployment which I think it hits spot on (sure I would like some improvements here and there). The biggest let-down in my opinion for the target audience is the lack of the Anyconnect capability, but this is said to be included in the next release (fingers crossed).

I would still recommend however that anyone requiring more complex configuration, multi-box management or monitoring still going directly for the Firesight Management Center.

—-

Ps. If you wants to see more screenshot of the entire ‘getting it up and running’. This blog has a quite extensive amount.