I'm having our CE come in to present the FWSM for 6500. I'm hoping to get some feedback from this forum a bit in advance. Does anyone have any pro's/con's regarding the FWSM, Routing (OSPF), Policies, MSFC2/SUp720 integration, Vlans? Or even design limitations using the FWSM.
The pix 6.3 code can run ospf as well as understanding and processing IEEE 802.1q tagged vlan frames using logical interfaces, and you can have up to 10 logical interfaces and 8 physical interfaces on a pix 515. To my knowledge, the pix has more IDS signatures than firewall functions on a router, and will probably continue to do so as its main function is firewalling.
It is my opinion that the FWSM is a good place to start firewalling functions (using it as an internal firewall, for example) and I believe that it can compliment a pix, instead of replacing it entirely. Having a pix can distribute your security policy a bit more, and the benefit of that is that a compromise of one device, say the 6500, does not affect the integrity of the other. Similarly if there were security holes in IOS and/or CATOS they usually would not affect pix code and vice versa.
Regardless of using the FWSM only, a PIX only or a combo of both use private or edge vlans where possible to prevent two devices connect to the same switch from talk direct to each other. The later version of the CAT code can extend that concept to trunk links as well. Using edge vlans forces the traffic to flow through a layer 3 device which can be the msfc or the pix. I also recommend using routing protocol authentication using md5 keys to validate routing updates. The later version of the pix code (6.3, maybe 6.2 as well) and the ios 12.0 and higher version have ways of authenticating ospf, eigrp, and rip v2 updates. The Cisco online resources can provide some good examples of how to do this.
If you want to use the pix and have the routing protocols updates flow through it, but not to it (that is, it does not process the updates, it just forwards them) you will need to tunnel the traffic using GRE.
Another good security technique that may be of value is unicast verify reverse path check (VRPF). The pix 6.3 code is capable of doing this as well as some 12.0 or higher ios codes and you should not need FWSM to implement that. This will help mitigate attacks using spoofed ip addresses, or at least give you an idea of where they originate from in the case where it cannot be prevented. However in IOS you need to implement CEF to get the benefits of VRPF. VRPF is helpful on the PIX when running dynamic routing protocols such as OSPF.
If I come across anyone I know that uses FWSM, I'll find out what they think of it and pass it on.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...