Question

I am communicating with a server behind Microsoft ForeFront and I am in need to connect to the Visual Studio Remote Debugger located on the server. My development computer is located outside of Microsoft ForeFront and therefor it is quite troublesome. So far I have managed to make the connection from Visual Studio on my machine outside forefront to the Remote Debugger on the server inside forefront. I can see in Remote Debugger Monitor that connection is successful. "DOMAIN\Jens connected" it says. The Visual Studio client is still waiting and after a while it complain "Unable to connect to the Visual Studio Debugging Monitor named Jens@SERVER. The Visual Studio Debugger on the target computer cannot connect back to this computer"

To set this all up so far I have tried to tunnel the remote debugger connection using Putty. I have set up Putty to connect to a linux-server outside the Microsoft Forefront network. In Putty I have set up the following forwards (123.123.123.123 is the linux-server outside ForeFront):

4R123.123.123.123:135      localhost:135
4R123.123.123.123:137      localhost:137
4R123.123.123.123:138      localhost:138
4R123.123.123.123:139      localhost:139
4R123.123.123.123:445      localhost:445

This part works great. I can access all these ports from my development machine and as I wrote earlier Visual Studio can even connect. I have set up a local administrator on my development computer and on the server with the same username and password and I run both Visual Studio and the Remote Debugger using this user.

Now my theory here is that the Remote Debugger on the server wants to make a TCP connection back to my development computer to send a reply to Visual Studio and I guess my connections from visual studio to the remote debugger on the server would look like they have originated from localhost. I therefore guess that the Remote Debugger will try to connect to origin (localhost) and try to send the reply there.

Does this make sense? If so, is there a way I can spoof this connection as coming from the actual IP address of my computer? If that is possible maybe I can trick the Remote Debugger to connect to the right place?

If I have explained this in a bad way, please ask me and I will do my best to clarify.

Was it helpful?

Solution

Ok, I have now found a simple solution to this. I installed OpenVPN server on a VMWare virtual machine on my development box. So I now have tree machines.

  • My development machine
  • The server in need of debugging
  • A new OpenVPN server (virtual)

I then opened up port 443 in my firewall towards the OpenVPN machine and next I installed the OpenVPN client on both the server in need of debugging and on my development machine and connected both to the OpenVPN server.

I had to configure OpenVPN so that I had 2 different users (one for each client) and I also had to enable cross-user communication on the VPN. I just had to add the IP submet of the VPN to the allowed private network list.

One last bit was to add an entry in the C:\Windows\System32\drivers\etc\hosts file pointing the server name to the vpn ip address (you have to connect to remote debugger with correct server name)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top