I asked previously how to configure 2 SSH tunnels using an intermediary server in order to run Remote Desktop through them and I managed to make it work. Now, I'm trying to do the same, using the same machines, but in reverse order. Here's the setup:

  1. Windows 7 PC in a private network, sitting behind a firewall.
  2. Public access Linux server, which has access to the PC.
  3. Windows 7 laptop, at home, on which I wish to do Remote Desktop from the PC.

I use Putty on the laptop to create a reverse tunnel from it to the Linux server: R60666 localhost:3389.

I use Putty on the PC to create a regular tunnel from it to the Linux server: L60666 localhost:60666.

I SSH to the Linux sever and I run telnet localhost 60666 and it seems to produce the expected output, as described in the debugging tips that I received here.

I try to connect Remote Desktop from the PC to the laptop: localhost:60666. It asks for my username and password, I click OK and it locks my current session on the laptop (so I see the welcome screen on the laptop instead of my desktop), it shows the "Welcome" message in the Remote Desktop screen and then it just goes black. It doesn't disconnect, it doesn't provide any error and I'm not able to perform any actions in the Remote Desktop screen. I tried the same setup with a Windows XP laptop and I'm experiencing the same symptoms. I also tried to use different ports than 60666, but nothing changed. Does anybody have any idea what I'm doing wrong?

Update: As pointed out by @jwinders, I'm not able to run telnet PC 3389 from the Linux server directly. Since Windows Firewall has a rule to allow all connections on port 3389, I have no idea what is blocking it. Fortunately, I'm able to create a SSH tunnel from the Linux machine to the PC ssh 3389:localhost:3389 'domain\user'@PC.

  • I'd seriously just use GoToMyPC at that point.
    – ewwhite
    Jul 11, 2012 at 13:05
  • 1
    @ewwhite I don't see any reason why I shouldn't be able to use the setup that I described. Even if there are simpler solutions (that require involving another 3rd party), I consider this to be an interesting challenge. Jul 11, 2012 at 14:24
  • 1
    This is a vey ld post, but the problem still exists, and it's quite frustrating that all the answers seem to miss the point. The connection can be initiated, but it breaks a second after it starts. The comment that "login via rdp, will disrupt that connection" seems coherent with what is observed but it doesn't answer why nor it suggest a solution.
    – rhermans
    Aug 8, 2019 at 13:37

6 Answers 6


I ran into the same black screen + disconnect problem myself today, using putty as my client. I did find a solution eventually.

I switched from putty to bitvise tunnelier, and setup a S2C connection with the following settings:

listen if:
listen port:13389
destination host:localhost
dest port:3389

As chance would have it, I'm using bitvise ssh server on my server, so this may just be a happy combination for two products made by the same vendor. It would be great if this solves the problems for others.

For the record, I'm not affiliated with these guys in any way.


I don't see anything wrong with your SSH tunnels. Connecting to localhost:60666 on the PC should end up at localhost:3389 on the Laptop. And the fact you're getting a login screen confirms this assessment.

A bit of googling on the blank screen get's me to this Microsoft knowledge base article: http://support.microsoft.com/kb/555840. It states a blank screen might by due to possible MTU size mismatches:

Verity that the server, client and the network equipment using the "MTU" size.

Given your fair amounts of network hops, firewalls and what have you, packet fragmentation is quite likely :) Most Windows machines use an MTU of 1300 by default, while most Linux boxes have 1500 (the max allowed value for LAN, not considering jumbo frames). You can try lowering these to reduce fragmentation.

See also:

  • 1
    Thanks for the tip, but, unfortunately, it doesn't do the trick. The MTU on both my laptop and the PC are set to 1500 (netsh interface ipv4 show subinterfaces) and ping linux_server -f -l 1472 succeeds from both machines. Just as a test, I tried to set the MTU on the PC to 1300, but it did not help. I also tried to change it on the laptop as well, but to no avail :( I am wondering if there is any "smarter" way to debug this issue... Jul 18, 2012 at 10:01

