These notes are to help you with two common scenarios.
You are away from the office, but have been provided some sort of internet access either to your own laptop or a provided PC?LinuX/UNIX system and you need to get work done on your office systems or elsewhere. You are outside your home firewall and possibly inside some other alien firewall.
You need to get work done behind an uncooperative foreign firewall at some collaborator's site.
The first step is to get your local network access working. This might involve configuring dialup, Wireless LAN, IRDA or Bluetooth (for GSM phones) access. Hopefully the instructions with your hardware will do the job; remember that many laptops come with IRDA turned off in the BIOS.
Next, make sure that you are getting efficient access to your alien network. You need to ensure that you are using a local DNS server; check by doing an nslookup of a well-known site and seeing which DNS server gets used. It should not be the one from back home. If it is, you need to go into Control Panel->Network Connections->(your connection)-> Properties->Internet Protocol (TCP/IP)->Properties->General and check Obtain DNS server address automatically.
You should also ensure Internet Explorer is working efficiently. You do not want to be using the cache from back home, so go into Tools->Internet Options...->Connections->LAN settings (if appropriate) and clear any Proxy server or Use automatic configuration script settings.
Your ideal next step is to create a VPN (Virtual Private Network) connection back to your home systems. On Windows XP, all you have to do is go into Control Panel->Connect to network at my workplace->Virtual Private Networking Connection->Enter your network name->Select Do not dial the initial connection->Enter your VPN host name, and finish. ECS users can look up the network name and host name at https://domain.ecs.soton.ac.uk/vpn.
Finally, to improve performance by ensuring that other connections are not unnecessarily routed via your home network, you should right click on the Icon for the new VPN connection and select Properties->Networking->Internet protocol->Advanced->Clear the Use default gateway on remote network check box.
Everything should now work as if you are on your home network. You can mount drives, open Terminal Services, VNC or X connections and do what you want. My personal choice is to run Terminal Services to Windows boxes, for its functionality, and VNC to Linux/UNIX for it's relatively fast loading and because it does not depend on the X configuration at your local PC. Both Terminal Services and VNC connections are persistent, so you should be able to resume your work if the network temporarily drops out, as in common on Wireless LAN or GSM.
Checking your Windows LAN connection.
A telnet client is built into Windows (you have to run it from the command line) and UNIX/Linux; you might be happy with it's poor security if you are running through a VPN. Otherwise, you can use OpenSSH which should already be on your Linux system and can be found as part of the Cygwin distribution for Windows. There are also several GUI Windows ssh clients; probably the best is the non-commercial version from SSH Communications Security. There is a client in Java, Mindterm, from appgate: various early versions were under GPL or other open source license.
The machine you are using may not be able to run as a VPN
client. You will have little choice other than to tunnel everything through
openssh. First, check if the ssh client exists on your machine. If not,
you will have to download and build OpenSSH
or use the Mindterm Java client. You can just
use the ssh client to give you a login session on an appropriate system:
ssh -l dan
login.ecs.soton.ac.uk
If you want something more exotic, you will need to tunnel other protocols
through ssh. X is easy, just add the -X flag to your ssh
session. For more exotic protocols, see Tunnelling using
ssh, below.
Here, you probably will not have the option of using a VPN, so you will have to use ssh as described below. You might find you have to log into a sentinel machine, and then use ssh port-forwarding to the actual machine you need. Note that some really hostile sites disable port forwarding either in the ssh demon itself or in an intermediate firewall between the sentinel and the other machines. You might be able to get around this by opening a second ssh session from the sentinel.
X is normally part of the standard configuration of Linux/UNIX
systems. For PC's you can buy Hummingbird
Exceed, run the Cygwin
version of Xfree86 or, as a lightweight alternative, use the
WeirdX X server written in
Java. If you are using a VPN, you can just set the DISPLAY environment
variable on the remote machine to point to your local machine:
export
DISPLAY=mimachine.mynet:0
This normally runs through TCP port 3389. If you are accessing a Windows 2k/XP box via a VPN or without any firewall or net security concerns, it all just works out of the box. Otherwise, these notes may help.
You can change the port assignment for the client and server built into Windows XP and .NET. Actually, you simply have to add :port-n after the hostname in the client, as in dan.ecs.soton.ac.uk:3390. There is another important trick for this client. The terminal services client in Windows XP will not connect to localhost, so it is difficult to use it for port forwarding. It turns out that this restriction is removed (I know not why) if you run the client in Windows 98 compatibility mode. You do this by copying mstsc.exe and mstscax.dll from c:\windows\system32 to a new directory. Then right-click on mstsc.exe, click on the Compatibility tab, and check Run this program in compatibility mode for. Choose Windows 98/WindowsME. Close the dialog and run this copy of mstsc.exe.
The terminal services client active X control, will happily connect to localhost without any problem. It is, however, not possible to change the port assignment, so you have to forward the default RDP port, 3389. This in turn means that you must not be running a terminal services server on your local host. The active X control can be downloaded and run from any web server, all you need is the mstscax.cab file and a simple web page like this one.
There are open source terminal services clients for X and VNC. The X one allows you to view a terminal services session on a UNIX/Linux box or to use a UNIX box as a gateway translating terminal services into X. The VNC client will act as a gateway translating terminal services to VNC which can then be forwarded to a remote user. This client also has better support for non-US keyboards. By default, you can only connect to the default port 3389, but it's not difficult to recompile with a port option.
VNC provides clients and servers for Windows, Linux and UNIX. There are also Apple Mac versions. VNC server number n accepts connections through port 5900+n. A VNC link typically works much better than X over a low bandwidth connection. There is one important gotcha. If you run the VNC server under Windows XP, you must go into Control Panel->User Accounts->Change the way users log on and off and clear Use Fast User Switching. You must do this at the server console; you cannot do it over an RDP connection. Again. apart from this fix, it should run out-of-the-box.
There are two reasons to tunnel other interactive protocols through ssh:
Because a firewall (at either end of the connection) prevents the service you need from working.
Because you don't trust the security of the network between you and the service.
For most jobs, it is much simpler to use a virtual private network (VPN); I'd only use ssh if, for some reason, I could not use a VPN.
For most cases, you use the switch -L lport:host:rport
on you ssh command line.
Here lport is the local port (the number that goes after localhost in the
client software) and you can choose any number that does not clash with other
services. host is the name of the remote host relative to the machine at
the far end of the ssh connection. Unless you are doing something complicated,
this will be
localhost. Finally, rport is the magic port number, listed in
these notes, for the remote service you want to use. So, to tunnel VNC to my
Department login server, I might type something like:
ssh -l dan -L 5900:localhost:5900
and run the vncserver through the remote login connection:
vncserver :0
Finally, I run the VNC client locally, connecting to localhost:0.
If you are using a GUI ssh client, you need to enable local port forwarding through the GUI. For example, in SSH Secure Shell 3.0.0, you go to Edit->Settings->Tunnelling->Outgoing->Add...
Use the -X switch. Everything just works. This is a rather more complex process than the simple port forwarding used for VNC or Terminal services, but ssh implements all of it, including xauth.
Use the switch -L 5900:localhost:5900 to cause a local client connecting to localhost:0 to be forwarded to :0 on the remote host.
Forwarding the ports is straightforward; the port number is
(by default) 80 for HTTP and 443 for HTTPS. If there is a :number after
the host name, such as :8080, then that's the port to use with the
-L switch. Unfortunately, you cannot then just invoke Mozilla or IE using
http://localhost, because the host name gets sent inside the HTTP(S)
traffic and most real servers will not respond as localhost. The way
around this is to configure LMHOSTS and enter translations for the hosts you
want to use to IP address 127.0.0.1. For example, to get to
https://zam574.zam.kfa-juelich.de/bscw, I might invoke ssh using:
-L 443:zam574.zam.kfa-juelich.de:443, insert an entry in my %SystemRoot%\System32\Drivers\Etc\LMHOSTS
file looking like
127.0.0.1
zam574.zam.kfa-juelich.de
and enable LMHOSTS lookup in
Control Panel->Network Connections->(appropriate connection)->Properties->Internet
Protocol (TCP/IP)->Properties->Advanced...->WINS->Enable
LMHOSTS lookup.
Now you should be able to connect to
https://zam574.zam.kfa-juelich.de/bscw tunnelled through the ssh
connection.
Yes, you're right; this is a horrid hack, only to be used as a last resort to achieve privacy from an untrusted site or to fight your way into an uncooperative intranet.
For difficult cases, you can probably do what you want using Netcat, which will turn stdin/out into a TCP or UDP active or passive port. This is just what you need when, for example, your remote sshd refuses to forward off the machine:
Screen from Jüren Weiggert is really useful under UNIX. It allows you to maintain multiple VT100-type sessions through a single remote login. It is especially helpful that the sessions are persistent and can be reconnected if your login connection drops out. Just run screen to start it, and screen -d -r to reconnect a dropped session. Sources. You might also wish to read this article.
The other thing you might need is a port forwarder. This accepts a connection on one port and sends it out to another. You can try FastForward (local copy) or Simpleproxy (local copy).
| dan@ecs.soton.ac.uk |