FWSM Design for Internet Data Centre

Unanswered Question
Apr 20th, 2007

Hi,

The Current Cisco Data Centre SRND v2.0 documents, specifically "Firewalling and Load balancing with 6500",

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/ccmigration_09186a00806eaff1

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?

Thanks,

Mark

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Fri, 04/20/2007 - 03:10

Hi Mark

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 :-)

HTH

Jon

UTVi-NetAdmin Fri, 04/20/2007 - 04:28

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

Jon Marshall Fri, 04/20/2007 - 04:48

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

UTVi-NetAdmin Fri, 04/20/2007 - 05:04

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

Jon Marshall Fri, 04/20/2007 - 05:13

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

mpipkin Mon, 05/07/2007 - 13:05

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)

*******************

MSFC CONFIGURATION

*******************

interface Vlan10

description OUTSIDE PERIMETER VLAN

no ip address

no mop enabled

!

interface Vlan15

description CORE (INSIDE) SVI VLAN

no ip address

!

interface Vlan20

description CORE SVI

ip address 192.168.1.2 255.255.255.248

!

interface Vlan30

description CUSTOMER A SVI

ip address 192.168.1.10 255.255.255.248

!

interface Vlan40

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?

Maury

Jon Marshall Mon, 05/07/2007 - 22:49

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

Actions

This Discussion