Skip to content

Using an outgoing SSH tunnel from behind a NAT for incoming VNC

Laurelin is working as an Au Pair for a Greek family in—where else than Greece. Her hostess has arranged for an Internet connection through Vivodi Telecom to allow Laurelin to maintain some form of contact with her friends and family at home.

Once connected, Laurelin quickly installed the Azureus BitTorrent client to be able to download some things (only legal things licensed under a liberal license, of course). Correct usage of the BitTorrent protocol implies opening up a port or two for incoming connections. After all, BitTorrent is all about sharing.

So, she needed help configuring port forwarding on the ADSL modem / NAT router (a microcom AD 2636) in Greece. She asked for this help two days ago while Wiebe was looking at my screen, because we where doing an extreme programming session on a database schema using VNC and Skype. We interrupted our work hoping that we could easily solve her problem.

I had been looking at screenshots and manuals of her router and her modem’s administrative interface earlier when they couldn’t get the connection to work. After making sure that the problem was not a configuration or software problem and identifying that there was probably a problem between their modem and their telephone exchange, they later got their problem fixed. So, now I had to dig up the manual again. But, this time I could only find some screencaps which accompanied a useless tutorial in Greek. This exemplifies why I think it is useful to keep a blog.

So, Wiebe and I did our best to guide her through a GUI we couldn’t see and eventually she succeeded in defining a few forwards. However, they didn’t do their job. According to nmap they were still filtered. She then installed RealVNC server for us and added port 5900 to the list of forwarded ports. Wiebe tried to connect using the kvnc client, but no response. By that time, we had fooled around quite a bit and after mucking about a little more, we decided to postpone the rest and return to our database design. We decided for next time to let her use PuTTY to put a hole through the NAT router.

Today was the next time. She installed PuTTY. I gave her an account on the Debian server in our local LAN (I am behind a Windows terminal myself). Now she had to set up a tunnel and connect to that account:

Configuring a remote tunnel for VNC in PuTTY

At this point, I still couldn’t access the tunnel between her box and the Debian machine from my Windows terminal:

$ netstat -l -n|grep 5900
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:5900          0.0.0.0:*               LISTEN

Since PuTTY was configured to let remote ports accept connections from other hosts, the problem had to be in the OpenSSH configuration on the Debian box. And indeed it was. I had to set the following option:

GatewayPorts yes

After a restart of the OpenSSH daemon, she opened a tunnel which I could access from my own machine:

$ netstat -l -n|grep 5900
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN

I could now control her desktop through the RealVNC viewer. Next time, I’ll need to actually do something with this connection.


No Comments ( Add comment / trackback )

Post a comment

(required)
(required)

Your email is never published nor shared.

(optional)
Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>