Is Cisco Firepower/FTD 6.4 code ready for production?

35 Comments

This is a follow up blog from my initial writeup on the release of Cisco Firepower/FTD 6.4 code release.

I mention in that blog that I had class that week and was going to thoroughly test the new 6.4 code, and then write a new blog on my recommendations, so here we are.

To cut to the chase, meaning that if your busy and don’t want to read anymore, just don’t upgrade or install 6.4 code yet, wait for 6.4.0.1.  Also, it’s worth stating that you should never install a “.0” code if possible.

UPDATE 5/16/19: 6.4.0.1 came out and has solved a couple of the issues addressed in this post. Will update this again once this is confirmed.

Update 5/16/19: I have confirmed that the new 6.4.0.1 patch has indeed fixed the firepower discovery issue with the new FMC installs

Here is a Concerning Issue:

In my six-years of almost full-time work on Sourcefire/Cisco Firepower, I have never seen a problem with RUA/RNA, FireSIGHT, or what we now just call Firepower Network Discovery, and I can almost guarantee no one else has either. Cisco Firepower/FTD code 6.4 seems to have broken that winning streak.

Update: see cisco bug CSCvp59960 (Sev 3)

In the screen shot below, I am showing the three Cisco created objects that I use or you can use in your Networks configuration of network discovery. (No, I did not use all three at the same time, I am just showing you the three I tested with individually for brevity).

Once deployed, go Analysis>Host>Network Map notice that there are no hosts present. This shocked and amazed me (I might have said WTF out loud too)! We tested this and tested this to make sure we weren’t making a mistake, but screwing up the easiest policy in Firepower is not easy to do! Usually, you’ll get data whether you like it or not…

Below, you can see the three manual configuration that we tried, again, all configured and deployed separately. When we deployed the Enterprise group, immediately hosts showed up. We also then tested typing in manually quad zeros, and then the 10.0.0.0/8 manually as well; every time we tested a manual object, Firepower starting worked as it always has…

Here we used a manually created network configuration in Firepower and hosts immediately showed up!

Solution? Use a manually created object, or just don’t upgrade to 6.4 yet.

Is the Juice of Upgrading to 6.4 worth the Squeeze?

From the ACP, you can click on Analyze Hit Counts, and then choose your 6.4 FTD devices and get hit counts via a the GUI. If you click on the rule name, it takes you to the rule itself, and if you click on the magnifying glass it opens and edits the rule. Useful. Maybe not worth the upgrade since you could always use the show acccess-list-config FTD command and get much more information than this provides…but hey, people love their GUI…

However, I’d rather just have a column in the ACP rules that shows you the hit count, for example put this where the Comment count is listed now (that now one gives a damn about), as shown here:

In addition, Cisco was also touting the new FTD command “show rule hits” at the CLI…however, this one made me scratch my head. Looking at the output below of the show rule hits command- that I first had to copy into notepad, so I could then compare the Rule ID to the actual ACP rule set. Seriously.

Remember, you could have always just typed in show access-list, as I did here, and see the hit counts as well…but, it’s not a GUI, true.

Possibly Cosmetic Issue or just plain odd…

When configuring the File/Malware policy with the same exact configuration that I’ve deployed for year, this error message popped up.

Update: please see Cisco bug CSCvp60050 (Sev 4)

I actually thought they had done some work on the new File policy, but no, just press OK here and the rule takes the commands, as it always has. We could find no issues with this, other than possibly a cosmetic message.

MISC

After mentioning this in the last blog, this really needs to be understood:

What Cisco doesn’t tell you here is that once you enable the File and Malware Settings in the global logging tab, you still need to go into Devices>Platform Settings>Syslog and configure the MID’s 430004 and 430005 into the Event List to make this work; and you might as well turn on 430001 (identifies an intrusion event), 430002 (identifies a connection event logged at the beginning of the connection) and 430003 (identifies a connection event logged at the end of the connection) well you’re at it. There is no documentation that tells you that you need this configuration!

Cisco just added these MID’s to the documentation: Cisco Firepower Syslog event messages

The Object Usage screen in Objects, starting in 6.4 is somewhat helpful for telling you the policy an Object is used in, however, it would be nice if it listed the rule number as well.

Also, there are some random issues that I ran into when creating rules: as in that it wouldn’t take the rule, and the Monitor rule wouldn’t, well, log. I can’t reproduce those on command though…also, 6.4 code breaks WCCP.

Lastly, I mentioned in my previous blog that Cisco is moving from Brightcloud to Talos categories for SI and URL’s. This has been delayed until 6.5 code now. Not an issue, just a heads up…

Can’t wait to see what 6.4.0.1 brings us…

 

 

