27 – Bis-Bis – Stateful Firewall devices and DCI challenges – Part 1 (cont)

Back to the recent comments on  what is “officially” supported or not ?

First of all, let’s review the different Firewall forwarding mode officially supported

ASA cluster  deployed inside a single data center:

Fig.1 Firewall forwarding mode within a single DC. Please note the firewall routed mode supported with the Layer 2 load balancing (LACP) Spanned Interface mode.

When configured in Routed mode (e.g. default gateway for the machines), the same ASA identifiers IP/MAC are distributed among all ASA members of the cluster. When the ASA cluster is stretched across different locations, the Layer 2 distribution mechanism facing the ASA devices is achieved locally using pair of switches (usually leveraged the a Multi-chassis EthernetChannel technique such as VSS or vPC).

Subsequently the same virtual MAC address (ASA vMAC) of the ASA cluster is duplicated on both sites and as the result it hits the upward switch from different interfaces.

 

 

 

 

 

 

 

 

 

 

Fig.2 ASA and duplicate vMAC address

Therefore when the ASA cluster runs the firewall routed mode with Spanned interface method, in a geographically stretched fashion, it breaks the Ethernet rules due to the duplicate MAC address, with risks of affecting the whole network operation. Consequently by default it is not supported as expressed in the release notes for the Inter-site section.

Fig.3 The routed mode is not supported with Spanned Interface mode for ASA cluster stretched across multiple locations.

The above requires a clarification. In this context, “NOT supported” means that no other design alternative allowing the firewall routed mode to be enabled in conjunction with Spanned interface mode has been tested by the Quality Assurance (QA) process.

However it doesn’t mean that there is no design workaround to address this requirement, and some additional network services may help to keep the ASA in Routed mode.

• The 1st option could be to filter the Virtual MAC address in the interface facing the DCI link.

This option may be desired if you need to use the ASA as the default gateway for the servers for example. However it must be enabled with caution, thus this option is definitely not recommended, except if you know exactly what you are doing.

The first drawback to keep in mind is that if the vMAC address is blocked, it results that the original ASA member cannot maintain the session stateful with a virtual machine  moving to the remote site. Consequently this option will be limited to “cold migration” using subnet extension (e.g. for cost containment or migration purposes).

The second concern is that to address any black hole scenarios, this option imposes as well the ingress traffic to be dynamically redirected to the new location as soon as the application of interest has migrated to (e.g. LISP mobility).

Fig.4 Statefull session is not supported with vMAC filtering

• A 2nd alternative more robust IMO is to isolate the layer 2 domain with a Router

With this option, the L2 domain used to distribute the traffic among the 2 local ASA devices is isolated from the data VLAN, hence the pair of switches facing the ASA members sees the vMAC only from the direct attached Firewalls. Only the data VLAN is stretched across the 2 locations (plus the CCL which is not represented in this diagram)

Fig.5 Router insertion to isolated the vMAC. ASA are configured in firewall routed mode with static routing.

However there are few disadvantages of using this design with the default gateway that resides between the application servers and the ASA clusters:

1. The ASA cannot be the default gateway of the servers due to the inserted first hop router.
2. The routing service on the ASA must be configured with static entries. Indeed, the dynamic routing is centralized to the master, hence routing adjacency on non-master site without a full stretched subnet will not succeed. On the other hand, if the subnet is stretched, we lose the ability to localize transit traffic to the local site.
3. It becomes challenging to secure the E-W traffic (e.g. Web-tier <=> App-tier <=> DB) with the same ASA cluster.

Note for the last bullet that IPS are usually more efficient (and mandatory) between application tiers than a classical firewall function However the ASA offers embedded IPS too, thus this comment I think may be important.

If theoretically the second alternative works as I described it, it is not yet officially supported, and it will require several tests with different scenarios that you may want to run to this validate this option for your environment.

Having said that, a new East-West insertion mode has been qualified and validated with the recent release 9.3(2), technically nothing new, it ‘s just that this one has been deeply tested. In this scenario the E-W traffic can nowbe secured via the same ASA cluster.

Fig.7 ASA in transparent mode. East-West traffic is secured using the ASA cluster.

When the ASA is configured in Firewall Transparent mode, the virtual MAC is not an issue anymore as the ASA members use a BVI address. The BVI address doesn’t appear throughout the data plane. Consequently there is no risk of duplicate MAC address. As the result, the outside router can act as a default gateway for all application servers of interest, allowing the E-W traffic (server to server communication) to be secured via the same ASA cluster. Keep in mind that it requires FHRP isolation to support hot live migration.

Additional details on E-W insertion design can be found in this release-notes 9.3(2)

I hope that post clarifies some statements within the official ASA document and alternative design.