Wouldn't a VPN be more appropriate? OpenVPN is super simple to configure. Here is a sample config and some links to guide your through the certificate creation process.

Just configure the intermediary to be the host, and the guests can dial in and still communicate with each other.

apt-get install openvpn
mkdir /etc/openvpn/easy-rsa
mkdir -p /etc/openvpn/ccd/client_server
touch /etc/openvpn/ipp.txt
cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
source ./vars
./build-key-server server
cd /etc/openvpn/easy-rsa/keys
openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt -certfile ca.crt

Then create a new file /etc/openvpn/client_server.conf and put the following in it, changing the SERVER_IP_ADDRESS as appropriate

port 8443
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
pkcs12 /etc/openvpn/easy-rsa/keys/server.p12
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
ifconfig-pool-persist /etc/openvpn/ipp.txt
client-config-dir /etc/openvpn/ccd/client_server
keepalive 10 120
status /var/log/openvpn-status.log
verb 3
reneg-sec 0

Then build a key per user who is going to connect, and create the config file in the ccd dir

./build-key-pkcs12 user1@domain.com
echo "ifconfig-push" > /etc/openvpn/ccd/client_server/user1@domain.com

The IP address MUST be suitable for a /30 subnet (see http://www.subnet-calculator.com/cidr.php), as there is only 2 addresses available (server and client) per connection. So your next available client IP would be and so on.

Then you now have static IPs per connecting user.

Then supply the user1@domain.com.p12 file to the end-user and use the following config file

dev tun
proto udp
pkcs12 user1@domain.com.p12
resolv-retry infinite
ns-cert-type server
verb 3
reneg-sec 0
  • 1
    Well, yes, this could work, but I don't have the required access on the Linux box to install stuff :( Still, I find the whole thing extremely frustrating, because it works in one direction and it fails in the opposite one. Jul 18, 2012 at 20:58

If you are running the ssh session within the user account (using program such as putty.exe), when you try to login via rdp, it will disrupt that connection causing the rdp session to break. What you need to do is run the ssh tunnel as a service which won't be interrupted.

  • 1
    Interesting. I don't have access to that setup any more, so I won't be able to test your theory, but it would be nice to get some extra details about this for other people who are facing the same issue. Do you have some reference for your claims? What do you mean by the connection being disrupted by Putty? Mar 24, 2015 at 14:13

i think you can do all of the conf from your laptop

setup a putty connection to the linux box on your laptop. then in 'connection'>'SSH'>'tunnels' put 60666 in the 'source port' field and make sure the Local radio button is selected. in the 'destination' you enter win7-box-name-or-ip:3389.

save all that and it should allow you to open a putty session to linux-box which automatically creates a tunnel forwarding traffic to localhost(your laptop):60666 to win7:3389

if you are doing this on the command line it should be something like

ssh -L60666:win7:3389 linux-box
  • 1
    So, let's see... This configuration should forward port 3389 from the PC to port 60666 on the laptop. I don't see how this will work, though, and, in any case, it won't allow me to do remote desktop on the laptop... As far as I can't tell, it needs to be done using 2 tunnels. Jul 11, 2012 at 23:44
  • with this conf, you can't rdp to localhost:60666 on your laptop ?
    – jwinders
    Jul 12, 2012 at 14:45
  • No, it does not work. Jul 12, 2012 at 14:52
  • 1
    That doesn't work. The only way I am able to do that is to first establish a tunnel from the linux box to the PC ssh 3389:localhost:3389 'domain\user'@PC and then do telnet localhost 3389 on the Linux box. Jul 13, 2012 at 13:14
  • 1
    That's an interesting point, but I'm not sure I understand what is blocking it. The Windows Firewall has a rule which explicitly allows all connections on port 3389 from the domain. Jul 13, 2012 at 13:50

I found that unless all users were completely logged out of the machine I would get a blank screen after entering credentials. So, make sure you always Log Off.

  • 2
    Nice try, but still no luck :( Oct 10, 2012 at 22:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.