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.

Interactive data access through firewall

Hi there!

I am facing this problem:

I have server A (SQL Server 2005) in LAN and server B (IIS 6) in DMZ.

Due to security policies, server A can initiate communications to B through a firewall; server B cannot initiate any communication to server A.

A web application on server B needs to interactively read/write data stored on server A.

I was reading something about repication, sql everywhere, service broker and something else.

Is there some integrated functionality in SQL Server 2005 that can help in this scenario, or should I develop some sort of sync application?

Thank you.

Bye!

Well, I would not suggest you to implement a sync mechanism on your own. Either use a local database which is replicated to the main server or open the firewall on the dedicated port and restrict the access to the IP of the web server and implement certain security rules like IPSec , using certificate based communication, encryption etc. to prevent any attack to your server.

Jens K. Suessmeyer

http://www.sqlserver2005.de

|||

Thank you for your answer.

I don't know exactly why, but they don't want data to be stored on the published server, nor in any other server in DMZ.

Since I have not much experience in firewalling and network rules, I am trying to adapt my software solution to the existing environment.

I developed a semi-interactive communication app based on asynchronous webservices, where server A polls from server B for queries that should be executed, and returns the resultsets. It's much like Exchange's "Direct Push Emails".

I am just wondering if this is the best solution, or if I should simply pretend some ports be opened on the firewall...

Interactive data access through firewall

Hi there!

I am facing this problem:

I have server A (SQL Server 2005) in LAN and server B (IIS 6) in DMZ.

Due to security policies, server A can initiate communications to B through a firewall; server B cannot initiate any communication to server A.

A web application on server B needs to interactively read/write data stored on server A.

I was reading something about repication, sql everywhere, service broker and something else.

Is there some integrated functionality in SQL Server 2005 that can help in this scenario, or should I develop some sort of sync application?

Thank you.

Bye!

Well, I would not suggest you to implement a sync mechanism on your own. Either use a local database which is replicated to the main server or open the firewall on the dedicated port and restrict the access to the IP of the web server and implement certain security rules like IPSec , using certificate based communication, encryption etc. to prevent any attack to your server.

Jens K. Suessmeyer

http://www.sqlserver2005.de

|||

Thank you for your answer.

I don't know exactly why, but they don't want data to be stored on the published server, nor in any other server in DMZ.

Since I have not much experience in firewalling and network rules, I am trying to adapt my software solution to the existing environment.

I developed a semi-interactive communication app based on asynchronous webservices, where server A polls from server B for queries that should be executed, and returns the resultsets. It's much like Exchange's "Direct Push Emails".

I am just wondering if this is the best solution, or if I should simply pretend some ports be opened on the firewall...