The Current Cisco Data Centre SRND v2.0 documents, specifically "Firewalling and Load balancing with 6500",
mention the fact that, typically, for an Internet Data Centre, the FWSM is placed 'outside' the MSFC, yet the document concentrates on the scanrio where FWSM is 'inside' or behind the MSFC.
Does this change how you would go about configuring a FWSM?
If you only want to place the FWSM in front of the MSFC then no not really. You just need to make sure that the routed vlan is not the outside interface.
If you want to have a FWSM in front of the MSFC and also behind you need contexts. We have this setup in our data centre where we have multiple server vlans protected by the FWSM with the MSFC in front and then a separate context for connecting a 3rd party with the MSFC behind.
I would still be wary of using the FWSM as the front door to the internet. I believe it is very good as a datacentre firewall for segregating your server vlans etc. but i would feel nervous using it as the main Internet firewall. The scope for a configuration error, vlan hopping etc. would make me nervous. I would prefer to use a standalone firewall myself.
But it could just be me being old fashioned :-)
I understand, it needs to be right, first time.
As you say, a stand-alone unit would be a better choice for the 'front door' but I would doubt if there will be the resources for it.
Considering you (I) follow Best Practices regarding Infrastructure Edge Protection etc..., are there any other downsides to haveing the MSFC in front of the Firewall, which is what the SRND's descride in an Intranet DC?
Apologies in advance if i have misunderstood your question.
If you have the MSFC in front of the FWSM then you can only protect those vlans that are created as DMZ's on the FWSM. So if you have a 6500 switch that has 10 vlans on it.
5 of those vlans have been allocated to the FWSM. Anybody accessing these 5 vlans would need to go through the FWSM.
But to access the 5 vlans that are not allocated to the FWSM you can just route via the MSFC.
If you place the FWSM in front of the MSFC then to get to any of the 10 vlans you need to go through the FWSM.
(Note - this is assuming access is coming from a remote vlan - ie. it doesn't exist on the 6500 ).
It all depends on what is on the other side of the MSFC. If it is the Internet or a partner intranet then it would be a mistake in my opinion to place the FWSM behind the MSFC as the external parties would be hitting the router before the firewall.
If your own WAN is on the other side of the MSFC and you are only firewalling certain servers then i would have no problem with having the MSFC in front of the firewall.
Hope this makes sense and has answered your question.
No apologies needed.
With the FWSM being the only dvice we will have in order to secure our site, then it sound as if multiple contexts is what we need. One to protect DC from Internet-sourced traffic and another to filter inter-vlan(serverfarms) traffic?
Is it true that without additional licensing, the FWSM supports 3 contexts, one Admin and two others? So this would suit us ok?
Yes you get 3 contexts for free :-). One is the admin context and then as you say you could use one context for the Internet etc. and another for the internal server vlans.
Having a separate firewall for the internet and a separate one for your internal servers helps to keep the access-lists manageable and helps avoid config errors.
You can also have different people in charge of configuration if that is what you needed.
Each context supports up to 256 interfaces so as long as you are using routed mode you should have enough interfaces for your internal server vlans.
HTH, let me know if there is anything else you need.
We came up with a unique and secure (verified by 3rd party auditor) solution for our FWSM configuration. Basically, we placed one context on the perimeter or internet facing. then our msfc. then we placed our additional firewall contexts behind the msfc. so the effect looks like a firewall, a router with multiple interfaces that connect to multiple firewalls. Here is a snippet:
Perimeter Context IP Config
ip address inside 192.168.1.1 255.255.255.248
ip address outside (public IP Address)
route inside 10.10.10.0 255.255.255.0 10.10.10.2
route inside 192.168.1.0 255.255.255.0 192.168.1.2
route inside 172.16.0.0 255.255.0.0 192.168.1.2
route outside 0.0.0.0 0.0.0.0 (SP Gateway)
description OUTSIDE PERIMETER VLAN
no ip address
no mop enabled
description CORE (INSIDE) SVI VLAN
no ip address
description CORE SVI
ip address 192.168.1.2 255.255.255.248
description CUSTOMER A SVI
ip address 192.168.1.10 255.255.255.248
description CUSTOMER B SVI
ip address 192.168.1.18 255.255.255.248
ip route 172.16.1.0 255.255.255.254 192.168.1.9
ip route 172.16.1.0 255.255.255.254 192.168.1.17
Customer A Context
ip address outside 192.168.1.9 255.255.255.248
ip address www-dmz 172.16.1.0 255.255.255.0
ip address inside 172.16.2.0 255.255.255.0
route outside 0.0.0.0 0.0.0.0 192.168.1.8
Customer B Context
ip address outside 192.168.1.17 255.255.255.248
ip address www-dmz 172.16.3.0 255.255.255.0
ip address inside 172.16.4.0 255.255.255.0
route outside 0.0.0.0 0.0.0.0 192.168.1.18
does that make sense?
Yes it does and the only thing i would say about this is that because you are routing between your outside and your inside contexts then you need to be careful as to what the customer can do once they have accessed their devices.
A lot depends on what type of access they have, but lets say for example they have telnet access to one of their servers on their DMZ. You need to make sure that they cannot initiate connections to anywhere but where you want them to go.
An alternatiev design would be to have the same context as you have on the outside.
You then have a shared vlan that your outside context connects to on it's inside interface. The customer contexts connect to this shared vlan with their outside interfaces.
This way the only routing that is being done is by the FWSM and the MSFC does not come into it.
Having said that this type of setup can create it's own challenges, see post in firewalling on cascading contexts. And only you are aware of the customer IP addressing and topology of your network.
With the right access-lists etc. then i cannot see a major problem with what you have.