Can't PPTP to SQL Server - Help!

You don't state how it is "not working".  Are you getting authentication errors, or is it timing out, or some other error.  The fact that you cannot see  any machines by name tells me that you have a DNS issue of some sort.  Also, what authentication model do you use on SQL 2K; SQL, WinNT, or both?  And which one are you attempting to use when you try to connect.

Thanks for all the replies and sorry for not answering your questions earlier.

- I do have a rule to allow the PPTP-Pool access to the internal network (PPTP-Pool, Any, Any, Accept). I've made sure it was in the right place in the rules chain.  I confirmed that the rule was working properly by checking the filter log and looking at the list of active connections. If I turn off the rule, entries appear in the log. If I turn it on, no entries appear.

- I'm trying to connect to SQL Server using the IP address and the name of the SQL Server instance as in 192.168.168.240\SQLSERVER2000. I verified those settings by connecting in the same manner from another Win2k machine on the internal network.

- SQL Server is currently set up for Windows and SQL Server authentication (though I've also tried just Windows authentication). I defined a user "test/test" on the Windows domain, a user "test/test" in SQL Server, and a user "test/test" in ASL. I put the Windows user/user under the Windows administrative group and gave user/user SQL Server administrative privileges.

- I'm attempting to connect to SQL Server through ODBC and through Enterprise Manager. I've tried both authentication methods (windows and SQLServer). The connection fails with a "general network failure" (error 11001, I believe). 

What I wish I could do (besides having this work the way I need it to) is as follows:

1) Verify that the PPTP client is actually reaching SQL Server. I thought I'd use Telnet on port 1433. What I do this on the internal network, I seem to connect but I see nothing that indicates actual communication. Is this all I can expect to see when I do this? Is there a better way to confirm communication with SQL Server?

2) Understand what the options at the bottom of the PPTP Roadwarrior Access set up screen mean.  The documentation doesn't explain their significance. For instance, Client Domain seems important but isn't even mentioned. What is this value? How is different from the Domain that the user specifies on the client when making the initial VPN connection? 

3) Be able to communicate with someone who is using PPTP to connect to SQL Server and who has enough Windows and SQL Server access privileges to be able to tell me how things are configured when working. If someone is in that position, please email me.

I appreciate everyone help. Please post any tests you'd like me to run. Thanks.

By the way, I'm using version ... (now, how does one find the version number through WebAdmin?) ... whatever the latest 4.xx is.

Farid

[ QUOTE ]
By the way, I'm using version ... (now, how does one find the version number through WebAdmin?) 

[/ QUOTE ]The ASL version number should show in your web browser's program title bar when you are logged into Webadmin. It should appear something like this:

Webadmin Version 4.021 on firewall.yournet.com

Ahhh... I see it now. Thanks. Version 4.021 it is. 

Farid

Problem solved!!!

A quick explanation for anyone who should stumble upon this thread in the future.

Part of the problem was my fault for confusing named pipes and TPC/IP naming conventions. With named pipes, the server is called \server_ip\sqlserver_instance_name. With TCP/IP, the server is called simply server_ip. But you must also specify the communication port (using the Client Networking utility or a similarly named button on the ODBC setup wizard) to 1433 or whatever port the server is listening on.

The other part of the problem was that the machine I was originally trying to connect to was on a non-standard port.

So here's what you do should you be in a similar situation:

To confirm that you got the tunnel open all the way to SQL Server, simply telnet to the ip of the SQL Server machine using the port that SQL Server is known to be using (run telnet then use OPEN ip_address port_number). If you get just a flashing cursor (and no error message), you're there. All you need to do then is deal with any authentication issues when you try to use the connection. If not, ASL is blocking the port you are trying to use (check your filter logs) and you need a rule to allow the traffic through or you are trying to connect to wrong machine or you are trying to connect over the wrong port. 

Farid

Problem solved!!!

A quick explanation for anyone who should stumble upon this thread in the future.

Part of the problem was my fault for confusing named pipes and TPC/IP naming conventions. With named pipes, the server is called \server_ip\sqlserver_instance_name. With TCP/IP, the server is called simply server_ip. But you must also specify the communication port (using the Client Networking utility or a similarly named button on the ODBC setup wizard) to 1433 or whatever port the server is listening on.

The other part of the problem was that the machine I was originally trying to connect to was on a non-standard port.

So here's what you do should you be in a similar situation:

To confirm that you got the tunnel open all the way to SQL Server, simply telnet to the ip of the SQL Server machine using the port that SQL Server is known to be using (run telnet then use OPEN ip_address port_number). If you get just a flashing cursor (and no error message), you're there. All you need to do then is deal with any authentication issues when you try to use the connection. If not, ASL is blocking the port you are trying to use (check your filter logs) and you need a rule to allow the traffic through or you are trying to connect to wrong machine or you are trying to connect over the wrong port. 

Farid