I'm not authorized to comment on non-publicly-announced future releases from Cisco. I suggest contacting your local Cisco account manager or partner to arrange for briefings under non-disclosure agreement which may shed light on future plans.
That said, Cisco's general direction is to advance the FTD platform towards parity with the rich features already available with ASA-based remote access VPN. Some features may be left behind but the ones you cited are by no means corner cases. I see them commonly used among my customers. I would expect them to be currently under development within Cisco.
Hi there, sorry to go over ground that may already have been covered but I was just looking for some clarification on this. Currently with our ASA devices I have configured 802.1x VPN access that uses an LDAP attribute map checking for membership of a specific LDAP group. Is this not going to be possible with the FTD 2110 devices?
It is not possible as of the current FTD 6.2.2 release.
That's confirmed in the section of the configuration guide covering guideline and limitations for FTD remote access VPN:
We would hope this limitation will be removed in the future but that's the way it is for now.
what are your best practices for deploying branch FTDs with a centralized management if a public IP is used for the FTD mgmt Port?
Just restricting e.g SSH etc... in Devices > Platform Settings?
What you suggest is currently the best available practice on the appliance itself. If you have an upstream router, you can layer in some ACL protection on it as well.
Many of us are hesitant placing control plane interfaces on a publicly exposed address. While some of that is rooted in practice drawn from historically unhardened protocols and implementations, I believe it's a valid concern that remains even with current technologies such as Firepower which uses only the relatively secure ssh and the sftunnel (a proprietary implementation of ssl/tls over tcp/8305) protocols as you alluded.
I would hope to see a more robust implementation from Cisco in future releases but, for now, what we have is a limited set of choices for hardening the branch deployments.
may I ask another question regarding FTDv?
Do you have some experience or best practices using it in a production environment?
From my perspective, due to the performance limitations and license costs it isn't really an option at the moment.
FTDv is a viable option for many customers as there are a very broad set of requirements out there.
I agree that it does have limitations that go along with its capabilities. However the ability to spin it up quickly in a virtual environment (including public cloud) are attractive to many customers. Not everybody needs the performance (throughput mostly) that's available on the hardware-based appliances.
Licensing costs can be a challenge; but we normally defer that discussion to outside the support community.
Site-to-site IPsec IKEv1 VPN is standards-based so there's no reason why it shouldn't work in principle.
My experience is that as long as you're using a common implementation (single link, pre-shared key, the usual transform sets, basic routing with NAT exemption for interesting traffic etc.) that multi-vendor interoperability is not an issue.
Some of the very obscure features may not be currently available but other than that you shouldn't have any problem. The underlying Lina code in FTD uses the same bits as the traditional ASA operating system for this feature.
Can you help me understand the processing difference for IPS and webfiltering of traffic between the Cisco ASA with Firepower and the FTD NGFW?
For example the ASA takes traffic on it's secure interface, and if the inspection ACL matches the traffic it's passed to the software IPS module for processing, then passed back to the ASA for further processing. Is FTD similar?
It's slightly similar.
Ingress traffic still matches any inbound policies and whether or not the Snort engine (usually equated with "Firepower" term) takes a look at it is based on the active Access Control Policy. The classic ASA inbound access list with 5-tuple can be equated to a prefilter rule in Firepower Threat Defense platforms.
There's a pretty good explanation of how it works in this Cisco document:
I got a design/feature question.
If you have two separate 2x10 Gbit Full Duplex Internet connections (asynchronous routing, traffic may go out on one side and come back on the other), and are looking into getting a redundant firewall solution using Cisco FirePOWER 4100 series. What kind of setup and modells would your consider to be best practise? Is it even possible to connect two 4100's together to be able to track all connections in this scenario?
If the asymmetric routes terminate on the firewall itself that will cause it not to work for any connections that are asymmetric. A stateful firewall depends on the traffic returning via the same interface that it egresses.
Thanks. I understand that. My question is really if it is possible to connect two FirePOWER units and let them share the connection tables/states etc. Some other firewall manufactors can do this.
What would you suggest doing if you want to have two active WAN's + redundant FirePOWER's and still be able to keep track of the connections and use FTD's full potential?
This is how I would imagine it could work:
FTD ---- FTD (to share connection tables?)
You can join to Firepower 4110s running FTD in either an Active-Standby High Availability pair or a 2-unit cluster. Neither method supports what you laid out though.
The supported method would be to have an upstream router or routers connected to your ISP circuits. You would then have either provider-independent or a SWIP'd /24 or larger between your router(s) and your firewalls. Traffic would come to your active firewall or firewall cluster. The routers would take care of routing between or among the ISP links.
If you had an HA pair of firewalls, only the active one would get traffic and state is replicated to the standby one in the event of a failure on the primary. If you had a cluster, the cluster control logic would assign a given flow to the owning member according to its algorithms.