The Quiet Release of the New Cisco Firepower/FTD 6.4 Code

85 Comments

The new Cisco Firepower 6.4 code has some great features. Something for Cisco to be proud of, and I’ll list a few of the top ones in this short article. However, it seemed to me that this release had less fanfare than say the “make it or break it code of 6.2.3”, or the “powerful 6.3 code” releases. Why? is it not as quite as powerful or full or fixes and features? Sure it is; not as much as 6.3, but still a good amount and worth the upgrade.

My thought is that we’ll see that they will make more use of this new code at Cisco Live when they announce some new all-so-powerful FTD devices. For example, you can’t run multiple instances using both ASA and FTD code except on the 9300. The existing 4100’s do not support it. In addition, the low-end 5506 doesn’t support anything above 6.2.3 code. Let’s see what Cisco Live brings us with the new 41×5 and 1000 series devices running the all-new-powerfull 6.4 code.

Worth the upgrade?

Sure, read on and find out. I believe the change in objects is worth it alone. However, they were very clear in the documentation that it’s a faster upgrade and that you’ll see faster deploy times. I upgraded over 20 FMC’s and the 90 minutes was about the same as 6.2.3 to 6.3. Also, there is zero time change in my deployments, but maybe you’ll see different results with this (hopefully!).

Non-Documented Changes

I could not for the life of me find these two new features in the Cisco Firepower Release Notes, Version 6.4.0: Object Usage and URL Categories

Object Usage

This is a pretty great new feature: You can now click and find the Object usage.

You can’t however see what rule the object is used in from here, but you can click on the Usage Policy listed, and it will take you to that rule. Very useful.

In In addition, and not such a big deal, this didn’t warrant a place in the documentation either, as they now put the Objects in alphabetical order, something I find annoying now, but I’m sure I’ll get used to it.

URL Catagories

Another big change, and again not documented, is the URL categories. Firepower will now utilize categories from Cisco’s Talos and not brightcloud. https://www.talosintelligence.com/categories 

[UPDATE 5/2/2019: The new URL categories for 6.4 were not implemented in this change as discussed in the beta, so 6.4 is still using bright cloud. This feature has been moved to the 6.5 release.] Here is an example of the new categories:

The ACP has two good changes:

First, you can now configure an external syslog server to receive file/malware events, which are generated by file policies configured on access control rules. Important: File events use message ID 430004, malware events are 430005 (this is not documented in the Cisco Syslog Documentation).

What Cisco doesn’t tell you here is that you still need to go into Devices>Platform Settings>Syslog and configure the MID’s 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.

UPDATE 5/1/19: Cisco just added these to the documentation: https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/b_fptd_syslog_guide/security-event-syslog-messages.html#id_105507

Also new inside your ACP is your Analyze Hit counts for your PreFilter and ACP. We’ll see how good this really is as my customers upgrade, but it sounds good.

There are some new CLI commands for this feature as well such as show rule hits that can be run on your FTD. Also, the show failover now contains object static counts related to syncing hit counts between HA peers

Enhancements & Improvements

There were five enhancements to the Firepower Threat Defense Encryption and VPN, however, this is the one I was waiting for the most:

RA VPN: Duo as first factor in two-factor authentication. You can now use a Duo proxy server (which also acts as a RADIUS server) as the first factor in RA VPN two-factor authentication

There were also five enhancements to the Events, Logging, and Analysis of Firepower.

Here is one of them: Cisco Threat Response (CTR) integration via System > Integration > Cloud Services

Cisco Threat Response is a new Cisco offering that you will be able to integrate with Firepower Threat Defense deployments. CTR’s powerful analysis tools will allow you to integrate Firepower event data with data from other sources for a unified view of threats on your network.

Also, Splunk users can use a new, separate Splunk app, Cisco Firepower App for Splunk, to analyze events. If you use Splunk, you need to check this out as it’s pretty cool, plus estreamer is going away soon: https://splunkbase.splunk.com/app/3663/

Connection-based troubleshooting

Connection-based troubleshooting or debugging provides uniform debugging across modules to collect appropriate logs for a specific connection.

It also supports level-based debugging up to 7 levels and enables uniform log collection mechanism for lina and Snort logs.

debug packet start, debug packet start, show packet debugs and clear packet debugs are the new commands

Performance

Snort restart improvements for 4100/9300 devices: Before Version 6.4, during Snort restarts, the system dropped encrypted connections that matched a ‘Do not decrypt’ SSL rule or default policy action. Now, routed/transparent traffic passes without inspection instead of dropping, as long as you did not disable large flow offload or Snort preserve-connection.

