Although not immediately obvious, the FirePOWER Series 3 devices can do a form of IPS on a stick. This means that the capability described here should be available to the current appliance versions of the FirePOWER managed devices. The premise involves connecting broadcast domains (VLANs) to bring the managed device inline between the initiator and responder of a flow. Configuration is fairly straightforward but does have some caveats.
- Even though only a single port is required, a virtual switch must be configured (this cannot just be an inline pair)
- BPDUs being bridged between VLANs are detected and will render the switchport(s) in an inconsistent state
- The FirePOWER physical interface will not activate until it is also bound to a Virtual Switch
The diagram shows two devices in the same VLAN (we will assume /24 for the configuration). The device on the top is in VLAN 100. The FirePOWER managed device bridges VLAN 100 to VLAN 101 and allows the two devices to communicate directly with one another. The connection to the FirePOWER device is a single 802.1q trunk.
Frames arriving on VLAN 100 will be processed and egress with a VLAN tag of 101. This configuration is similar to a Router on a Stick but this example processes frames at layer 2. This methodology has been used to shoehorn an IPS between endpoints for quite a while.
R1(config)#interface gig 0/0 R1(config-if)#ip address 10.100.100.1 255.255.255.0 R1(config-if)#end R1#end
R2(config)#interface gig 0/0 R2(config-if)#ip address 10.100.100.250 255.255.255.0 R2(config-if)#end R2#end
//To R1 SWITCH(config)#interface gig 1/0/1 SWITCH(config-if)#switchport mode access SWITCH(config-if)#switchport access vlan 100 //To R2 SWITCH(config-if)#interface gig 1/0/2 SWITCH(config-if)#switchport mode access SWITCH(config-if)#switchport access vlan 101 //To SourceFIRE Managed Device SWITCH(config-if)#interface gig 1/0/48 SWITCH(config-if)#switchport trunk encapsulation dot1q SWITCH(config-if)#switchport mode trunk SWITCH(config-if)#spanning-tree portfast trunk
In the FireSIGHT Management Console, choose Devices, Device Management and Select the Managed Device.
On the interface tab, select the pencil to edit an un-configured interface.
In the subsequent dialog box, select Switched and specify a virtual switch. This seems to be required to activate the physical interface. This attachment is only relevant to untagged frames so it might make sense to create a virtual switch solely for this purpose. Save the configuration to exit.
Note: It may be necessary to Apply Changes on the device management screen before proceeding to the next step
To create the logical VLAN interfaces, select Add -> Logical Interface.
In the dialog box, select the physical interface that was configured in the previous step. Identify the appropriate VLAN (100 in our example) and attach it to a virtual switch. Notice that I created a second virtual switch specifically for attaching my VLAN subinterfaces.
Repeat this step for a second subinterface using VLAN 101. All items should remain the same as the previous step (with the exception of the VLAN Tag).
Next select the Virtual Switches tab.
It is necessary to edit the switch that connects the two VLANs. Select the pencil for the appropriate Virtual Switch, then choose the advanced tab in the resulting window. Select the option to Drop BPDU’s. This will keep the switch from detecting BPDUs on the wrong VLAN (as a result of them being bridged) and placing the port in an inconsistent state.
After saving and applying all the changes, the configuration should be complete and working. To test, it is necessary to send traffic from a device on VLAN 100 to a device on VLAN 102 (or vice versa).
R1#ping 10.100.100.250 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.100.100.250, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/4/9 ms
This article demonstrates a workable method for doing IPS on a stick with the SourceFIRE solution. It is worth noting that I would typically prefer to build a solution that uses inline pairs. Inline pairs, depending on the type of interfaces used, may offer flexibility in the form of hardware bypass and don’t require mac learning. They simply function as a bump in the wire.
The requirement to block BPDUs when bridging VLANs causes me some concern. Basically this isolates the network into two spanning-tree domains. It is imperative that these two networks not be connected at any other point. So building a redundant solution around this increases risk of a catastrophic loop and would require careful consideration and planning.
I’d love to hear from you, so share your thoughts by commenting below.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.