I'm migrating a client away from legacy FWSMs running release 4.1, to new ASA-5585s. The current design involves a pair of legacy 6500's (not VSS) at their two DCs. each running separate FWSM HA's. The two DCs are connected via a 20gb dark fibre and a 10gb dark fibre. The 6500's at each site are not paired locally but rather DC1-6500-01 is paired from DC2-6500-02, and DC1-6500-02 is paired with DC2-6500-01. The primary 20gb is terminated between DC-6500-01 and DC2-6500-02, and the 10gb is terminated between DC1-6500-02 and DC2-6500-02. So as you can see, the 6500 pairs are connected in a ring topology, with transit 6500 networks existing between pairs.
I was considering the 8.4 release as would expect it to be less buggy, but am interested in the experiences of others.
The migration approach is that the ASA-5585s will span two DC's in a single HA Pair, but will connect to local 6500's, not a direct connections via dark fibre. They will also operate in multi context mode, in Active / Active. The DC1 FWSM firewall pair will have their active gateway on the DC1 ASA-5585, and the DC2 will be configured as standby on that context. And the DC2 FWSM firewall pair will have their active gateway on the DC2 ASA-5585, with DC1 being configured as standby on this ASA.
I'm developing the migration approach with the client as we cannot do this in a big bang due to it being a multi tenant environment. Has anybody been involved in similar migrations, and can you advise of the issues you encountered ? Or are you aware of design guides that will offer insights into our design ? I really just want to reach out into the wider community and hopefully be made aware of known problems.
Think I am too tired to picture the whole setup you have currently with the FWSM and how the ASAs will be placed in the network.
We do still have 3 FWSMs running in our environment (1 Multicontext A/S pair and 1 single FWSM) and also 4x ASA5585-X SSP20 units which are the devices that replace the FWSMs. So far I have migrated a single FWSM with around 100 Security Context and after that the migration hit a problem mainly due to normal day to day work taking time away from the migration.
As I work at a ISP, we use the virtualized ASA firewalls to host customer firewalls. We use separate hardware to provide the users with VPN services. For example ASR routers handle L2L VPNs while ASAs handle VPN Client connections.
I can't really remember that I would have had any major problems with the migration work so far.
Naturally in your case too you will have to make sure to get used to the new NAT configuration format that was introduced in the ASA 8.3 software. The FWSM dont use/support this format and its newerst software levels compare to the ASAs 8.2 software level in configuration format. This will essentially mean that you will have to migrate all the existing NAT configurations to the new format.
Since the NAT configuration format and the NAT operation in itself changed, you will also be migrating any ACLs that use currently NATed IP addresses in them. After the NAT format change you will always reference the real/local IP address of the host/network rather than the NAT IP address. This is because of the changed order in which NAT and ACL are processed.
In my migration I was essentially able to create a complete firewall configuration in the ASA Security Contexts and handle the actual migration/switch between devices simply by changing routing and moving IP addresses to different interfaces. But what you have to do in your situation depends on how you have currently setup the connectivity between the Security Contexts and the actual networks behind them.
We migrated to the 8.4(x) software levels and so far we havent really had that many problems. A couple of bugs but those were sorted pretty fast.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...