35 Comments

  3. We’ve been testing 6.4 beta and now deployed into pre-production and progress since 6.2.3.x is really not enough.
    6.3 was a mess and 6.4 is still unfortunately not solving our long term issues

    Reply

    1. there are more and more features coming out every week. But they are not up to what the ASA provides yet, but each week it gets better. I understand your frustration.

      Reply

  4. Running Firepower FMC version 6.4 – Just found out Correlation Event emails are not working. The Events happen, but no emails being sent.

    Worked fine in FMC 6.2.3.6.

    Can anyone else test this? Have TAC case open.

    Reply

    1. yes, I will test it, but I’m at a customer today, and can get on this tomorrow!
      thanks for the heads up!

      Reply

  5. I agree you shouldn’t rush for a release just because. But we are forgetting one important new feature that, at least for me, is forcing my hand. The support for Microsoft Azure installation. It’s doesn’t justify pre-releasing an unfinished product but in my case Azure support quite frankly allows me to continue using the Firepower brand all together since my employer is fast becoming an Azure only shop.

    Reply

    1. Yes, that is true, and something not really brought up. The Azure support is great, but you can’t do a lot with FTD and Azure still….

      Reply

      1. I wouldn’t say that. With and vFTD in Azure acting as the IaaS firewall you can basically set up a multi-zone network in Azure just as on any physical implementation and do away with the awkward Azure Network security groups. Now with 6.4 you can have the vFMC “on site” as well which for me greatly reduces the strain on our hybrid links.

        Reply

        1. there were a couple things that stopped me from using azure for my FTD classes, things like no HA and no sub interfaces at this time.

          Reply

        1. there were a couple things that stopped me from using azure for my FTD classes, things like no HA and no sub interfaces at this time.

          Reply

        1. Hi Matt.
          I like 6.4.0.1
          there are a lot of features that I blogged about and I really like it. I a large medical company on 6.4.0.1 and averting is going great. If your not in a hurry, you can wait until the end of this week and I promise I’ll know more
          Todd

          Reply

  7. Hi Great blogs and comment though I would post my experience so far

    Waited for 6.4.0.1 as you do and this is for HA Paired devices

    Carried out upgrade to 6.4 followed by 6.4.0.1 patch of FMC (No problem) followed by FTD Devices this is where things started to go a little wrong taking a day to work out solutions or workarounds. Firstly Passive showed as constantly in Sync even after leaving overnight resolution was even if not listed for 6.4

    https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc81801/?rfs=iqvred

    Next problem we have NAT rules translating both Destination IP and port (Working on 6.3) re-deploying on 6.4.0.1 gives up an error saying something along the line of can not map nat port. Changing to ANY other source and/or destination port gives the same error removing succeeds even creating new rule or changing Dynamic to static all fails

    Moving rules from the default NAT Rules Before to NAT Rule After and it works

    Reply

    1. I have seen the HA issues, and sent them to Cisco. They haven’t been able to replicate it of course, but I can see it all the time. It has something to do with versions, even though I install the same software exactly, it doesn’t show they are the same. Very odd!

      The NAT issue is new to me. I’ll have to test that

      thank you for posting!

      Reply

      1. Following up now 6.4.0.2 is out NAT issue is still there but we found the problem is due to we have sub interfaces but the interface has a security zone also. As not needed removed resolves the problem that was fine on 6.3

        Also https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp70543 matches the same or similar errors given in transcript just for Firepower Appliances rather than ASA

        Reply

        1. Hi Roy, yes, we had to down grade to 6.4.0.1 again…we ended up with the same HA issue…I guess we’re all waiting for 6.4.0.4 now..

          Reply

    1. Hi Todd, any luck with 6.4.0.4 with FTD’s? I’m planning to install them this week on all of our FPR-2110’s, wonder if HA will break. I’ve already consulted with Cisco TAC but they didn’t mention anything about HA breaking. We’re moving up from 6.2.3.13 tp 6.4.0.4. Thanks.

      Reply

      1. I did run 6.4.0.4 in my class last week with 12 people and we had no issues, however, we never got to the HA lab….the problem with the HA issue is that it doesn’t show ups right away…it takes a couple days to see the issues arise mostly…sorry that I don’t have the answer right now, but I’ll work on it!

        Reply

  12. As per TAC, there is a patch for the HA issues – 6.4.0.2 Hotfix F, shouldn’t be a problem when on 6.4.0.4.

    “CSCvq34224: Firepower Primary Detection Engine process terminated after Manager upgrade

    If you already upgraded to Version 6.4.0.2-34 and have FTD devices configured for high availability, apply Hotfix F. In FMC deployments, apply the hotfix to the FMC. In FDM deployments, apply the hotfix to both devices.”

    Reply

  15. Hello all!

    Wccp redirection works on 6.4 like a charm!!!!

    We tried it on a lab with virtual ftd (6.4 & 6.4.0.4 ) and deployed also today on a customer environment with ftd 2120.

    > show wccp

    Global WCCP information:
    Router information:
    Router Identifier: 192.168.254.1
    Protocol Version: 2.0

    Service Identifier: 90
    Number of Cache Engines: 1
    Number of routers: 1
    Total Packets Redirected: 169
    Redirect access-list: ACL_WCCP_REDIRECT
    Total Connections Denied Redirect: 3575
    Total Packets Unassigned: 0
    Group access-list: ACL_WCCP_WSA
    Total Messages Denied to Group: 0
    Total Authentication failures: 0
    Total Bypassed Packets Received: 0
    > show version
    ———————-[ ftd1 ]———————-
    Model : Cisco Firepower 2120 Threat Defense (77) Version 6.4.0 (Build 102)
    >

    access-list ACL_WCCP_REDIRECT line 2 extended permit ip host 10.1.3.44 any log informational interval 300 (hitcnt=643) 0xcca8978c

    Regards,

    skra

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *