Virtual Private Networking

Executive Overview

The physical characteristcis of a Local Area Network (LAN) allows for certain assumptions of data security. These assumptions then allow for certain privleges among machines sharing a LAN. The purpose of a Virtual Private Network (VPN) is to re-establish these assumptions when machines are not sharing a LAN, but are separated by an unsecured public channel, e.g. the Internet. Creating a VPN between you home computer network, or your traveling laptop, with the department's VPN server will give you LAN-like access to departmental resources.
Security as at least these three elements:
1. Authenticity: assurance is given as to the source and destination of the data.
2. Privacy: the data cannot be understood by other than the authentic source and destination of the data.
3. Integrity: the data cannot be modified by other than the source and destination.
Methods of VPN
We have implemented several free VPN's, called Ad Hoc VPN's, since they are administratively light-weight. We give details for the following methonds:
1. VPN using SSH and Port Forwarding.
2. VPN using PPP over an SSH Tunnel.

SSH and Port Forwarding

Overview
The simplest method uses the capabilities of SSH to channel service ports across the Internet inside of an SSH session. Although it has limitations, it requires no administrative setup (almost), and has worked reliably. While the tunnel is in place, your remaining Internet connectivity is unaffected. Here is a picture:
```
   imap client --->| localhost:143         |---> imap server (imap-server:143)
                  /                         \
                 /                           \
   ssh client   +====>==================>=====+  ssh server (ssh-server:22)
                 \                           /
                  \                         /
   smtp client --->| localhost:25          |---> smtp server (mail-server:25)
```
In this example, two ports have been forwarded: imap and smtp. This will allow you to send and receive mail securely. The required .ssh/config file is:
```
   Host tunnels
      HostName ssh-server.cs.miami.edu
      User burt
      LocalForward 143 imap-server:143
      LocalForward 25  mail-server:25
```
The VPN is established by the command ssh tunnels and logging into the ssh-server. (But see Privleged Ports, below.) The VPN is used by configuring your mail client to use localhost as your imap and mail (or smtp) server.
Note: to forward POP, use LocalForward 110 pop-server:110
Port forwarding
SSH consults its configuration file for options such as local forward directives. A local forward directive specifies three things:
1. a local port number;
2. a remote host name;
3. a port number on the remote host.
SSH opens its usual connection to the machine given by the host name directive and, for each local forward, starts a local listener on the the given local port. The listener will forward all traffic to and from the local port through the ssh channel to the other ssh endpoint. There, ssh will forward the traffic to the named remote host at the specified remote port.
Other ports can be forward, for instance, to access the internal departmental web server, to browse the web in proxy through a departmental server, to forward X11 windows, and to mount SMB (Microsoft Networking or Samba) filesystems. These are described separately below.
Privileged Ports
All ports below 1024 are privileged for Unixoid Operating systems. Not so with Microsoft. This makes ssh tunneling a bit more involved on Unixoids than Microsoft. For Unixoids, ssh must be run as root in order that it binds to (listens to) ports 143, 25 and 80. For a single user machine, the simplest thing to do is use sudo to run ssh, in which case you need to take care to use the correct configuration file:
```
   burt@myComputer> sudo ssh -l burt -i./.ssh/id_rsa -F./.ssh/config
```
For Linux, which does not have sudo natively, you must su to root.
For Microsoft, just run ssh.
Web Proxy
Sherman supports web proxy. If you set your proxy server to localhost:80, and an HTTP tunnel is open, as described above, you should be able to surf the web as if you were coming from a departmental machine. This useful to access journals from off-campus.
Forwarding X11
For X11, the proxy is in the reverse direction. An X11 server supports multiple displays, each with multiple screens. An X client indicates which machine, display and screen by the environment variable DISPLAY. For instance:
```
   DISPLAY=192.31.89.33:14
```
This means that the X server at 192.31.89.33 is listening on port 6014 for client requests. Rather than X, SSH listens at this port and "reverse forwards" this information back through the ssh channel to the local machine. Here it is sent to the port of the local X server (port 6000 for display 0). SSH is nice enough to set DISPLAY correctly on the remote machine according to the port it found open above 6000 for listening.
Tools
Get SSH. Aidi and I are working on a cross-platform "wizard" to make this easy.

PPP Tunneling (w/ ssh)

Joe Clarke, from Cisco Systems, and a UM alumnus, suggests another method. Another method, with several advantages is to use PPP to create interface endpoints named /dev/tun at either end of the VPN channel. An ssh session connects them. A combination of routing and NAT'ing is required to complete the connection.

PPP setup.

Call the server S and the client C. The client is attached to the internet via some provider and might have some local address, say 192.168.1.2. The server might be sherman, with address 172.20.0.2.

On S, the /etc/ppp/ppp.conf reads

    vpnserver:
       set timeout 0
       set log phase lcp ipcp command
       allow mode direct
       set ifaddr 10.0.0.2 10.0.0.1 255.255.255.255
       allow users burt
       disable dns
       accept dns
       set dns 172.20.0.2

Actually, we haven't gotten the dns to work well, but that might be due to OS X.

On P, here is /etc/ppp/options:

pty "/usr/bin/ssh -l burt 192.31.89.2 -e none -q -t -t /usr/sbin/ppp -direct vpnserver"
local 
10.0.0.1:10.0.0.2
noauth
nodefaultroute
usepeerdns

The pty command pipes the tun device on C into an ssh session. On start of session, ssh will execute /usr/sbin/ppp and pipe through it. The other end is connected to the tun device on S. Public-key authentication is required for this to work, as you will have no opportunity to respond to any command prompt from ssh. We had to suid root pppd for this to work (in order to create a device?).

In this configuration, the C:tun is address 10.0.0.2, and S:tun is address 10.0.0.1. (check this) Now trafic for the 172/8 net should be directed towards the tun device:

route add -net 172.0.0.0 10.0.0.2

Now ping 172.20.0.1 should work.

The advantage of this method is that any port on 172.20.0.2 is available. However, unless NAT is used somewhere, or default routes to 10.0.0.2/32 are installed in various places, the rest of 172/8 is still unavailable.

Joe has gotten much farther along on this then this notes describe. Come back for more information.

History

Burton Rosenberg, 30 July 2002
Upate: 6 August