What exactly will the FWSM be firewalling - is it just vlan 2 because you talk about making this the inside and having a new vlan for the outside. What about the other server vlans etc.
Are you looking to use more than one context because just in case you are unaware you can only use static routing in multi-context mode.
Reasons for transparent could include whether is it just IP traffic you are dealing with or do you have for example IPX.
Do you want routers to form neighborships with through the firewall.
Other factors to take into account are load-balancing ie. are you doing any to the servers, does this need to integrate with the FWSM.
If you could give a bit more detail of yhour topology especially in terms of DMZ's etc. and where you see the FWSM in the overall picture we may be able to point you in the right direction.
One thing worth mentioning. All the documents always talk about the ease with which transparent firewalls can be placed into existing setups. But from my experience it really isn't that hard for routed either. Often it involves nothing more than moving the L3 SVI ip address to the FWSM and setting up routing.
I have attached a sample diagram of the current network. The network is a MAN providing triple play services.
VLAN 2 - Management
VLAN 3 - Voice
VLAN 4 - IPTV
Broadband is provided using a layer2 VLAN directly to the BRAS with PPPoE
VLAN 3 and 4 are internal only and do not need public access in or out.
DMZ requires public access in/out and VLAN2 requires internet access out.
The are multiple networks connected to the 7600 and each MAN location, all running OSPF.
I also run SSM Multicast on VLAN 4
Ideally I would like all the networks behind the FWSM.
The border router handles BGP and ISP connectivity. I only have IP traffic.
At the moment there is no requirement for load balancing but going forward there may well be.
I don't believe transparent will work for this situation because in the docs it mentions that you can not have any secondary networks on the inside. So I think that rules it out.
That leaves me with routed mode. I don't think I can place an SVI (MSFC) on the outside because I will have traffic bypassing the firewall to my SVIs on the inside.
That leaves me with placing the MSFC on the inside. Which suits me because of all my SVIs.
I have attached a diagram of a proposed solution.
In this solution I remove the PIX and crate a new VLAN10. I do not assign an SVI to this VLAN but associate it with the outside interface on the FWSM and assign it an IP.
The DMZ I associate VLAN20 but no SVI and associate with FWSM and assign an IP.
VLAN2 has an SVI and I associate it with the FWSM inside interface and assign an IP.
I configure NAT and statics for public access to the DMZ and DMZ to inside traffic.
I do not want to run any routing protocols on the FWSM just static routes.
With the SVIs for VLAN 2,3,4 etc all running OSPF.
Is this solution legal. Will traffic bypass the FWSM. Can you think of any drawbacks.
Because I have a multiple context license I would like to make use of these contexts for future business. I have attached a diagram with multiple contexts. If I go with the above solution do you think I will run into problems later on. I don't think transparent will ever be an option if I go with the above because I would need an SVI on the outside.
"I don't believe transparent will work for this situation because in the docs it mentions that you can not have any secondary networks on the inside. So I think that rules it out."
You can create multiple bridge groups however with the future in mind and the flexibility of routed mode i would go with routed in the interim. As your multi-context design shows you can mix and match routed/transparent. More on the multi-context later.
"That leaves me with routed mode. I don't think I can place an SVI (MSFC) on the outside because I will have traffic bypassing the firewall to my SVIs on the inside"
Correct. As long as you have SVI's on the MSFC for your server vlans then you cannot have another SVI for the outside or as you say traffic will just route around your FWSM. This also applies to your multi-context design UNLESS you migrate the L3 SVI's to the FWSM itself, something which isn't proposed in your designs as far as i can see. A common design is to have a vlan that connects the MSFC to the outside of the FWSM and then all the protected vlans only have interfaces on the FWSM and not on the MSFC. This design though presupposes you want to firewall each vlan whereas even in your multi-context design you don't seem to want to do that. Note none of what i am saying is criticism, i'm just trying to get the full picture.
There is nothing wrong with your proposed interim design except that i would recommend having a dedicated vlan from the FWSM to the MSFC on the inside rather than use one of your server vlans so you end up with
v10 -> FWSM -> v100 -> MSFC -> vlans 2, 3, 4.
where vlan 100 is the new vlan purely for FWSM to MSFC connectivity.
"Is this solution legal. Will traffic bypass the FWSM. Can you think of any drawbacks"
Legal may not be the best word :-), it is valid and it will work. Traffic cannot bypass the FWSM because
1) to get to vlan 20 you have to go to the outside of your FWSM
2) to get to any of the inside vlans from either the outside or the DMZ you have to go to the FWSM.
Obviously traffic is unrestricted between vlan 2,3.4.
Be aware that with standalone PIX/ASA devices traffic is allowed from a higher to a lower security interface without an access-list. This is not the case with the FWSM so you would also need an acl on the inside interface ie. vlan 100 or vlan 2 depending on which you go with.
Can't see any major drawbacks assuming your existing setup works as you are just doing a straight swap to the FWSM.
Firstly your design shows different vlans on the outside. A perfectly acceptable alternative is to use the same vlan for all your contexts on the outside. This would negate the need for subinterfaces on the 7200. One caveat with that statement. I have deployed the FWSM in this way with multiple contexts in data centres but i have never had a mix of routed/transparent. All my contexts were routed, so i can't say 100% that it would work with transparent as well. Perhaps you could test ?
Only other thing i would add is that you can also if needed mix and match whether the MSFC is on the inside or the outside per context so you may want to factor this in just in case you weren't aware of it.
Overall there is nothing wrong with what you are proposing but please come back with more questions if needed. The FWSM gives you great flexibility in how to deploy firewalling services and the ease with which it integrates with the 6500.
I don't have a requirement to firewall my internal VLANs 2,3,4. However I do understand what you are saying about adding the VLANs to the FWSM and firewalling between the VLANs. I would just be a bit worried about routing and multicast traffic. I currently run three OSPF processes, but I could combine two to leave me with the supported two, but then of course OSPF is not be supported with multiple contexts :-(
Yes I will incorporate the separate VLAN100 for FWSM to MSFC connectivity.
Thanks for the ACL pointer, that would have caught me out when it came to migrating to the FWSM.
I will more than likely stick with routed mode in all contexts as transparent has the drawbacks of a single network on the inside.
I did not realize I could mix and match per context I will keep this in mind.
I have purchased the Cisco Press book
Cisco Secure Firewall Services Module FWSM so I will see if there are any other pointers I can incorporate into the design.
Again thanks for your help and I will let you know how the migration goes.
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...