Well, this is probably more than a rant as anything else, but it this point I am not just disappointed with the whole ASA Firepower implementation but quite mad at Cisco for tossing out a product with promises not delivered.
Especially the ASDM Management of the FP Module (on a 5512)
The URL Filter
What point does any URL filter have, if it is not filtering correctly?
You can block porn all day long, yet it can not even prevent the number one hit on google search for porn.!!! SERIOUSLY?????
Just in case my number one hit is different than anyone else's, it is pornolaba.com.
While it is listed as adult on brightcloud, the FP module (mind the ASDM Management Version) is not capable of preventing the page from opening and displaying all of its content. While it somehow prevented playing vidz inside the browser, it let me download them as video files (well, the browser just popped up with "where to save the mp4 to...)
I have the same setup running on a 5506 with the Management Center, it seems to work better there (at least no video download) but I was able to view the main site too.
For all of you suggesting to use an Ironport,,,blah blah... if I wanted to use one I would have, I am talking about a simple url filter, which FP is supposed to be, I do not need a dedicated appliance for that, especially a way to expensive Ironport.
Besides that, even if porn is the only blocked cat. that I have configured, other sites (due to the IDS I guess) are opening extremely slow at first. Maybe because of the brightcloud lookup. Mainly on sites with lots of external links or distributed on Akamai.
(Fun part is, I can see SFP drop request from its own ASA management interface connecting to brightcloud.)
Any open source web filter can do better than this implementation of an URL Filter.
ASDM Management of FP
That is another ugly example of not doing anything right. Response time, reaction time is slow and I mean slow. Why put this into the ASA, if the CPU cannot handle the load? Besides it being really sluggish, compared to the management center on VMWare, it feels like half the features are missing, reporting is utterly useless, or settings are just spread over different parts of the gui compared to FPMC.
In a long run, or really doing it right, the ASDM implementation is pointless. And why the hell is this still JAVA??%$%#^@$#
JAVA SUCKS - GOT IT? - I have several VMs running due to the fact the there is nothing as incompatible as Java. Every pity java app will only run with whatever version it feels like - one 0.0.0.0.0.0.0.0.01 minor update - not working anymore.
NO ONE NEEDS JAVA - GET A REAL PROGRAMMER AND WRITE THIS IN C or at least something other than Java.
So, we determined the ASDM implementation is useless, now we have to PAY for a management center that is needed in order to correctly configure a feature that has been sold with the ASA? And no one felt the need to mention that on the ASA website?
Granted, the 2 device lic is fairly reasonable priced, but it still has a price and for something necessary to configure a feature sold with the hardware, that I find a questionable business practice.
Furthermore, comparing the price tag for the higher license like 10 devices - that is as always so much overpriced that is stand in no comparison with the price for the module and/or hardware.
But even if we overlook that, WHY IS IT NOT RUNNNING ON Hyper-V?????????
Why is Cisco clamping down on it so hard to only run on VMware or KVM? Well maybe because their business policy is similar to Cisco? Overpricing and ripping customers off?
There is NO - absolutely NO reason to force customers to use VMWare or KVM. Any virtual implementation should be available on the platform of my choosing. There is no technical reason for it not to work on Hyper-V or Citrix or whatever. Others can do it too.
Cisco should be aware that there are more and more companies are pushing into the market and every year there is more and more that Cisco has to share with others BECAUSE of things like that.
Last but not least,
ASA Access Rules, FP Rules
If I have permitted ACLs, I have permitted them for a reason. FP seems to ignore that and just blocks communication on that port.
For example I have external connection from a static IP to an ASA on port 38000 which is by nat/pat translated to x.x.x.x / 3389 - yes RDP.
But as soon as I flip the switch, the FP is blocking all connections to that port. REALY?
I had to do another PERMIT on the Access Control in FP? SERIOULSY?
Also we manage quite a few ASAs for customers, where is the option to manage the FP Module from a Public IP AND internal IP?
Also it is not wanting to cooperate when doing it through a vpn tunnel and with source nat. Bummer, so I have to have a VM at all sites to manage the FP internally... at least I have not seen any other way as of yet.
Now of course it could be that this is all some bugs, or a coincidence of unfortunate configuration events that lead to all this, but I am using latest updates, even rebooted twice.
Ok done. Lets conclude:
- URL Filter not working as it should, ESPECIALLY porn site are not getting blocked correctly. For most customers, that is a no-go.
- ASDM only java - becoming more and more a problem especially since Chrome and IE dropped it.
- FP Management on ASDM is half baked, slow, sluggish, looks different compare to FPMC, reporting stinks
- FP MC, works, menu structure feels a bit criss-crossed, BUT it has a price tag for what should be free. Also higher license versions (other than 2) are way to expensive. Only web based, thus slow, power hungry, would it be written in a real programming language it would be much better and faster as a real application. Reporting actually works well.
Unfortunately all of Cisco Software Suits are overpriced by a factor of 10.
- Supports only VMware,KVM, no logic behind that other that Cisco has VMWare shares. Ignores other VM platforms
But maybe all this is just a fluke and gone by itself tomorrow...or maybe the documentation sucks and I was not able to find the needed parts...
I understand your frustration. A rant after encountering limitations and bugs is understandable and necessary for vendors to take problems seriously.
I will try to explain some of the issues and tell you my opinions, might help :)
1) Firepower ASDM Management
It is a bad implementation full of bugs and not maintained very much because there is more focus on Firepower Management Center and the new Firepower Device Manager (for FTD). IMO it should not be used by anyone. I know using a VM (FMC) to manage a single firewall seems like an overkill but its worth it. ASDM Management will die off sooner or later, it has been a dirty hack to provide on-board management without FMC.
2) URL Filtering
To understand why this is happening, understanding the url filtering architecture might be of help. Firepower uses the Brightcloud database for url filtering which is about 400MB and stored in a shared memory segment on the firepower module. Since smaller ASAs have less memory, the 400MB database cannot be loaded into memory and another db with 30MB is used. To work around "unknown" URLs a flag can be configured to lookup unknown URLs online if they cannot be found in the local database.
tl;dr low-end ASAs url filtering has limitations when it comes to categorization
3) Using WSA to work around URL Filtering bugs and limitations
I am with you on that one. Using an additional product is not acceptable. 6.2 will be focused on stability and many bugs considering url filtering should be fixed by then.
4) Firepower Management Center
We might see Hyper-V support in the future. Since many shop deploy VMware / KVM I think Hyper-V hasnt been a high-priority roadmap item, but I understand the frustration for MS-only shops.
FMCv 6.0 looks like it does not need a device license for devices (encountered during a recent installation), but I will ask a cisco rep, since it isnt documented anywhere.
Considering performance... They definitely need to do some refactoring and solve performance issues. Many api calls / db queries just fry a single cpu core which leads to performance issues.
5) Access Rules
Using ASA + Firepower Services can result in a somewhat redundant ruleset depending on how you design your firepower policy but other approaches might solve this (e.g. only blacklisting + permit any any with inspection). Another possible workaround is an any-any ruleset on ASA side and only configure policies in firepower (more suitable for smaller deployments).
Using the converged image (FTD... ASA+Firepower Code in one image) makes this issue obsolete, but FTD does not have feature parity yet.
6) Management via Public IP
Why not NAT/PAT the management interface IP of the firepower module and only permit access from your FMC? Works fine without issues.
Let me know if you have any question.