Spoof database connection to be local instead of remote

Solution 1:

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.

Solution 2:

While you certainly could use techniques like SSH port forwarding to make a remote listening TCP socket appear like a local one, it probably would not be of any help.

If your client is "crashing" upon connection, it most likely would not stop doing so just because you are using a different destination IP address.

There might be a myriad of reasons why the software is running fine when connecting to a local database but becomes troublesome with a remote database, including but not limited to

• version issues
• use of different protocols (Named pipes vs. TCP/IP)
• authentication issues (integrated authentication might work locally but break for remote systems)
• configuration issues

You should direct your efforts towards the problem's diagnosis instead of doubtful workaround attempts.

Solution 3:

The other answers seem to suggest you should get the application fixed - this is not always possible in reality, so here's a bit of a band-aid/paper clip/bubble gum fix.

I haven't tried this with MSSQL, but for MySQL, I was able to configure TCP proxying via Nginx. The setup would be to deploy Nginx on the same box as your application, with config like that in this SO answer; hopefully it'll work for you just by changing the ports to 1433:

stream {
  upstream db {
    server mssql.example.com:1433;
  }

  server {
    listen 1433;
    proxy_pass db;
  }
}

EDIT: If using named instances and SQL Browser service (which uses UDP) is involved, you can also add a config for UDP proxying: https://dev.to/jordonr/reverse-proxy-ms-sql-with-nginx-3e90

stream {
    upstream dbtcp {
        server db1:1433;
    }

    upstream dbudp {
        server db1:1434;
    }

    server {
        listen 1433;
        proxy_pass dbtcp;
        proxy_connect_timeout 1s; # detect failure quickly
    }

    server {
        listen 1434 udp;
        proxy_pass dbudp;
        proxy_connect_timeout 1s; # detect failure quickly
    }
}