Putting a Firewall in Your Catalyst Switches

Cisco has produced a containerized version of the ASA firewall code, suitable for running in Catalyst 9K switches. It is something to factor into your design thinking.

This blog is intended to:

Increase awareness of this product as a design option
Discuss its apparent pros and cons

See also my prior blogs about Elisity (link in the Links section below). The products serve different market needs. Elisity is a leaner Zero Trust Identity-focused product. Cisco ASAc is a full-featured virtual firewall. At the time of this writing, Juniper also had an announcement impacting this space, which I intend to blog about.

ASAc Purpose and Basic Use Case(s)

As we add segmentation to campus networks, we can encounter an efficiency problem around securing inter-segment (inter-VRF) flows. This is a topic I’ve been mulling over for a while. There appear to be several answers, each with pros and cons.

ASAc adds one more option.

The challenge is where and how to put firewall services in a network. (Plus, the usual: what are your requirements, what do you NEED to do?)

If the network in question is a single site or even a set of regional sites, then backhauling the traffic to a centralized firewall (pair) for routing between VRFs with security services is technically feasible: latency will likely not be a real problem. The amount of aggregated traffic is a consideration but not a problem unless you’re moving a LOT of data: 100 Gbps switches aren’t that costly. However, firewall capacity at the aggregated traffic levels could be a significant cost factor.

This approach can be scaled to geographically distributed sites or regions by replication. More firewalls but still manageable and affordable. (YMMV: “Your Mileage Might Vary”)

Central firewalling per site or region also lets you readily secure flows to the cloud (assuming the firewall is placed between the site/region and the WAN cloud access). That’s where backhauling starts becoming a relevant consideration, if you want traffic going directly to the cloud rather than via central or regional firewalls.

Tunnels with some SD-WAN and SASE devices compound the complexity (and possibly the latency penalties of tunnels forcing indirect traffic paths).

What are the alternatives?

If scaling or avoiding backhauling are your challenges, then distributing and localizing the traffic filtering is worth considering.

This is a strong motivating factor for using agent-based security. If the security workload is distributed to end hosts and even servers running agents, then the workload becomes distributed, and in the worst case, may require throwing more CPU at it in some servers.

It’s a challenge to similarly distribute the workload with actual firewalls due to cost, physical placement issues, and the need to manage larger numbers of them. Distributing them into a Layer 2 or VXLAN campus fabric could also be painful.

But it might be “necessary.” The Cisco Service Insertion blog (see the link below) notes that IOT/OT devices have their security challenges. So (my addition), while end-system security agents might work for other devices, they may not be an option for IOT/OT. Or, if you prefer a more traditional (non-agent) approach, you need a design option that aligns with that.

Furthermore, stateful inspection may be part of your requirements. If you’re using Cisco switches with or without SDA/DNAC, they do enforcement in hardware, but I don’t think it is stateful. It is two-way filtering, but that’s not the same thing.

That’s where the ASAc might come in. You could deploy it in switches in the IOT/OT to campus network path, and distribute the stateful firewalling while not having to deploy a bunch of small physical firewalls. (Noting again that switch ACLs / SGACLs are not stateful.)

Note that ASAc contains the full set of ASA firewall code features. The means it opens up the possibility of other services, such as NAT, double NAT, encryption and VPN tunnels.

Cisco also notes rack space, power, cooling as other reasons using the ASAc might be preferable to a bunch of small physical firewalls.

They didn’t say “edge” (e.g. in-store edge) but I will. Less gear, perhaps a quarter or half rack in a smaller box?

The ASAc could also be used to encrypt some or all traffic flows. (For scaling reasons, “some” might be a better fit?) In particular, secure remote management!

ASAc also provides VPN services, include the ability to use AnyConnect to connect TO it (and potentially from the IOT devices behind it).

Pros/Cons

The above presented (or tried to present) the sales / use case for ASAc. You might run your VRF/VLAN segments in an IOT/OT switched branch into a Cat9K campus switch running ASAc, and control traffic out of the IOT world or between IOT segments there.

The main “Con” negative considerations that I see in this at the moment are:

Managing deployment, upgrades, and configuration of the ASAc containers. DNAC is recommended for doing so at large scale. CDO handles the security policy side, providing separate “ownership” (or control) into network (physical device) versus security (ACL rules, etc.) roles.
How much throughput can the ASAc sustain?

The latter matters since a Cat9K switch can likely move a LOT more data than the ASAc can handle. On the other hand, IOT/OT traffic may be much lower in volume and may be the only traffic you need to isolate/filter. So as usual in networking, “it depends.”

If you want to speculate, note that the virtual ASA (ASAv) has been available for a while, and the ASAc is likely a containerized version of that virtual machine, apparently consolidating SKUs for use in both server hardware and on switches.

Hence the ASAv link below might be applicable to some degree, at least until more ASAc-specific info is available. Talking to your Cisco or consultant team is also a good idea if you are considering ASAc for your use case.

In particular, the vCPU and memory information for cloud deployed ASAv might give a rough idea of the performance ASAc could provide. If ASAc gets 2-4 vCPU and 4-8 GB of RAM out of the switch, then that appears to equate to under 1 Gbps of throughput. Caveat: we’re definitelly in SWAG (stupid wild-a$$d guess) territory here! The comments on the first link below say 150-250 Mbps of IMIX traffic, up to 100K sessions/connections. In a Cisco partner presentation I saw the numbers 200-350 MB IMIX. (Is that capital B as in bytes?). My understanding is that the number does NOT include VPN and other encryption, which Cisco may still be testing – and which might further limit throughput.

Conclusion

ASAc is another tool in the design toolbox. Throughput is a major design consideration.

It may be helpful in keeping traffic flows aligned with physical topology, and securely segmenting IOT/OT traffic from the user side of campus/building networks.

ASAc Purpose and Basic Use Case(s)

Pros/Cons

Conclusion

Links

Related Topics