Hey, everyone!  Welcome to a quick blog about enhancing your Cisco ACI security by integrating Fortinet Firewalls through L4-L7 service insertion.  

First, let's take a look at the topology we want to setup (pictured below, who doesn't like pictures?).  Underneath a single tenant and single VRF, we have two separate bridge domains called LAB_DATA and FortiTest.  LAB_DATA has three EPGs, and FortiTest has only one.  Underneath LAB_DATA's bridge domain we have two subnets configured.

So what do we want to test?  As seen in the diagram above, first we wanted to test traditional cross subnet boundary firewalling from FortiTestVM2 10.64.20.100 to FortiTestVM1 10.64.10.101.  Second, we wanted to test the same functionality, but within the same Bridge Domain between FortiTestVM4 10.64.30.100 to FortiTestVM1 10.64.10.101.  Lastly, we wanted to execute on the micro-segmentation strategy and within a single Bridge Domain and a single subnet talk from FortiTestVM3 10.64.10.100 to FortiTestVM1 10.64.10.101.  What now?  Let's get after it!

We have a FortiGate 1500D firewall, and the first thing we need to do is create a new admin user that we're going to use for Cisco's ACI integration.  We also have to create a port-channel (manually) with a name we reference later on for the L4-L7 device. (pictured later)

Next, we log into ACI APICs and install the device package.  This one is the Fortinet device package for APIC 1.3, but was tested valid and working on 2.2(1n), as well as an upgrade we did to 2.2(1o).

Here we setup the L4-L7 Device.  If you haven't done it before, there are a few things to know.  You need to determine whether you are going to utilize "GoThrough" or "GoTo" mode for the function, as well as, whether or not you're using a context aware device.  An older, but a good quick reference to this from ACI 1.2 is here.  Notice in the top right section, we had to input the "interfaces" and while we did select the VPC itself, we had to give it the name of "ACI" manually, which is the component we spoke about earlier and will show a picture of in just a moment.  Likewise, you then have to setup the consumer and provider interfaces in the bottom right which is going to always be the 'Name' (Device1 in this case) and the 'Interface' you setup (ACI in this case).  Since we're doing a single device in one-armed mode, they're using the same interface.

Upon doing so, the APIC pushes down a new VDOM (9847 in this case) and also chooses a VLAN from the "dynamic VLAN pool" in ACI for the physical connection to the FortiGate firewall.  We have it configured for a range of 5 VLANs, and it chose 'Vlan 5' here and created ACI_v5.  Notice here the "ACI" physical connection that we setup in the beginning!

Next, we created our service graph template in ACI for the consumer to provider context through the FortiGate firewall.  Visual representation below.

Next, you have to deploy the service graph template in ACI which associates the consumer and provider EPGs through a contract.  After deployment auto population of EPG membership nodes in the FortiGate appear as objects (left) and you can see a validation of deployed services in ACI (right).

The policies for this test were an "any" on the FortiGate and all "denies" were handled by the contract provide/consume and filter allowance within ACI.  There is always a debate on how this should be handled.  I would prefer to drop all non-critical packets at the fabric layer and save any compute/overhead from hitting my firewall.  Now, I wouldn't necessarily recommend everyone deploy their firewalls with just "any any" everywhere, but you could!  What would be most beneficial is to keep your firewall rules the way you have them today and amend your deep packet inspections, URL filtering, DLP, et cetera in the rules.

Here we see the rules we expect to see, one subnet to another through a firewall, but this isn't anything new is it?

This is what we've worked for until now!  10.64.10.101 talking to 10.64.10.100 within the same subnet (10.64.10.0/24) part of the same VRF, same Bridge Domain, but separate EPGs talking through a stateful firewall!

So, what is the one thing we didn't discuss?  How can a firewall write the rule for you based on the EPG/Contract association in ACI?  That would be awesome!  Unfortunately, this isn't a Fortinet problem; it is an integration problem with all firewall integrations at this time.  It is risky business to have your firewall policies written and maintained by an external entity.  I can see the security concerns here and why there is a separation. Through software defined networking we're looking to make the network intelligent and communicate together, which it is!  However, we're not fully to the state I think we will be within another year.

In conclusion, L4-L7 integration between Fortinet and Cisco's ACI worked splendidly.  While some see ACI as the "end all" for security in the data center, there are things that it doesn't do natively that other devices do well.  If you're looking to make a move in the data center and upgrade your infrastructure, consider how Cisco ACI can integrate with your current or future solutions today by reaching out to info@withrove.com to set up a discussion with one of our ROVE experts.

 

Paul Campbell

ROVE | Practice Lead, Software Defined Architectures

@paulmc3

1 Comment

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out