2

On my local network, I can VNC-over-an-ssh-tunnel quite easily. I wish to do the same from abroad.

The server is set up to accept WAN-side ssh connections, and this works reliably. The problem is, when abroad I cannot start a successful VNC session over the ssh tunnel. A similar tunneling setup is used when I do the same on my LAN (which works perfect).

So "from over there," I can connect SSH, but when I try to connect VNC to 127.0.0.1, I get on UltraVNC: Connection failed - End of stream Possible causes - Another user is already listening on this ID - Bad connection ...with whatever ports I may use.

Luckily TightVNC provides some level of logging. A failed connection is recorded as such:

[  512/ 1904] 2015-03-22 10:33:34:617 : Initialization of socket stream and input/output gates...
[  512/ 1904] 2015-03-22 10:33:34:617 : Connection is established
[  512/ 1904] 2015-03-22 10:33:34:617 - Protocol stage is "Handshake".
[  512/ 1904] 2015-03-22 10:33:34:647 - onDisconnect: Connection has been gracefully closed
[  512/ 2060] 2015-03-22 10:33:35:719 - Process focus restoration in the RfbKeySym class
[  512/ 2060] 2015-03-22 10:33:35:719 - Process focus loss in the RfbKeySym class
[  512/ 2060] 2015-03-22 10:33:35:829 - Process focus restoration in the RfbKeySym class

And a successful one looks like this (from my LAN):

[ 7536/ 2900] 2015-03-22 11:22:28:892 : Initialization of socket stream and input/output gates...
[ 7536/ 2900] 2015-03-22 11:22:28:892 : Connection is established
[ 7536/ 2900] 2015-03-22 11:22:28:892 - Protocol stage is "Handshake".
[ 7536/ 8032] 2015-03-22 11:22:28:946   client rect: 0, 0; 124, 31
[ 7536/ 8032] 2015-03-22 11:22:28:946   Desktop-window. (x, y): (0, 29); (w, h): (124, 2)
[ 7536/ 2900] 2015-03-22 11:22:29:040 - Server sent protocol version: RFB 003.008
[ 7536/ 2900] 2015-03-22 11:22:29:040 - Send to server protocol version: RFB 003.008

After weeks of hair-pulling, different client attempts and trying whichever port-forwarding configuration I could think of (on either side's routers), I finally made a breakthrough.

I set up a second ssh tunnel in PuTTY - Dynamic at port 1080 (D1080). I then used a VNC client that allows a proxy connection, RealVNC VNC-Viewer, and pointed it at localhost port 1080 (type SOCKS 5).

THIS. WORKS. I am now sure my VNC session is secured, but only if I go through a local SOCKS proxy when I am abroad. The down side is I can not use my favorite client UltraVNC Viewer.

Also, I do not understand what is going on; I am looking for an explanation. Why doesn't the simple L5900 tunnel do the job from then WAN, when it does within the LAN?

  • Same issue, did you find a solution? – JaredBroad May 6 '15 at 2:40
  • No, I have not - I still have the issue. I did spend some more time on this and have confirmed this is not related to a "live Google Remote Desktop link" issue as the problem repeated consistently when I tried to connect directly back home, being physically at the remote location. I do not have this issue if I carry my laptop over (I can VNC just fine on that ISP), it's only from that home's computer that this happens. – Tfb9 May 6 '15 at 2:48
  • I think if its only a localhost connection which is failing there is a setting in your VNC program somewhere "Allow loopbacks" which means allow connections from localhost. – JaredBroad May 6 '15 at 20:39
  • With the same VNC client settings, I can have a successful VNC session if I use [remote IP] rather than 127.0.0.1 (in extenso not tunneled through ssh). Naturally I also had to unblock port 5900 within my home's NAT firewall. - Why can I not VNC -over-ssh??! – Tfb9 May 26 '15 at 22:21
  • I also must correct myself from an earlier comment: I do have the issue of not being able to VNC-over-ssh with my personal laptop carried over at the remote IP's location. ...and the same setup does behave just fine at home; can VNC-over-ssh within the LAN. – Tfb9 May 26 '15 at 22:34
1

The problem here is the SSH tunnel setup in PuTTY.

Based on a web tutorial, I set up my 5900 SHH tunnel with the LAN IP adress of the server 192.168.1.110, so it looked like L5900 192.168.1.110:5900 in PuTTY. Target host was also 192.168.1.110. As we know this worked fine.

Then I configured my SSH session with PuTTY for use abroad. Shame on me, I used the WAN IP in both the target host and the tunnel. I now realize that when it received packets destined to port 5900, the OpenSSH server did as instructed - it forwarded them to my NAT router (or tried to, anyway, as the pointer was to a WAN address).

The sure way to configure PuTTY is to always use the LAN IP for the 5900 tunnel. Better yet, as in my case the VNC server is on the same machine as the OpenSSH server, just use localhost for the tunnel, as in L5900 localhost:5900.

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.