The Cisco Firewall Services Module (FWSM) is a module that installs into the a Catalyst 6500 switch, and connects via 6 x 1 gigabit ethernet channel bonded into a single Etherchannel on the backplane. Delivering up to 6 gigabits per second at less than 300W in a C6500 chassis it has got some potential as a high performance firewall.

When used in multi-context mode to provide multiple logical firewalls there are some specific considerations.

Virtualisation

The Cisco FWSM uses what appears to be a type-2 hypervisor to provide multiple logical firewalls from a single physical unit (very similar to that method used Cisco ASA/PIX platforms). I model that function along these lines when showing the System Context and the Admin context.

Packet Classification

Each packet that enters the FWSM in Routed Mode must be classified and then allocated to a context. Each packet is sent to a context. In the event that the packet cannot be classified, it will send the packet to the Admin context. It is very important to understand this when troubleshooting.

The FWSM uses a single GLOBAL MAC ADDRESS across all interfaces. You cannot change it.

This is not a problem unless the multiple contexts want to share the same VLAN interface. If two virtual contexts share the same VLAN (regardless of IP address), then the FWSM OS must use some other
criteria to determine which context is the destination for the packets because all interfaces have the same MAC address

From the manual:

Routed Mode Only
The FWSM lets you share an interface between contexts. However, packet classification requirements might make sharing interfaces impractical. Because the classifier relies on active NAT sessions to classify the destination addresses to a context, the classifier is limited by how you can configure NAT. If you do not want to perform NAT, you must use unique interfaces.

Note: The FWSM does not support sharing the outside interface of one context with the inside interface of another context (known as cascading contexts). Traffic that is outbound from one context (from a higher to a lower security interface) can only enter another context as inbound traffic (lower to higher security); it cannot be outbound for both contexts, or inbound for both contexts.

Lets start with something that works:

Single Context per VLAN

When the virtual context contains a single FWSM interface in a given VLAN,
the FWSM classifier will classify all packets into that context. This is
illustrated in the figure below.

In this design we have two VLANs, one front and one back, and only one VLAN with an SVI configured with an IP address.

Think carefully about your VLAN interfaces on your Supervisor

A classic mistake¹ is to think you can configure two interface on your Supervisor and then add VLANs to the FWSM. Of course, these will be in the same routing process and the packets will never reach the FWSM.

Use VRF-lite or MPLS to configure around this problem, since the routing tables will be separate in each VRF the interfaces do not exist is a single routing space and would look something like this. Herewith is the reason why Security Engineers need to have some MPLS skills.

It would also be possible to use Policy Based Routing but this nearly always ends in tears.

Multiple Contexts per VLAN

In the scenario in which multiple contexts have interfaces within the
same VLAN, the classifier will continue to intercept packets and extract the destination IP address. The classifier can use NAT statements to establish to which context to send the packets to. Thus for a number of firewalls that share a VLAN with public IP addresses, perform NAT on all traffic to RFC1918 addresses you can have many contexts on a single VLAN, the but the private VLANs MUST be separate.

Thus the following will work correctly:

The scenarios described above are valid and correct design solutions. The following describes invalid scenarios that must be avoided. They all
relate to scenarios where multiple contexts have interfaces within a
single VLAN.

The classifier does not use the routing for classification. Even though
a context includes a static route that points to an external router as
the next hop to a subnet, and a different context includes a static
command for the same subnet, then the classifier uses the static command
to classify packets destined for that subnet and ignores the static
route.

The routing table is ignored in every case. The figure below illustrates this scenario.

As mentioned earlier, the FWSM classifier can use a mapped address in an
active dynamic address translation (set by the global command) to permit
traffic. This can results in working one way flows, which may be desirable, whereby egress traffic from the DMZ is forwarded to the FWSM the traffic is placed in the translation table, and return packets that are part of the flow will return through this flow.

Static NAT Hack

However, a new inbound flow will never be classified and will be dumped
to the Admin context. In this case a static NAT is required.

It is possible to solve this problem using a static NAT added to configuration, but this is not a particularly scalable solution, and would be hard to maintain since you would not normally configure NAT for every access rule unless you actually wanted to perform address translation for every single IP address. This option does not scale.

The Teeth Kicker Here

One of the things that makes troubleshooting this problem quite difficult, is that existing flows through the firewall – that is, TCP sessions that have already been created and are active through the firewall can still work, sometimes. Of course, the occasional or intermittent fault is very hard to detect.

Hard Lessons – Shared

I had a few hard lessons on configuring the Cisco FWSM before I fully understood how the packet classifier worked. You should take some time to learn this before you start designing with FWSM. The big problem is that if you create a new context, and mistakenly attach it to a VLAN that already has a firewall context from the same physical unit, then packets will be dropped for BOTH CONTEXTS

It might be worth noting that the Juniper NetScreen OS has similar issues but, possibly, handles it better than the FWSM (if only just).

Footnote: Cisco PIX / ASA virtualization

Most of the information above applies to Cisco ASA/PIX when used in Multiple Context Mode, but the option of building cascading contexts and multiple contexts per VLAN is possible because you can configure the MAC address on the interface (which is recommended practice anyway because of failover MAC addresses when the secondary starts before the primary).

Conclusion

it would be fair to say that the Cisco Firewall Services Modules is a very odd piece of equipment. It has a unique feature in that it can connect directly to the backplane of the Catalyst C6500, however the Catalyst C6500 is not the great product it once was and has a limited future in data centres as the increase in bandwidth has moved past it.

The Firewall Services Module is no longer the fastest firewall at Cisco. The Cisco ASAS5580 is more than twice as fast, with less problems. I have experienced a lot of pain with the FWSM, and can’t say that I would wholeheartedly endorse the product.

Especially when you enable the application inspection features, the performance of the module becomes very poor. The full rundown on performance is covered in the Cisco Press book on the FWSM and you should consult this at length to understand the very many limitations of the FWSM.

For most use cases, I would choose the Cisco ASA or Juniper NetScreen as they work more effectively and reliably.

As always, please leave comments if you want to know anything else.

Footnotes

1. I’ll admit I have done this twice when I wasn’t thinking properly [back]