November 5, 2002 at 3:05 pm
I apologize if this question has been asked before. I've done some checking and haven't been able to find a solution.
I have server in a DMZ zone that is accessing an SQL server on our internal network. The connection works but is slow when first connecting. For example, I can run a 'netstat -an' on the server in the dmz which will display no established sessions to the SQL server over port 1433. If I then try to connect to the SQL server, the connection can take up to 4 seconds.
Running another netstat will show the new connection as established. Using the existing connection will then be quick from then on.
The configuration is as follows:
Internet<-->Netopia router<-->ComputerA<-->Sonicwall firewall<-->SQLServer
Netopia router Internal IP: 192.150.150.1
ComputerA IP: 192.150.150.150
The Default Gateway for ComputerA is the Netopia (192.150.150.1)
Sonicwall firewall External IP: 192.150.150.2
SQL Server IP: 192.200.200.200
Netopia Router
Static Route: 192.200.200.0 (Dest) 255.255.255.0 (SM) 192.150.15S0.2 (GW)
Sonicwall firewall
Access allowed over port 1433 from 192.150.150.150 to 192.200.200.200
Using this configuration when I attempt to connect from ComputerA to SQLServer the following message is logged on the Sonicwall:
"TCP Connection Dropped."
SRC: 192.150.150.150, PORT_NUMBER, WAN
DEST: 192.200.200.200, 1433, LAN
Type: 143, Rule: 0
If I change the Default Gateway on ComputerA to the Sonicwall (192.150.150.2), the same thing happens.
In order to get the connection to work, with the slow connection time, I added the following to the Sonicwall:
One-to-One NAT: 192.150.150.55 maps to 192.200.200.200
192.150.150.55 does not exist, it is not a computer in the DMZ
If I now try an SQL connection to 192.150.150.55, the connection to SQLServer works, but is slow when first connecting.
Using a 'virtual' non-existent server is probably not the correct way to do this 🙂
Any suggestions on how this should be configured would be greatly appreciated.
Thank you.
November 5, 2002 at 7:26 pm
When you have no connection try a tracert and see what happens. It may be trying to negotiate the initial handshake and is getting delayed along the path. Now the fact that once connected it can reconnect quickly most likely means that connection pooling is doing it's job. ot sure otherwise.
November 5, 2002 at 9:13 pm
Basically, it looks like the firewall is right... you need to open port 1433 into your internal network. The question is, do you need to allow all network traffic back to the server within the DMZ on the firewall or do you have it toggled where the internal network can send through anything?
Obviously there's a catch on the firewall about the IP... and the reason you're having to NAT the SQL Server. I've not worked with that brand of firewall, so I'm not sure what the configuration should be. If you were dealing with a PiX, I could point you to some folks. You might try a SonicWall support forum.
With respect to the ports (which it looks like you've done), here's the MS article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q287932
I'm assuming you're using ADO, and if that's the case, you want to make sure you're using TCP/IP as your default network library... if it is trying named pipes, that's one explanation for the delay. Here's another KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q269882
One other thing to keep in mind is that when a client does try to connect to SQL Server, it will likely try to do the standard NetBIOS communications checks to the respective ports, so that does take some time to timeout as well.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
November 6, 2002 at 10:26 am
Is this a SonicWall Pro? Used one with no real issues. Be sure the client isn't trying NetBIOS as Brian suggested first.
Steve Jones
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply