Interesting issue connecting to Sql server through a firewall..

We have an app in development. The front end of the app is web-based running
tomcat.
This app sits in our DMZ.
This app communicates to a sql 2000 server on our corporate network. The
connection is via microsofts jdbc 2000 connector.
We have allowed the server hosting the app to initiate connections to the
internal sql server on port 1433 only. The sql server can communicat any/any
back to the dmz.
I am seeing some interesting behavior - The front end initiates a connection
to the DB server on 1433 which is successful, but then also tries to
initiate a connection on 137 (named pipes/nbname), of course the firewall
blocks this and it eventually times out. and the opens addtional pool
connection on 1433. This causes the app to load very slowly as the pages
are data driven. If we open up 137 then the app runs at a normal speed.
I dont understant why the front end is trying to communicate to the server
on anything other than 1433. The server is configured for tcp/ip only. The
JDBC driver and app on the front end is doing everything by IP address.
I've thought of trying a host file on the front end resolving the back end.
and vice versa, but this shouldnt matter as everything is IP and not name.
I am now trying to figure out if this is an issue with the microsoft jdbc
driver config - though it looks like you dont have the ability to specify
protocols in it, an issue witht he sql server - perhaps the response to the
initial connection is telling the client to talk named pipes, or if its
just an OS issue.
Leaving 137 open from the dmz app to the internal sql server is not an
option.
Thanks in advance.
BillConnecting with an IP address doesn't necessarily mean that
the clients will use TCP/IP for the network library. Try to
force the clients to connect through TCP/IP by specifying
the network library to use, e.g.
Network Library=DBMSSOCN
I don't know about the issue with specifying libraries with
the JDBC driver but you can also set this up on the client
by configuring an alias and the network library with the
Client Network Utility.
-Sue
On Tue, 30 Mar 2004 16:22:15 -0600, "Bill B"
<fakexxbbaulingyy@.unitedcenter.com> wrote:

>We have an app in development. The front end of the app is web-based runnin
g
>tomcat.
>This app sits in our DMZ.
>This app communicates to a sql 2000 server on our corporate network. The
>connection is via microsofts jdbc 2000 connector.
>We have allowed the server hosting the app to initiate connections to the
>internal sql server on port 1433 only. The sql server can communicat any/an
y
>back to the dmz.
>I am seeing some interesting behavior - The front end initiates a connectio
n
>to the DB server on 1433 which is successful, but then also tries to
>initiate a connection on 137 (named pipes/nbname), of course the firewall
>blocks this and it eventually times out. and the opens addtional pool
>connection on 1433. This causes the app to load very slowly as the pages
>are data driven. If we open up 137 then the app runs at a normal speed.
>I dont understant why the front end is trying to communicate to the server
>on anything other than 1433. The server is configured for tcp/ip only. The
>JDBC driver and app on the front end is doing everything by IP address.
>I've thought of trying a host file on the front end resolving the back end.
>and vice versa, but this shouldnt matter as everything is IP and not name.
>I am now trying to figure out if this is an issue with the microsoft jdbc
>driver config - though it looks like you dont have the ability to specify
>protocols in it, an issue witht he sql server - perhaps the response to the
>initial connection is telling the client to talk named pipes, or if its
>just an OS issue.
>Leaving 137 open from the dmz app to the internal sql server is not an
>option.
>Thanks in advance.
>Bill
>
>
>|||Hi Bill,
The Microsoft JDBC Driver will only work with TCP. Named pipe
connections would use 139 or 445, not 137.
Are you running Microsoft Enterprise Manager on the same network or are you
only running the JDBC app from the machine?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.