Friday, March 19, 2010

Design: Cisco Firewall Services Module Virtualization Design Traps

August 13, 2009 by Greg Ferro · Leave a Comment 


The Cisco Firewall Services Module (FWSM) is a mod­ule that installs into the a Catalyst 6500 switch, and con­nects via 6 x 1 gig­abit eth­er­net chan­nel bon­ded into a single Etherchannel on the back­plane. Delivering up to 6 gig­abits per second at less than 300W in a C6500 chassis it has got some poten­tial as a high per­form­ance firewall.

When used in multi-​​context mode to provide mul­tiple logical fire­walls there are some spe­cific considerations.

Virtualisation

The Cisco FWSM uses what appears to be a type-​​2 hyper­visor to provide mul­tiple logical fire­walls from a single phys­ical unit (very sim­ilar to that method used Cisco ASA/​PIX plat­forms). I model that func­tion along these lines when show­ing the System Context and the Admin context.

fwsm-design-trap-1.jpg

Packet Classification

Each packet that enters the FWSM in Routed Mode must be clas­si­fied and then alloc­ated to a con­text. Each packet is sent to a con­text. In the event that the packet can­not be clas­si­fied, it will send the packet to the Admin con­text. It is very import­ant to under­stand this when troubleshooting.

The FWSM uses a single GLOBAL MAC ADDRESS across all inter­faces. You can­not change it.

This is not a prob­lem unless the mul­tiple con­texts want to share the same VLAN inter­face. If two vir­tual con­texts share the same VLAN (regard­less of IP address), then the FWSM OS must use some other
cri­teria to determ­ine which con­text is the des­tin­a­tion for the pack­ets because all inter­faces have the same MAC address

From the manual:

Routed Mode Only
The FWSM lets you share an inter­face between con­texts. However, packet clas­si­fic­a­tion require­ments might make shar­ing inter­faces imprac­tical. Because the clas­si­fier relies on act­ive NAT ses­sions to clas­sify the des­tin­a­tion addresses to a con­text, the clas­si­fier is lim­ited by how you can con­fig­ure NAT. If you do not want to per­form NAT, you must use unique interfaces.

Note: The FWSM does not sup­port shar­ing the out­side inter­face of one con­text with the inside inter­face of another con­text (known as cas­cad­ing con­texts). Traffic that is out­bound from one con­text (from a higher to a lower secur­ity inter­face) can only enter another con­text as inbound traffic (lower to higher secur­ity); it can­not be out­bound for both con­texts, or inbound for both contexts.

Lets start with some­thing that works:

Single Context per VLAN

When the vir­tual con­text con­tains a single FWSM inter­face in a given VLAN,
the FWSM clas­si­fier will clas­sify all pack­ets into that con­text. This is
illus­trated in the fig­ure below.

fwsm-design-trap-2.jpg

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

Think care­fully about your VLAN inter­faces on your Supervisor

A clas­sic mis­take1 is to think you can con­fig­ure two inter­face on your Supervisor and then add VLANs to the FWSM. Of course, these will be in the same rout­ing pro­cess and the pack­ets will never reach the FWSM.

fwsm-design-trap-3.jpg

Use VRF-​​lite or MPLS to con­fig­ure around this prob­lem, since the rout­ing tables will be sep­ar­ate in each VRF the inter­faces do not exist is a single rout­ing space and would look some­thing like this. Herewith is the reason why Security Engineers need to have some MPLS skills.

fwsm-design-trap-4.jpg

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

Multiple Contexts per VLAN

In the scen­ario in which mul­tiple con­texts have inter­faces within the
same VLAN, the clas­si­fier will con­tinue to inter­cept pack­ets and extract the des­tin­a­tion IP address. The clas­si­fier can use NAT state­ments to estab­lish to which con­text to send the pack­ets to. Thus for a num­ber of fire­walls that share a VLAN with pub­lic IP addresses, per­form NAT on all traffic to RFC1918 addresses you can have many con­texts on a single VLAN, the but the private VLANs MUST be separate.

Thus the fol­low­ing will work correctly:

fwsm-design-trap-5.jpg

The scen­arios described above are valid and cor­rect design solu­tions. The fol­low­ing describes invalid scen­arios that must be avoided. They all
relate to scen­arios where mul­tiple con­texts have inter­faces within a
single VLAN.

