iscsi cluster question from dmz to inside networks?

[rob.keller]

Hello,

We have a web server that is hosting multiple sql 2005 db’s.  The web server is running on my Dmz network of my pix 515e.   I would like (if possible) to use an existing NetApp filer to host the sql db’s in a simple, cluster type setup.  The filer is located on the inside interface of the pix.   We would be using iscsi to connect the applications on the web server to the NetApp.

Can this be done, should it be done?  What drawbacks are there to getting this working?  Will my main issues be with the Pix firewall and configuring it to allow the traffic to flow through it?  My main goal with using the Netapp filer is to save money and not have to buy and additional San storage device for my web server (on the Dmz network).  Any thoughts are welcomed.

Many Thanks,

Rob

[swim_or_die]

Greetings,

From a technical perspective, there should be nothing preventing you from sending iSCSI traffic over the PIX.  iSCSI uses TCP 860 and 3260 by default.

However, best practices dictate that you should do everything you can to separate your iSCSI traffic from other LAN/WAN traffic, as it should never have to compete with other network traffic from a resource perspective.  Also, there are no security mechanisms buit into iSCSI that will provide confidentiality, integrity, and availability, of your transactions.

If your NetApp filer has more than one Ethernet interface, I recommend you isolate the iSCSI traffic from the web server to the filer via a switch instead of through the PIX and carve out a LUN (or whatever the equivalent is) reserved solely for your SQL databases.  This will require an additional NIC on your web server.

You could also get creative with VLANs if your filer NIC and your web server NIC support virtual IP's/trunking, but you're looking at some complexity and possibly some security issues, as it involves creating (non-routed) vlans on your inside switches that will separate your iSCSI traffic in its own vlan.

If you have only 1 Ethernet interface and have to route through the PIX, you should definitely extensively test the traffic through the PIX in order to ensure it supports the bandwidth requirements of both your iSCSI traffic and other network traffic, realizing that if there is congestion or other network issues, that the IP traffic will be dropped.  Probably a very bad thing given the transaction-dependent traffic associated with SQL.

Hope this helps.

[rob.keller]

Thank you very much for your quick response.  I was discussing my situation with a friend of mine who does a lot of consulting work.  He suggested that the easiest and simplest way to solve my problem is to just move my web server from the Dmz to my internal network and just Nat a public ip address to it.  Seems simple enough, but, I've always been a proponent of keeping the web server out on the Dmz.  It certainly would be easy to setup and test. What do you think about such a suggestion?

Thanks,

Rob

[swim_or_die]

Rob,

This is a good technical solution, but I think you're right in assuming you should separate your public-facing front-end from your back end SQL servers.  If your web servers placed behind the PIX on the inside interface are compromised, then they pretty much own the rest of your inside infrastructure.

If you do pursue this, you should at a minimum create a separate VLAN on your inside switch infrastructure for both your front-end web server and SQL databases.  You could then use ACLs on the VLANs to have some basic packet-filtering capability, even though you will lose the PIX stateful-inspection and application inspection capabilities of the traffic from your web front-end to your SQL cluster.

If you haven't done so already, you should have a proper risk assessment done for this system,  so that your management can either accept the risk associated with a less-secure configuration, or realize the need for an increase in your security/hardware/training budget.

-Steve