Firewall insertion with ACI

Hey there,

So this is probably my last post of the year, it has been a fun ride! So far I have been able to keep the goal “no post without code” (excluding the news updates), let’s see if I can keep it up next year.

But let’s turn to our matter of the day. Have you ever configured L4-L7 Service Insertion with service graphs in ACI? It is all about doing two tasks, where one of them is optional:

  1. Bring a L4-L7 device (like a firewall or a load balancer) into the data path
  2. Put some configuration on that L4-L7 device (optional)

By the way, step 2 has become optional since the latest ACI release 1.2 with what we call “unmanaged service graphs” (you do the L4-L7 device configuration outside APIC).

Obviously, you still can insert firewalls and load balancers the same way we always have, using VLAN/subnet/VRF stitching. So why going over the hassle of doing this service insertion thing, specially when it is not the easiest thing to configure in ACI?

First, as usual, let’s define some focus for our question. I will concentrate on the Cisco ASA. Other firewalls are supported for ACI service insertion as well (Palo Alto, Fortinet, Checkpoint), but the ASA’s device package has the best capabilities.

I decided to test a cluster of physical firewalls in routed mode, and got the help of two colleagues, since I am not that expert in firewalling: Stefan Dürnberger and Goran Saradzic. BTW, they will be presenting in CiscoLive, do not miss their sessions on DC Security if you happen to be in Berlin next February.

So What were our findings? I have created a series of videos (so far 3, more might come) with the main benefits (in my opinion)

One API for the whole network, quick insertion/removal, self-service

Having the possibility of orchestrate from a single place the full L2-L7 network. It is not only having a REST API, but the helper tools as well that make that API usable (as opposed of just having a 400-page API reference guide). Think API inspector, Python/Ruby SDKs, Arya, Save As / Post GUI operations, etc.

For example, you could easily build a self-service portal with which customers can decide whether using the embedded ACI security (up to L4), or including some additional L4-L7 security coming from the ASA (and SourceFire).

You can see more details here (7:55):

Easier troubleshooting

The next question was: if the network is aware of the services inserted, it should provide some context in troubleshooting? This is why we explored what the Troubleshooting Wizard looks like, when there are firewalls inserted over Service Graphs.

As you can see here, ACI can give relevant information (such as counters from the source to the firewall, and from the firewall to the destination).

I used the chance as well to try the relatively new “SPAN to APIC” function. I would have killed for having that one in my days as network admin, for not having to travel to the DC every time I needed to capture traffic.

Ruleset management

And finally, how do we address the constant pain of too complex firewall rulesets? Multiple answers on that one:

  • Since ACI is like a distributed L4 packet filter, you can configure “permit tcp any any eq xxx” kind of rules in your firewall that take care about TCP normalization or application-specific firewalling. ACI will do the rest, and you don’t need to modify the ruleset every time servers come and go
  • But wait, there is more. Some customers like to have in their firewalls the full policy, no “any to any”. You can use object groups that ACI will update automatically. How cool is that? You have IP address information which is always up to date, but you don’t need to maintain it.
  • And lastly, what about the list of protocols to be allowed? APIs come to the rescue here as well. Why not “offloading” that task to our own customers, giving them a self-service portal to configure them? This is what we did in this demonstration. Again, the enabler is not only ACI’s REST API, but all the helper tools around it (and more specifically, the API inspector and Save As functions).

Have a look (6:46):

And as usual, here all the code that I have used for these demos, plus the tenant configuration, plus the firewall configs: https://github.com/erjosito/sirius

What do you think about service insertion in ACI? Are you happy with VLAN/subnet/VRF stitching? Would you rather go for managed or unmanaged service insertion with ACI? Were these demos helpful? Have you already watched The Force Awakens? (awesome!)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: