Hi, II don't think there is direct configuration migration available in this scenario (not sure,I know there are tools available for ASA to FTD, but that  requires ASA 9.x software), but I've had a similar discussion on this subject before and just to share some of my thoughts on this. Since you do not plan on using the FTD image, but only the ASA image on the FirePower 2110 appliance, I suggest you look at this like any other ASA upgrade and focus on that perspective. The platform change will be the easier part of this migration. There are significant changes in configuration and default behaviour between ASA versions 8.2 and 8.3, and then there are again additional configurational changes in version 9.0 For reference take a look at both the two following resources: https://supportforums.cisco.com/t5/security-documents/asa-8-3-upgrade-what-you-need-to-know/ta-p/3127078 https://www.cisco.com/c/en/us/td/docs/security/asa/asa83/upgrading/migrating.html Note that the second one states "Due to additional configuration migration in Version 9.0 (see the 9.0 upgrade guide), we suggest that you upgrade to Version 8.4 first, and then to Version 9.0." And the ASA Upgrade Guide seconds this, stating that ASa version 8.2 and earlier should be upgraded to 8.4(6) and from there to any of the 9.x versions. ( https://www.cisco.com/c/en/us/td/docs/security/asa/upgrade/asa-upgrade/planning.html ) If you have a spare 5510, then you could load it with 7.2(4), and then go through the upgrade procedures. And once you get to 9.x, then you could copy most of the configuration over, interfaces and other platform-specific objects would need to be configured manually. (Note that there are different memory requirements for the 5510 in 8.3, so if you have a really old appliance you might not be able to upgrade.) There is (atleast) one caveat with this approach though. The ASA will try to migrate your configuration when you upgrade from 8.2 or earlier to 8.3/8.4, in my experience; depending on the complexity of your configuration this migration might not work as intended. So in my mind the solution to your challenge really depends on how complex, or not, the current configuration of this ASA 5510 appliance is. I know this doesn't directly answer your question but I hope it helps. ... View more

May I suggest that you would take a look at some of the Cisco Live On-Demand presentations on this subjects that are available. That might give you a head-start. For example, BRKRST-2619 from Las Vegas 2017 topic is "IPv6 Deployment: Developing an IPv6 Address Plan and Deploying IPv6 " and can be viewed online. And there's a IPv6 addressing whitepaper available on cisco.com/go/cvd That being said, to answer some of your questions. The most common scenario is probably to use global (public) IPv6 address space internally, and I would recommend doing so and steer away from NAT. The security issues are similar as with IPv4, you have to make sure that unwanted inbound traffic is stopped at the perimeter firewalls. It may depend on the operating system and clients, but usually dual-stack systems will attempt to connect via IPv6 when both IPv6 and IPv4 are available. Some applications (browsers mainly) have implemented "Happy Eyeballs"(RFC8305) so if a connection via IPv6 is unsuccessful it will quickly fallback to IPv4 without the user experiencing timeouts or errors. I don't have the expertise to go deep into the DHCPv6 vs Stateless Autoconfiguration (SLAAC) topic right now. There are several things to consider there and one of them is that not all clients support DHCPv6. Take a look at the "Comparison_of_IPv6_support_in_operating_systems" wikipedia article for reference. ... View more

Regarding AnyConnect and RSA SecurID integration, yes that is possible and you can use either the SDI protocol or RADIUS between ASA & the SecurID AM. There are implementation guides availabe from RSA ( https://community.rsa.com/docs/DOC-62877 for example) and a number of posts on the Cisco community forums on the subject. This is usually pretty straightforward. I'm not sure if you can then run Microsoft PPTP to the TMG gateway within the AnyConnect VPN connection. However, considering additional packet overhead, complexity and I understand that the TMG is end of life, I would suggest that you would look at ways to redesign this remote-access scenario so you would not need multiple VPN solutions on top of each other. ... View more

Thanks for this clarification. EXSi 5.1 has been out for a while now, and it's not a promising scenario when the customer needs to upgrade his ACEs but is unable to upgrade the ANM. Do you have any info that you can share on when we might expect an OVA image that'll be installable on EXSi 5.1 ? Withbestregards, J'J ... View more

Since it's apparent that others are experiencing this error, and google only leads you here, it would be wonderful if there was a solution to this that could be posted here. @Ajay Kumar Here's the the relevant screenshot. In my case, I've already verified that the MD5 checksum is correct. ... View more

Hi, Asuming that crypto & routing are working correctly, if I remember correctly you need to specify a tunnel key ("tunnel key" command under interface tunnel configuration) when you are sourcing multiple GRE tunnels from the same source interface (Loopback0 in your example). So for each tunnel specify a different tunnel key (both ends need to match). Sent from Cisco Technical Support iPad App ... View more

Hi Judhajit, In regards to these features mentioned in the subject, can you tell me what corresponding IPv6 security features are available for a company that has access switches that mostly consist of 3560 and 3750, if any? Or do you know if any of these features (RA guard for example) is on the roadmap for these types of switches. ... View more

I know this may not be the answer you're looking for... But what about considering implementing IPv6 within your network? (dual-stack) When the computers have native IPv6 connectivity, they should always prefer using the native IPv6 connection rather than any of the tunneling mechanisms such as 6to4. Instead of looking at this as a "unmanaged" problem, look at this as "managed" connectivity service. So by enabling IPv6 within your network, you get two things done. 1) Your network steps into the future. 2) Your clients (managed and unmanaged) will have native connectivity to both IPv4 and IPv6 resources, just like you do with IPv4-only resources today, and then you don't have to worry too much about 6to4. ... View more