A Firepower Inline Set is essentially a bump in the wire and works very similar to an inline IPS. For all practical purposes, this is a layer 1 technology and does not require any routing or VLAN translations. Prior to Firepower you had two options:
Routed-Mode: A Routed-Mode firewall works just like a router. If you were trying to protect traffic between two segments, you would have to redo routing and potentially redo your entire IP scheme. Ugh.
Transparent-Mode: The other option was an attempt to mitigate some downsides of the Routed-Mode option. In this case, the firewall acts as a switch and can be dumped off between segments. The issue here is this requires a VLAN translation. For example, traffic enters the firewall in VLAN 10 and leaves the firewall on VLAN 110. This is okay but does not scale very well. This is a ton of configuration if you have hundreds of VLANs. In addition, the firewall itself also requires an IP in each segment. Which is a nightmare if the segments are /30 networks.
Now we have a third option (inline set), and we can essentially put the firewall anywhere. Regardless of the underlying network transport.
Our customer has two buildings that are connected via a point-to-point link. They would like the ability to inspect and filter traffic inter-building. However, their network team is swamped, and they are unwilling to engage in this project, if routing/IP changes are required.
Our job is to insert a firewall between Site1-Core and Site2-Core.
The existing configuration is straightforward. The default gateway for the clients is the access-layer. There is a transit network between the access layer and the core on each side. Finally, there is a p2p link between the cores, and everyone runs OSPF in Area 0. There is full IP reachability between all segments on the network.
Note: The “clients” are just switches which we will use for testing.
Our marching orders are simple – Do not make any network changes! This task would be impossible without an inline-set. For example, we cannot do Transparent as the firewall will require an IP in the 10.0.50.0/30 network, but there is no IP available.
As a quick test, we will just ensure Site1-Client has learned all routes from Site 2, and can ping Site2-Client:
Site1-Client#show ip route 10.0.2.123
Routing entry for 10.0.2.0/24
Known via "ospf 1", distance 110, metric 50, type intra area
Last update from 10.0.1.1 on Ethernet0/0, 00:01:50 ago
Routing Descriptor Blocks:
* 10.0.1.1, from 184.108.40.206, 00:01:50 ago, via Ethernet0/0
Route metric is 50, traffic share count is 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.123, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Looks good to me.
Now we can place our firewall and begin the configuration process.
The first step is to get management rolling on the firewall. Obviously, we want to pre-configure our firewall before we start moving cables. This article assumes you know how to build the FTD/FMC and understand the registration process. For an inline-set, it does not make a difference if you configure the firewall in routed or transparent mode. Choose the best option based on other services the firewall will perform.
Configure the usual Next Generation features and functions.
Now we can configure the actual inline set using interfaces g0/0 and g0/1.
Enable and name each interface (that’s it, do nothing else):
Save the interface configuration.
Click on “Inline Sets”
Name your new set
Add the available interface pair to the “Selected Interface Pair” box.
Accept the warning
This is the reason we did not add a zone to our initial interface configuration. We will go back and do that now:
Click the Interfaces tab
Edit each interface and add a zone, if desired
That’s it! Save, deploy, and move the cables:
Step 4: Quick Test
Of course, this article only covered the infrastructure. It’s up to you how you secure your traffic now that you have full visibility and a host of security features.
How can CDA help you improve your network security?
Members of our team are Cisco Certified Internetwork Expert (CCIE) certified and can help at any stage of the process: proof of concept, design, architecture, implementation, testing, & issue resolution. Want to learn more?