Sql-server – Spoof database connection to be local instead of remote

localhostnetworkingspoofingsql servertsql

I am trying to connect one of our clients "as is" programs to a remote database instead of a local one, they think that they have coded it to work that way, but for some reason the program crashes when trying to connect to a remote database. I don't have the source code so I can't really dig much deeper than that and the company does not provide any upgrades or custom modifications. I can successfully connect to the database through SqlDbx and HeidiSQL so I know that the server is set up correctly.

This is why I need to find a way to spoof a remote connection on port 1433 to appear like a local database connection to the program. I thought about editing the hosts file, but it will most likely crash other programs if I bind localhost to another IP than 127.0.0.1.

Any ideas?

UPDATE:

I've tried solving it other ways like suggested, but I've tried everything I can think of.

  • It's the same versions of all the programs
  • TCP/IP works instead of Named pipes on localhost and works with sqlviewers like SqlDbx and HeidiSQL
  • Authentication works with sqlviewers
  • The configuration is only the fields needed for the database connection string

The only thing that I can see is left is that there is something restricting it from inside the code which I have no control over.

Best Answer

Essentially, you're trying to work around what appears to be somebody else's bad implementation. That seems reasonable to me, and sometimes, that's a necessity. If this program is indeed "crashing" when trying to connect to one database but not another, as opposed to, oh, you know, displaying an error message, that's pretty weak.

I have a standby solution for this in Linux ("redir") ... but not Windows; however, I found this in the Google machine:

http://www.vakuumverpackt.de/tcptunnel/

I tested it just now with the "Cygwin" version -- no install required, it has an exe and a DLL and it "just worked" on my Windows 7 laptop. Neat little bonus, it has a --log-to-stdout option which, combined with > into a file, logs the bytes sniffed from the stream (might be interesting reading). I didn't have a SQL Server handy, but I tested it with some other TCP services and it seems to work as intended -- it listens on a local socket, and when connections come in, it makes a connection to a designated socket on a remote machine, and ties the ends of the pipes together. Listening on 1433, it "should" do the trick.

It's going in my toolkit, anyway.

Related Topic