Faster access control The Version 6.4 upgrade process enables egress optimization which  is a performance feature targeted for selected IPS traffic, and this enhances access control performance. Cisco TAC strongly recommend you leave this feature enabled. from the CLI use the command asp inspect-dp egress-optimization, but this is enabled by default and you should leave it as so.

Faster SNMP event logging Performance improvements when sending intrusion and connection events to an external SNMP trap server.

Faster deploy: Cisco mentions that they made improvements to appliance communications and deploy framework for faster deployment times. However, after my upgrade the deploy time was about the same as it was in 6.2.3 and 6.3. Will keep an eye on this one.

Lastly, there were quite a few new features available in FTD 6.4 when configured using Firepower Device Manager (FDM).

85 Comments

  1. Did you upgrade the FTD to 6.4 as well and then test Deploy time? Or did you only upgrade the FMC? I believe you will see an improvement in deploy time once both devices are on same version.

    Reply

    1. Hi Jonathan, thank you for your post
      I did both, and I received the same deploy time with both, which were the same as 6.2.3/6.3 deploys
      I have a full class this week and I will get a lot of perspective with the code!
      I’ll post again at the end of this week!
      Todd

      Reply

      1. I will update you on our deploy times once I upgrade (currently on 6.2.3). I have heard of others saving a few minutes on deploy. Hopefully it helps us.

        Reply

        1. so I added two 6.4 devices and the deploy time was a lot faster, but it’s not apples to apples, as the 6.4 devices had 16G or Ram and 8 cores, more than twice my other devices

          Reply

          1. Cool. I upgraded one 2110 FTD and now our WCCP redirect isn’t working and getting two security intelligence list feed errors. Not cool.

          2. Hello Jonathan, is it possible to provide the case number for that issue ? also what was the resolution

    2. Just sharing my deploy time experience. I have 3 2110 FTD’s talking to a Virtual FMC. The FTD’s are all configured the same with 1Gb interfaces. Right now I have 2 at 6.3.0.3 and one at 6.4.0. First of all I saw a significant deploy reduction when I went from 6.2.3.x to 6.3.x. I cut about 30 to 40 seconds on average off the deploy times after I switched. I could easily confirm this by only upgrading one FTD and then deploying the exact same config to all 3. The one that was upgraded to 6.3 always deployed faster. I did this same test after upgrading the one to 6.4.0 and so far I have not seen any improvement over 6.3. All of my deployments have been the same over all 3 FTD’s. I am looking at about 1:35 deploy times. That does bring up a curious question. What general deploy times are you guys seeing?

      Reply

      1. I have two 5506 FTD with 6.2.3 and two vFTDs with 6.4
        the 6.4 code are faster, but it’s not a fair comparison as the 6.4 has 8 cores and 16G or ram….
        I’m seeing upward of 6 minutes, with all policies configured..

        Reply

  3. Can anyone give me info on WCCP configuration, we have FTD’s 2120’s and want to use Baraacuda devices but not inline, HELP

    Reply

  4. Hey Todd,

    I upgraded FMCv and 1 FTD to 6.4.0 from 6.3.0.2 and under Status|Product Updates FMCv shows Current 6.4.0 and Latest 6.4.0. But the FTD’s show Current 6.3.0.2 and 6.4.0 but the Latest show 2019. Have you seen this on any of your deployements?

    Reply

    1. you mean one 2110 to 6.4? Yea, it’s not ready yet. I had too many problems this last week. 6.3.0.2 is great…wait for 6.4.0.1

      Reply

      1. Yes. To 6.4. HA FMC pair upgraded fine and don’t see any issues with that.

        Time for TAC I guess. That’s too bad. Was hoping for no issues.

        Reply

        1. so most of 6.4 worked fine, yes, but we found issues and I haven’t had time write them up yet….we found a serious issue, and then a few not so serious issues….I’ll create a new post soon…
          Jonathan, always just ping me before you upgrade, I won’t mind getting an email…about 100 people do every time code comes out…I get to test it seriously in production (not beta, but in real life area’s) when it is released. my response to my customers were NO on 6.4 for now…there is great stuff here, just wait for 6.4.0.1

          Reply

          1. 5 hours on phone with TAC. 6.4 breaks WCCP. Had to reimage production firewall. 2110 FTD. Not fun.

          2. Did they not know this, and why it took so long? No, that is not fun….we’ll have to remember to never do a .0 code again! Sorry Jonathan!

          4. Hi Earl, yes, you should read all my posts on 6.4, and now 6.4.0.1
            there are some great features with 6.4, and 6.4.0.1 solved the problems I mention in this post
            thanks for writing
            Todd

      1. Thanks Jonathan for confirmation. I’m glad you guys brought up the issues before I upgraded my production FTD’s. I did upgrade FMC though. Should I revert that back to 6.3 or will I be ok with Judy leaving the FTD’s at 6.3?

        Reply

        1. Thanks Jonathan for confirmation. I’m glad you guys brought up the issues before I upgraded my production FTD’s. I did upgrade FMC though. Should I revert that back to 6.3 or will I be ok with just leaving the FTD’s at 6.3?

          Reply

          1. I have mine at 6.4 and it is good, but I did have the Firepower Network Discovery issue, but I used the workaround.

          3. In 6.4.0 code, if you used a default network object in your network discovery, such as RFC1918 group or individual objects, then no hosts would be found with Firepower Network Discovery. You could type in the IP address or use a custom object and it would work. They fixed this rather quickly after 6.4.0 release.

      2. So my Geo-location updated to the latest version over the weekend and now my latest is showing correctly. Can’t say for sure that is what cleared it up but that is the only thing that changed.

        Reply

        2. Roy,

          Yes, mine is fixed now too. Showing correct update version. No more 2019 (which didn’t even make sense)

          Reply

  6. Hi
    Anyone give me info on configuring the FTD for WCCP redirection to 3rd Party devices please.??

    Reply

    1. That is just one thing I have not done. I hope you find your solutions! Maybe call barracuda?

      Reply

    2. good morning. This is one thing I have not done, and I hope you find your solution soon. Did you call barracuda?

      Reply

    3. I have done this for Websense on FTD 6.2.3. Pretty simple. using flex config, as you do it regularly in ASAs.

      Reply

    1. Hi Roy, they list a couple fixes in the release notes, but Im at a customer and will need more time before I can get to this, but I will shortly! I know other people have started testing! Will post results!
      thank you!

      Reply

  8. I just thought of something that has been annoying me since day one. I use a custom block page for URL filtering. Has anyone found a way to show the category of why the user was blocked? I have not been able to figure that out. Right now I just have it to where it shows the URL they accessed with a hyperlink to talos so they can click to show the category. But that is cumbersome and not very clean. I have been wanting to just integrate it directly into the page but can’t seem to get it going. If you have done this your help is greatly appreciated.

    Reply

  9. Got a new one for you guys. FMCv is 6.4.0.1 FTD 2110 is 6.3.0.3. Setup a correlation Policy to email on rule hits. The events are happening but nothing is emailing. I can see the events in correlation events to confirm and it shows the policy and rule being generated. I know email is working because the email relay test works and other events are emailing. Just none of the correlation events. Have any of you seen this or can duplicate? I did not have any setup before so I can’t say if it has ever worked on prior versions.

    Reply

    1. Updated the FTD to 6.4.0.1 to see if that would be the fix and it is still not emailing. So it is either a problem with 6.4.0.1 or I have something horribly wrong going on. I did test the relay again to make sure it was working.

      Reply

      1. OK Nervermind. I found the reason why it isn’t working, “external email alerting is not supported for connection events”. Although not really sure why that isn’t an option.

        Reply

    2. So I have a lab that uses a rule when its hit that generates and email. I think if you were plain connection events, than that is the issue as you stated, but I know I can get it for a particular rule hit

      Reply

    3. Roy,

      This worked for us in 6.2.3.6. Now that I went to FMC 6.4, it broke. No longer works. I am seeing the exact same thing you are.

      I have a TAC case open on it. They are trying to help me out. No luck as of yet.

      Reply

    4. Cisco is able to reproduce this in their LAB. I have a ticket with them. This seems like an issue in the 6.4 code.

      Reply

          2. Sorry been away for a while. I didn’t get it working and thank you Jonathan for figuring out it is a bug. Kind of sucks that we have to wait that long for it to be fixed but at least they are looking into it.

  10. Are the SNORT restart improvements to the point that when an IPS policy or VDB update is deployed it won’t cause traffic disruption? We use a pair of FTD 4110’s (on 6.2.3.10) as a datacenter firewall and one of the major headaches is not being able to update the IPS except during scheduled outage windows because these deployments always causes a 3-second disruption in traffic. This creates havoc with some of the more sensitive applications trying to communicate during this window a version that resolves this is highly anticipated for us.

    Thank you for makings these blog posts and sharing your experiences.

    Reply

    1. Great, thank you for posting!
      3 seconds seems like a long time for a 4110. Its possible if you have a lot of big policies I suppose.
      The 6.4.0.1 seems faster, but only when I am running the devices and FMC all at 6.4.0.1
      I believe it would be faster than any version of 6.2.3, but you’d still have to test it.
      Been beating the hell out of 6.4.0.1 and it is pretty stable with good features. Maybe worth a try!
      Backup first! :)

      Reply

  11. I have been struggling to get DUO as a secondary server for RAVPN on FMC 6.4 has anyone got this working?

    Reply

  14. Hi

    We went from FMC (FMC4000) 6.3.0.1 to 6.4.0.2 on Thursday evenign last week and have had a loads of issues following the first deployment to larger devices (we have a lot of 55xx devices). 4 of our 5525 clusters stopped allowing dns, our two 5545 and 5555 clusters (used for Site2Site VPNs) started crashing with SNORT process issues (SNORT just craps out and following the initial deloy of updated SRU (first deploy updated snort then timed out, second+ deploy just timed out with “waiting for SNORT”). In the end i managed to deploy to one only after downing the interfaces on it and manually restarting the snort process. TAC have been zero help so far.

    I have a TAC call open, the only way to get the devices operational was to switch off most of the network analysis rules and set the firewall to any-any allow. We think it’s the IPS rule set that is teh cause of all this and somethign fried it when we went to 6.4.0.2.

    We have been desperate for this upgarde as our deployment screen had got to 5 minutes plus before offering a device to deploy and this version fixes that.

    Regards

    Matthew

    Reply

    1. Matthew, turning your devices into hubs isn’t much of a solution, but one I see way too often
      If you’d like, I’ll login with Webex with you and take a look with you. email me [email protected]

      Reply

          1. Hi

            Cisco released 6.4.0.2-35 this week and pulled 6.4.0.2-34, plus they release Hotfix F

            Apparently if you went up to 6.2.3.14, 6.3.0.4 or 6.4.0.2 (FMC only) and you had any HA devices you could have the symptoms we had (basically the firewall stops working, snort crashs, HA fails etc..)

            They have updated the bug report

            https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvq34224

            I even had an email from Cisco warning me becuase i’d downloaded the 6.4.0.2-34

            Our records indicate that you have recently downloaded a Firepower 6.4.0.2-34 image from Cisco.com. A bug was found on this version that impacts Firepower Threat Defense (FTD) devices when deployed in High Availability (HA) mode. This bug, CSCvq34224, can cause failures to occur in the detection engine, resulting in traffic disruptions. In some cases this may also result in failovers and deployment failures.

            The problem may not be immediately observed upon upgrade. Once the management device is updated, and a deployment is done, the symptoms of this bug may be encountered.

            NOTE: If you are NOT using Firepower Threat Defense in High Availability (HA) mode, this bug will not impact you and no action is required, even if you have installed the impacted version.
            NOTE: If you are using Firepower Threat Defense in High Availability mode, and have already updated to the impacted version but have not encountered the issue, it is still highly recommended that you follow the steps below to avoid encountering the issue.

            What to do if you have already installed 6.4.0.2-34:
            Install 6.4.0 Hotfix F (from CCO) on both FMC and managed devices

            Cisco recommends that you install the hotfix on all devices, starting with the management device. If your Firepower Threat Defense High Availability pair is managed by an FMC it is not required to update the FTD devices, but it is recommended in the event that you want to use Firepower Device Manager (FDM) to manage these devices in the near future.

            What to do if you have downloaded 6.4.0.2-34 but have not yet installed it:
            You should delete the build 34 patch (i.e. Cisco_Firepower_Mgmt_Center_Patch-6.4.0.2-34.sh.REL.tar) and download the build 35 patch from CCO (i.e. Cisco_Firepower_Mgmt_Center_Patch-6.4.0.2-35.sh.REL.tar) and install this instead.

            More information related to this issue can be found at the following link:
            https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvq34224

            Regards

            Matthew

          2. thanks, Matt, for letting us know about this! We had some issues in class and I couldn’t figure out what was wrong with our HA!

          3. So did the FTD devices have to be on 6.4 code as well? Or just the FMC?

            I have installed 6.4.0.2-34 and have HA pairs but have not noticed any issues that I can tell. Our FTD devices are not on 6.4 however.

        2. We hit this too twice. Because the “hotfix” still crashed it. Then when they release 6.4.0.3, the 6.4 ASA w/FTD code in HA work, and then it breaks my 6.3.0.3 FP 2130s in HA. So now, we have to wait till 6.4.0.4 to hope it is all patched as they say it will be. Too many long nights on the phone with TAC and hit 3 sev 1 bugs. Amazing. 6.4 has NOT been kind to the HA department. Apparently, they are mostly FMC bugs doing this too, not actually related to FTD unless you are using FDM instead of FMC for management.

          Reply

  15. Jonathan, I had all my devices as 6.4.0.x and we had the problem constantly.
    thanks for posting!

    Reply

  16. Another unrelated question. I have been having a problem since day 1 of installing my 2110’s. I have a VPN tunnel between two of them and I can only get around 120Mb across the tunnel even though the circuits at both ends are 1Gb and I can get those speeds over the internet, just not the tunnel. I have had Cisco working on it for months. On my 5th Engineer now. Has anyone setup a tunnel with the FTD’s, especially the 2110, and if so, have you gotten full speeds?

    Reply

  17. The new GUI hit counter is not accurate. Have you noticed that? I do not know where they are getting the hits from for that. I don’t think they are combining the hits from the different parts of the system (access-control-config vs. access-list)

    Depending on what type of rule and traffic, it could make a hit in either of those access lists.

    The GUI hit counter is not even close to some of my CLI output hit counters. I was excited for this in 6.4 but now can’t even trust it anyway seems like.

    Reply

      1. Yes, I agree. Lots of “0” hits, but that doesn’t mean you can remove the rule cause I see hits in the CLI in one or the other lists. Crazy!! Who the heck is programming this stuff??? :)

        Reply

  18. yea, but at least I have got to the top and they are seriously working on it…they can reproduce easily enough

    Reply

  19. Hi Todd, I have an upcoming installation for 2 Firepower 2130, I have to configure it using FDM as there is no FMC available physically or virtually. I am planning on running BGP or OSPF for routing in the firewall and to do SSL resigning. Could you please suggest me what code is the most stable one when it comes to routing, HA and resigning from FDM prospective?

    Reply

    1. 6.3.0.3 is the least I have my customers run. Some are running 6.4.0.3 which is okay and has more features. so nothing below 6.3.0.3

      They are making FDM better in 6.5.x code, but I don’t think any FMD can do all you are trying. It’s possible though, did someone tell you it could? please let me know! I’ve never seen or heard that it could do that much…

      Either way, I HIGHLY recommend spinning up a vFMC…it’s easy and cheap…

      Reply

  20. Currently upgrading one of our two AMP8150’s via the FMCv. From 6.2.3.13 to 6.4.0 then 6.4.0.3. The other AMP8150’s took about 4hrs 45mins for the main code then about 36mins for the patch. They all reside on the same location. Has anyone experience this? Is this expected?

    Reply

    1. 6.2.3 to 6.4 can take a while, but mine usually took about 1.5 hours on the virtual FMC. That does seem like a lone time, but is it up and running okay? Any errors?

      Reply

  21. The other AMP8150 took a total of about 7hrs 30mins in total. That’s 6.4.0 then the 6.4.0.4 patch, also the policy application after the upgrades. So far so good but I’m more worried of the FTD’s, if HA will break.

    Reply

  22. In the above article you mentioned that “estreamer is going away soon” are there any links you can provide for details on that? I’ve tried googling around but haven’t found any other information on that topic

    Reply

    1. So that is a good question
      There was no doubt they were going to end it, but from what I can tell they are now keeping it now…that’s my best info

      Reply

  23. Hello,

    I’m running 6.4.0.4 on my FMC and FTD.
    When you say:
    Faster access control The Version 6.4 upgrade process enables egress optimization on eligible devices, which enhances access control performance. Cisco TAC strongly recommend you leave this feature enabled.

    Where exactly can I check if this is enabled? I couldn’t find that option on the GUI. Maybe I’m missing something.
    I upgraded both from 6.2.3.x to 6.4.x

    Thanks.

    Reply

    1. His Hector, it is enabled bu default and is a CLI command:

      To enable egress optimization, use the asp inspect-dp egress-optimization command. To disable egress optimization, use the no form of this command.
      Egress optimization is a performance feature targeted for selected IPS traffic. The feature is enabled by default on all FTD platforms.

      We strongly recommend you leave this feature enabled. Disable it only if advised to do so by Cisco TAC.
      asp inspect-dp egress-optimization

      no asp inspect-dp egress-optimization

      Reply

  24. Dear 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 *