Jon,

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?

Thanks,

Mark

Mark

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.

Jon

Jon,

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?

Thanks,

Mark

Mark

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.

Jon

Hi Maury

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.

HTH

Jon