The clas­si­fier does not use the rout­ing for clas­si­fic­a­tion. Even though
a con­text includes a static route that points to an external router as
the next hop to a sub­net, and a dif­fer­ent con­text includes a static
com­mand for the same sub­net, then the clas­si­fier uses the static com­mand
to clas­sify pack­ets destined for that sub­net and ignores the static
route.

The rout­ing table is ignored in every case. The fig­ure below illus­trates this scenario.

fwsm-design-trap-6.jpg

As men­tioned earlier, the FWSM clas­si­fier can use a mapped address in an
act­ive dynamic address trans­la­tion (set by the global com­mand) to per­mit
traffic. This can res­ults in work­ing one way flows, which may be desir­able, whereby egress traffic from the DMZ is for­war­ded to the FWSM the traffic is placed in the trans­la­tion table, and return pack­ets that are part of the flow will return through this flow.

Static NAT Hack

However, a new inbound flow will never be clas­si­fied and will be dumped
to the Admin con­text. In this case a static NAT is required.

fwsm-design-trap-7.jpg

It is pos­sible to solve this prob­lem using a static NAT added to con­fig­ur­a­tion, but this is not a par­tic­u­larly scal­able solu­tion, and would be hard to main­tain since you would not nor­mally con­fig­ure NAT for every access rule unless you actu­ally wanted to per­form address trans­la­tion for every single IP address. This option does not scale.

The Teeth Kicker Here

One of the things that makes troubleshoot­ing this prob­lem quite dif­fi­cult, is that exist­ing flows through the fire­wall — that is, TCP ses­sions that have already been cre­ated and are act­ive through the fire­wall can still work, some­times. Of course, the occa­sional or inter­mit­tent fault is very hard to detect.

Hard Lessons — Shared

I had a few hard les­sons on con­fig­ur­ing the Cisco FWSM before I fully under­stood how the packet clas­si­fier worked. You should take some time to learn this before you start design­ing with FWSM. The big prob­lem is that if you cre­ate a new con­text, and mis­takenly attach it to a VLAN that already has a fire­wall con­text from the same phys­ical unit, then pack­ets will be dropped for BOTH CONTEXTS

It might be worth not­ing that the Juniper NetScreen OS has sim­ilar issues but, pos­sibly, handles it bet­ter than the FWSM (if only just).

Footnote: Cisco PIX /​ ASA virtualization

Most of the inform­a­tion above applies to Cisco ASA/​PIX when used in Multiple Context Mode, but the option of build­ing cas­cad­ing con­texts and mul­tiple con­texts per VLAN is pos­sible because you can con­fig­ure the MAC address on the inter­face (which is recom­men­ded prac­tice any­way because of fail­over MAC addresses when the sec­ond­ary starts before the primary).

Conclusion

it would be fair to say that the Cisco Firewall Services Modules is a very odd piece of equip­ment. It has a unique fea­ture in that it can con­nect dir­ectly to the back­plane of the Catalyst C6500, how­ever the Catalyst C6500 is not the great product it once was and has a lim­ited future in data centres as the increase in band­width has moved past it.

The Firewall Services Module is no longer the fast­est fire­wall at Cisco. The Cisco ASAS5580 is more than twice as fast, with less prob­lems. I have exper­i­enced a lot of pain with the FWSM, and can’t say that I would whole­heartedly endorse the product.

Especially when you enable the applic­a­tion inspec­tion fea­tures, the per­form­ance of the mod­ule becomes very poor. The full run­down on per­form­ance is covered in the Cisco Press book on the FWSM and you should con­sult this at length to under­stand the very many lim­it­a­tions of the FWSM.

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

As always, please leave com­ments if you want to know any­thing else.

Footnotes

  1. I’ll admit I have done this twice when I wasn’t think­ing prop­erly [back]

Please rate this post:

  Why Rate Posts?
1 Star - It\\\'s Crud2 Stars - It\\\'s Tosh3 Stars - Something\\\'s missing4 Stars - Needs works5 Stars - Good Enough6 Stars - Good7 Stars - Excellent8 Stars - Brilliant9 Stars - Astonishing10 Stars - Awesomely Godlike? (3 votes, average: 8.00 out of 10)
Loading ... Loading ...

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!