VLAN Bridging with FirePOWER

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

FirePOWER Bridge VLANsThe 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 Configuration

R1(config)#interface gig 0/0
R1(config-if)#ip address

R2 Configuration

R2(config)#interface gig 0/0
R2(config-if)#ip address

Switch Configuration

//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

 SourceFIRE Configuration

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).

Final Testing


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, 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.

More Information

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.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

13 Responses to VLAN Bridging with FirePOWER

  1. Chris says:

    Paul, thank you for the excellent tutorial. I’m new to Sourcefire and am having problems getting my pings to through from one VLAN to the other following the example above in my lab. Would you mind sharing any policies that were used to get this traffic through the Sourefire appliance? I wasn’t sure if it was implied that a “permit ip any any” policy was used in this example. Thank you in advance!

    • In the article I focused on bridging two VLANs. I cannot recall the policy contents but it was likely a permit-all policy. I would certainly expect inline policies to function normally once the bridging configuration brings the traffic inline. Unfortunately, I don’t have access to gear to rebuild the configuration.

      • Chris says:

        Paul, thank you for your reply. The problem in my config was the lack of routes (completely overlooked that). As soon as I put in the necessary routes, pings went through just fine. Again, I appreciate the tutorial.

  2. Yashar says:

    Thanks for the detailed explanation Paul. Two questions:

    – Can you also please elaborate on how high-availability can be incorporated into this design ? Suppose the FirePOWER device goes down, then how VLAN100 is bridged to VLAN101?

    – Can this solution be implemented using two physical interfaces? In other words, can I bridge S1P1.100 and S1P2.101?

    • Regarding the first question, there would be no HA within the FirePOWER solution. You would have to provide HA around the solution. So if this is a midpoint between two L3 hops, you could use a secondary path (potentially through another appliance) with a higher IGP cost. There is a hardware bypass option that basically can do a physical pass through. However if the VLANs need to be manipulated as they pass through, there is no way that could happen in the event of a failure.

      I see no reason why this couldn’t be done between two physical interfaces. I don’t have access to confirm this at the moment, but I fully expect that to work. Another thought if you can use two physical interfaces would be to get to the point that the VLANs are the same. This might be possible if you are bridging between two VDC’s in a Nexus or are going between physically separate components. This would be something that might lend itself to hardware bypass (if fail-open is a desire, in some cases it isn’t).

      Thanks for the questions, those are some good discussion points.

  3. modalita says:

    I have a question that is inline, if you will, with the IPS on a Stick above. I am attempting to leverage the Sourcefire SSL-8200 (Bluecoat made) using VLAN bridging to force traffic through the IPS for specific VLANs. Let me explain my issue.

    The SSL8200 connects to a Cisco 6500 Switch. The 8200 has two interfaces (call them Net-1 and Net-2) connected to the 6500 and two interfaces that connect the IPS to the 8200. The 8200 is doing VLAN bridging so VLAN 100, 101, 102 exist on Net-1. Net-1 plugs into a trunk port on the 6500. Net-2 bridges VLANS 200, 201, 202 and is plugged into another trunk port. So basically I have a loop from one port on the 6500 to another port with the IPS analyzing in the middle. The solution currently passes BPDUs. I did a tcpdump and watched the STP/BPDU packet flow.

    Let me step back a bit. I also run an older Cisco IPS on a stick which is also doing VLAN bridging for these same VLANs. The packet capture I did on the Cisco IPS did not seem to show the passing of STP packets.

    I’m replacing the Cisco IPS with the Sourcefire SSL/ IPS solution. When the network engineer activated the ports for my new SSL/IPS solution he did not remove the VLANs from the existing Cisco IPS on a stick port on the 6500 which caused some very unstable communications for all devices and VLANs connected to the 6500 besides the ones I was bridging, and it did so in a very insidious way that was not or did not seem to be easily diagnosed. Anyway, that was resolved.

    However, this environment has two 6500 switches for redundancy including trunk link between the two for all the VLANs, interconnected links for state, etc…only one is active and the other sits idly waiting. I installed my secondary SSL/IPS system – configured identically – to two trunk ports on the 6500 configured identically to those on the primary 6500 and the VLANs were removed from the trunk ports of the 6500 for the secondary Cisco IPS on a stick (learned our lesson), however, within five minutes of enabling the secondary SSL/IPS system, communications were failing, systems unavailable, the SSL8200 no longer processed packets, etc.


    I’m arguing that the 6500 ports the 8200 connect to should not participate in STP. I believe we are running PVSTP+ and thus with only one SSL/IPS in place the BPDUs seen on the two switch ports on the primary 6500 were not alarming and did not cause spanning tree issues because one saw BPDUs tagged 1xx and the other tagged 2xx.

    But when the secondary SSL/IPS was enabled and passing BPDUs, I think spanning tree started going nuts because I assume the BPDUs seen on the same trunk port for each 6500 indicated a loop for VLAN 1xx or VLAN 2xx for the other corresponding pair of 6500 switch ports. The behavior was virtually identical to what we saw previously when the VLANs had not been removed from the trunk ports for the Cisco IPS on a stick and I enabled the new Sourcefire SSL/IPS solution on the primary 6500.

    The SSL/IPS solution cannot create a true switching loop because it is like a single wire connecting two switch ports. Yet to spanning tree it could appear that way if allowed to pass BPDUs. I want to know how the trunk ports on the 6500 should be configured from an STP perspective to work with the VLAN bridging solution using the SSL8200. Any advice would be greatly appreciated.

    • That’s a lot to digest> what is odd to me is that it quit working in roughly five minutes. I’m guessing that would align with the CAM table timing out and not relearning something it should be learning. There could be some relationship with spanning-tree, but I would’ve expected proper learning if the frames were properly flowing. I would be curious if there was high or low utilization when the issue started occurring the last time.

      The bottom line is you would probably want to test this configuration in a situation where you know nothing should be L2 blocking. Then you need to introduce the redundancy and confirm you know where spanning-tree root is in both a normal and a failed mode.

      To be 100% honest, I have not experimented with PVSTP+ and these devices and I’m not sure how the work in either scenario. I would probably be concerned with doing a port-level bpdu filter.

      I wish I had a personal experience I could share on this. You might see if your partner can share some insight or if you local Cisco SE may personally have some information or can pull in a security Expert. This is definitely something I want to experiment when I have a little time and access to the proper gear.

  4. modalitas says:

    Thank you Paul. I’m a little disappointed with Cisco/Sourcefire because their tech support has not been very helpful in a number of ways from the configuration of the VLANs on the SSL8200 to why when I run a packet capture on the 8200 it stops processing packets. I got a Cisco switching engineer to work with me and one of our network engineers looking at switch and STP configuration but without possible problem resolution. We have to test in production and it does bring communications virtually down but of course the Cisco engineer wants/needs to diagnose when the problem is happening. I’m tired and frustrated. It wasn’t supposed to be this difficult. It’s probably not the BPDUs like I was hoping. Sometimes I just want an answer now. Anyway, thanks for chiming in and when…we find the answer or one working answer I’ll post it.

    • Let me preface a disclaimer with what I’m about to tell you. This is my personal site and I don’t make any commitments for Cisco here. With that being said, I know there are some good SourceFIRE support resources in TAC. I cannot speak to every one of them, nor can I speak to your particular experience or experiences. As a Smartnet customer, you should have the right to call the TAC and request to speak to a duty manager. The duty manager should be able to review the case and get it moving forward with whatever resources he/she deems necessary. I would also reach out to the local partner and/or Cisco team. These are the customer situations that they usually want to know about and might be able to provide some additional direction.

      You mentioned a second issue in that running a packet capture causes it to stop processing packets. Once you get the VLAN forwarding to work in your environment, I would go through and make sure those secondary issues are addressed by TAC (may require a separate case).

      • modalita says:

        Thank you Paul. I have made contact with our local Cisco engineer and he’s coming in this Friday. And I may do as you suggest and talk to the duty manager for Cisco Sourcefire support. I very much appreciate your input.

  5. modalitas says:

    Turns out the Bluecoat/Sourcefire SSL appliance software has a bug/problem in regards to one or two issues around PVST and BPDUs. I may not have the terminology correct. First I was told SNAP encapsulated BPDUs , which are used with Per VLAN Spanning Tree, were being blocked; but that may not be quite correct as later it came out that the SSL appliance could not update the BPDU VLAN ID (PVID) for PVST on trunks, and therefore the BPDU coming in to the SSL device for VLAN 100 on trunk port interface 1 and leaving on interface 2 destined for VLAN 200 retained the VLAN ID (PVID) of 100 and thus the Cisco switch dropped it. The inability of the SSL appliance to properly update the PVID of the BPDU for PVST on trunks stopped STP from working correctly in our redundant switch architecture in which we still uses STP to determine the active and passive switch (blocked paths). Cisco provided more interface cards for the SSL and IPS systems so we could run each VLAN on a separate physical interface – eliminate trunking and VLAN bridging. Messy but it works. I just wanted to pass on the result and not leave the post hanging.

  6. wageh says:

    Hello Paul, Thank you for this well written article it really helps!! However I am working on a tied environment where I have only one SFP 3D83xx with 2xASA5585-X firewalls in clustering with north and south security contexts in transparent mode, The SFP is sandwiched between both firewall contexts, where it is connected only to both firewall via 2x10Gig spanned port-channel on each firewall, as follow.

    n9ksL2 – spanned cluster trunk- to – ASA_NORTH_Context – spanned port-channel->SFP in a Virtual switch mode -> ASA_Soruth_Context, We basically configured the SFP to bridge VLANs between both contexts ( paring VLANs), the traffic is working fine as expected, however we tested Fail-open it didn’t work, we do have a SFP 10Gig netmod that support hardware bypass, so I wonder is this a supported design for fail open, and if not, is there any other way to tweak the SFP virtual switch to support fail open.

    i really appreciate your feedback.

Comments are closed.