Should work fine. What problem are you seeing?

At first I thought we were seeing problems with the ports on the cluster. I
found this article that made me think we were close to an answer. see:
http://share-point.blogspot.com/2008/10/moss2007wssv3-using-clustered-sql-named.\
html But, even using this DSN fix didn't work. Install still fails with a
'....Server does not exist or access denied.'

To summarize, we have:

- clustered Active - Passive sql  cluster 2008 with (3) name instance. SharePoint
is using one of those instance.
- Farm service account used for installation of SharePoint is a domain account,
local admin on WFE(s) and has public, security admin and db creator rights on
SQL server database.
- initial Wizard is being run  on Index server

Local admin rights are not necessary at all. Deployment are done as the user
initiating the command, not the farm account.

Ensure that the SQL Browser service is running. SharePoint won't see the
instance without it running.

Make sure the SQL Browser service is running

Yep. Up and running.

We are starting to suspect an ACL issue. The WFE(s) are on a different subnet
than the SQL cluster.

Have you checked to make sure that you're running  the correct access
protocols, and that your Surface Area config isn't shutting you out?

If I understand what you are suggesting to review, from SQL Server Configuration
Manager, my Instance is reporting "...Shared Memory, Named Pipes and TCP/IP" as
all being "Enabled". Am I missing something?

Are there any other applications that can try to connect to a named  instance
from the same subnet as the WFEs? Perhaps one of those freebie sql  clients, just
to test is connectivity is the issue. Integrated security is what you want, and
if using Kerberos, it may also be related to that. Check for Kerberos errors in
the windows event logs.

Ensure the user account running  the config wizard has at least DBA rights on the
cluster. I think DB Creator and DB Security Admin are the necessary role. You
also might want to turn on C2 audit tracing on the SQL server to try and find
out if it's a permission issue on the sql servers. Another trick is to turn on
Auditing for everything in the Local Computer Security Policy, be sure to audit
all failures. Might be a good idea to add that to the hard drive hosting the SQL
databases as well.