IMSc Virtual Private Network

A Virtual Private Network or VPN allows users across the internet to pretend that they are all part of a small (and private) local area network.

There are two situations for which we currently have a VPN in IMSc:

This document explains IMSc's virtual private network from the point of view of the user and the system administrator. It provides the justification for its deployment, and explains its installation, use and maintenance.

Note: This document should be considered a perpetual work-in-progress so feedback in the form of editing or e-mail response to one of authors is always appreciated.

1. IMSc VPN for Users

The reasons for requiring VPN authentication are explained in the chapter for System Administrators.

For a quick start, a user is encouraged to read section "Do you need to VPN?" below to decide whether to configure her/his laptop for VPN access and which kind of VPN --- ssh or openvpn --- is desired. The appropriate section can then be followed in order to setup this access. Finally, a quick glance through the sections on "Tips and Tricks" and the "Comments" at the end is recommended.

1.1. Do you need to VPN?

If you only access the IMSc network to read publicly accessible web pages and use e-mail services, then you probably do not need to VPN.

Here are some reasons why you may wish to set up VPN access to the IMSc network:

In any case, please note that IMSc VPN access will only be granted to users who are long-term on-Campus users of the IMSc network.

There are two forms of VPN available to IMSc users. Both methods require the user to generate an RSA (or DSA) key pair. The Open VPN method requires a little more configuration but is probably easier to use in the long run. The secure shell method requires less effort to set up but is more cumbersome if you need to use it extensively on a daily basis. Both methods are based on NetworkTunnels but there are differences.

1.2. Generating your Key pair

Install openssh if your system doesn't already have it.

The commands below are to generate an RSA key. You can also generate a DSA key by replacing rsa everywhere below by dsa.

Run the command

        ssh-keygen -t rsa

You should put a non-trivial passphrase when you are prompted for one.

This will produce two files:

If you happen to delete or lose your public key file it can be regenerated with the command

        ssh-keygen -f $HOME/.ssh/id_rsa -y > $HOME/.ssh/id_rsa.pub

If you happen to delete or lose your private key file or forget the passphrase with which you encrypted it, then you must delete both files and start again :-( .

If you want to use the key for openvpn then follow the instructions given below. Otherwise, jump to the instructions for secure shell tunnels.

1.3. OpenVPN

These steps need to be carried out only once for each computer which needs to use the VPN.

The steps are as follows:

  1. Create an Openssh public key if you have not already created one.

  2. Request the OpenVPN CA to sign your key if you do not already have a certificate for your key.

  3. Wait for a responding e-mail from the certifying authority.

  4. Install the files in exactly the locations suggested in the e-mail. (Or do it your own way if you feel you can solve any problems that may arise!)

  5. Download, install the programs.

The last sub-section below also contains the instructions to run the programs.

1.3.1. Certificate Signing Request from OpenSSH private Key

If you have an RSA private key for openssh then it is a 2048-bit SSL private key as well. You can create a certificate signing request for it with the following command (where we assume that $HOME/.ssh/id_rsa is your private key):

        openssl req -new -extensions v3_req \
         -key $HOME/.ssh/id_rsa -out $HOME/.ssh/id_rsa.csr

Answer the prompts accurately as the entered information will be used to decide whether the certificate should be issued or not! In particular, make sure you enter your full name and proper e-mail address. Some systems will ask for a challenge password. We do not use a challenge password at the moment so you can just press enter.

This will create the file $HOME/.ssh/id_rsa.csr which you should mail to the Certifying Authority (currently sysadmin for this VPN).

If you have a DSA key at $HOME/.ssh/id_dsa then you run the alternate command

        openssl req -new -extensions v3_req \
         -key $HOME/.ssh/id_dsa -out $HOME/.ssh/id_dsa.csr

The rest of the instructions are as above.

1.3.2. Installing the Openvpn configuration files

The configuration files for openvpn are:

  1. The files <vpn name>.conf where <vpn name> is either imsc_lan or imsc_wan in our context. These file contain the names of the other files.

  2. The Certifying Authorities certificate imsc_openvpn_ca.crt

  3. Your certificate signed by the CA client.crt

  4. Your private SSL key client.key

The four files imsc_lan.conf, imsc_wan.conf, imsc_openvpn_ca.crt and client.crt will be e-mailed to you by the Openvpn Certifying Authority.

The last file client.key should never leave your machine! The client.key file is usually stored encrypted on the disk with a passphrase.

If you created the Certificate Signing Request using your SSH key as explained above then client.key is the same as your $HOME/.ssh/id_rsa or $HOME/.ssh/id_dsa key file. Copy or link it to the same directory as the other files.

However, it is better to put these files in their expected locations as shown below.

System

Directory

Remarks

GNU/Linux

$HOME/.ovpn/

Recommended location for IMSc use

Mac OS X

$HOME/Library/openvpn

MS Windows

\Program Files\OpenVPN\config

The file extension is .ovpn instead of .conf in this case

1.3.3. Downloading and installing Openvpn

The instructions depend on the type of computer (operating system) being used and assume that you have installed the files as explained in the previous section.

1.3.3.1. GNU/Linux (Debian or Ubuntu)

You need the package openvpn so you do

        sudo aptitude install openvpn

or possibly

        sudo apt-get install openvpn

This will install the package.

If you put the configuration files in $HOME/.ovpn as recommended then you can run the command

        sudo openvpn --cd $HOME/.ovpn --config imsc_lan.conf || echo FAILED

when you are inside IMSc.

If you are outside IMSc you run

        sudo openvpn --cd $HOME/.ovpn --config imsc_wan.conf || echo FAILED

to start the external tunnel. (Note the replacement of lan by wan.)

When you are finished with using the tunnel you should run

        sudo killall openvpn 

(There is also a clickable interface in a package called kvpn but you need to figure that out for yourself right now!)

1.3.3.2. Mac OS X

You need the package tunnelblick from the web-site http://tunnelblick.net/ . When you download the .zip file and open it it will yield an application that is represented by a "tunnel" icon. Drag that icon to the Applications folder.

Next you open the folder $HOME/Library/openvpn that contains your VPN configuration. There you click on (say) imsc_lan.conf. You will be asked which application will handle this file. You select TunnelBlick (you will need to first select All Applications instead of Recommended Applications in the selection bar). The tunnel icon will appear in your taskbar. From this icon you can select which tunnel you want to open or close

Note: If the clickable interface crashes on you you can still use the command like just like for GNU/Linux. For example,

        sudo openvpn --cd $HOME/Library/openvpn --config imsc_lan.conf

is the command for the LAN version.

1.3.3.3. Microsoft Windows

You need the package from the web-site http://openvpn.se/ . Download and follow through the Windows Installer. Select the default installation directory \Program Files\OpenVPN. After installation a little network icon will appear in your taskbar with reddish monitors. Right click on this to select the appropriate connection to open or close.

Note: During installation you will be prompted to allow the installation of the tun network driver. You should accept this installation as the tunnel will not function without it.

Note: The configuration files are named .ovpn and not .conf in this case.

1.4. Secure Shell Method

Your key pair is not of much use unless it can used :D . If you mail this key to the IMSc system administrators they will install it in your home directory on access.imsc.res.in. If you can already log in to access.imsc.res.in and wish to install a new or additional key you can run the command

        ssh-copy-id -i <public-key-file> access.imsc.res.in

where you must replace <public-key-file> with the path to the public-key part of your new or additional key pair.

To use the same key within the IMSc network, you can install this key to any IMSc machine with the command

        ssh-copy-id -i <public-key-file> <hostname>

where you must replace <hostname> with the name of the IMSc host where you want to install the key. (You need only install the key on one of the machines that has your NFS home directories.)

1.4.1. Making a Tunnel with Secure Shell

When a user is outside IMSc, one way to access IMSc machines is using Secure Shell (ssh) to log in to access.imsc.res.in using key-based login.

After logging in to access one can further log in to the IMSc network machines using ssh. You can also make IMAP connections to banyan. This multi-stage process is sometimes cumbersome. So we describe an alternate approach using SSH tunnels.

1.4.1.1. First example: Using IMAP directly

ssh -f -L 9143:banyan:143 access.imsc.res.in sleep 300

(Here 9143 is some arbitrary choice of number greater than 1024.) If you run the above command from any machine (say A) on the internet, then you can connect to port 9143 on machine A to use the IMAP service on access directly. For example, on machine A you can type

mutt -f imap://luser@localhost:9143/mailbox

This will access the folder mailbox of the luser via imap. (You will be prompted for the password of luser by mutt).

Note: The above tunnel will timeout in 5 minutes (=300 seconds). You may wish to increase the time if you need more time. However, for security reasons please ensure that the tunnel is closed (by killing the relevant process) as soon as you have finished using it. We monitor long running connections and will disable :( accounts which misuse this facility.

1.4.1.2. Second Example: Using SSH directly

ssh -f -N -L 2222:as96:22 access.imsc.res.in && TUNPID=$$

(Here 2222 is some arbitrary choice of number greater than 1024. For as96 you can replace any IMSc host.) If you run the above command on machine A then you can use an ssh connection to port 2222 on A to actually connect to as96. For example,

ssh -o HostKeyAlias=as96 -p 2222 localhost

will open a connection to as96. The HostKeyAlias is so that ssh is able to check in its database for the HostKey for the host as96. You can also add other ssh options to the command. For example

ssh -X -o HostKeyAlias=as96 -p 2222 localhost

can be used to forward X11 connections. This way you can run xterm or xpdf on the IMSc machine as96 and have the output show up on Machine A.

Note: Do not forget to kill the tunnel when you are done. By kill $TUNPID or killall ssh.

1.4.1.3. Third example: Combining the above two

ssh -f -L 1234:banyan:143 -L 3456:as96:22 -L 4567:as84:22 access.imsc.res.in

You can put any number of -L options in the command line. This will allow you to use the same tunnel to connect to multiple hosts. In fact the above command will log you in to access as well; this will mean that you will have to use the tunnels from some other window on your screen.

You can even add tunnels while you are logged in. Use the ~C escape sequence when you are in an ssh connection. This opens the command line for editing, so you can add some more -L port forwardings through the same ssh tunnel.

1.4.1.4. Advanced Example

Ultimately, even the above may not be enough for you. What you want is to set up your machine to connect to the IMSc LAN as if you are in IMSc. So you need to use ssh with the SOCKS protocol.

For this you need to be able to configure 'SOCKS' for your network applications on machine A. There are too many different ways to do this so we cannot specify them here. Add a comment at the bottom of this page if you have questions. The SOCKS tunnel is started with the command:

ssh -f -N -D 1111 access.imsc.res.in

(Here '1111' any number larger than 1024.) This will set up a SOCKS service with address 127.0.0.1:1111. If you configure your application to use this SOCKS service, then any network connection it opens will be opened as if the same connection was opened by you from access.

A number of applications like Mozilla, Firefox, and Thunderbird can be configured to use SOCKS tunnels.

Since openvpn is provided it may be easier to configure that as explained above. However, if you insist on using ssh there is a way.

1.5. Tips and Tricks

If you use the clickable interfaces, then you will probably be asked whether you want to save your passphrase --- think carefully about the implications before you accept.

When you use the imsc_wan VPN from the internet, the route for machines with addresses like 172.16.x.x will be through the VPN. To use names that are internal to the IMSc network you will need to all the following lines to your /etc/resolv.conf (or equivalent file for non-GNU/Linux machines)

        domain imsc.res.in
        search imsc.res.in
        nameserver 172.16.1.71

If you want journal access then you should enable the http proxy setting on your browser. Point it to 172.16.1.71 with port 3128.

Generally speaking you should only enable this VPN when you are actually using our network and turn it off otherwise.

If you are within IMSc and are using a machine that is not configured by our system administrators then you will only be able to use a (small) percentage of the available bandwidth unless you enable openvpn or use the SOCKS-based ssh tunnels.

If the imsc_wan configuration file does not work for you try the imsc_wan_tcp configuration file. The latter replaces UDP packets with TCP packets which helps with some situations (like using BSNL gateways).

2. IMSc VPN for System Administrators

Access to the IMSc network from the internet is restricted to authenticated users who have registered their public key on access.imsc.res.in. However, the IMSc currently has a permissive policy regarding the use of the link to our network and the internet from the IMSc campus.

Given the installation of a number of wired and wireless access points we need to restrict such unfettered access to computers that are authenticated in some way.

At the same time, to avoid inconvenience to our short-term visitors we need to continue to allow limited access to some internet facilities from unauthenticated external computers on the IMSc campus.

The IMSc VPN is one way to achieve these goals.

2.1. The VPN policy

A small number of network services provided by the IMSc computer network are meant to used by all people connecting to this network --- whether from within the IMSc campus or from outside. The remaining network services are intended to be used only by authenticated IMSc users.

The IMSc system administrators install some authentication mechanisms on each computer acting as a desktop, workstation or server in the IMSc network --- such computers can be considered internal and hence pre-authenticated.

All other computers must be considered external. In addition, all laptops must be considered external due to their portability. The IMSc VPN is the mechanism for such computers to make authenticated access to the full range of services provided by the IMSc network.

2.2. Certificate Management for OpenVPN

We describe a method for Certificate Management based on the software that came with openvpn. The software resides in /usr/share/doc/openvpn/examples/easy-rsa/2.0/. It is copied to a "permanent" location like /root/CA on a machine which has limited access. The file /root/CA/vars is then edited. The relevant entries are at the very end:

export KEY_COUNTRY=IN
export KEY_PROVINCE=Tamil-Nadu
export KEY_CITY=Chennai
export KEY_ORG="The Institute of Mathematical Sciences"
export KEY_OU="Computer Centre"
export KEY_CN="OpenVPN CA"
export KEY_EMAIL="sysadmin@imsc.res.in"

One then runs the commands

        cd /root/CA/
        . ./vars
        ./clean-all
        ./pkitool --interact --initca

This creates the private key without a passphrase! So we run

        openssl rsa -in keys/ca.key -out keys/enc_ca.key -aes128

to encrypt the private key. Choose a non-trivial passphrase and remember it! We then put the encrypted private key in place of the old key

        mv keys/enc_ca.key keys/ca.key

This sets up the Certifying authority.

2.3. Signing Keys

The generation of Certificate Signing Requests has been explained elsewhere. Assume that a .csr file has been received by mail. We save the .csr file with a name like keys/<hostname>.csr or keys/<username>.csr. To sign the key we run

        cd /root/CA/
        . ./vars
        ./pkitool --interact --sign <name>

(where we replace <name> with the name of the .csr file as we stored it). The program will prompt for the passphrase chosen earlier. After checking that the key has all the correct data one can approve the signature. The program will emit some error message about not being able to chmod the key file; this error can be ignored.

3. Comments and Questions


A short article on VPN installation can be found at http://www.debian-administration.org/articles/563

-- kapil 2007-11-23 11:17:12

You can add your comments and questions regarding the above write-up here. Please use the template so that your name and the time you make the change is recorded.


CategoryComputer

IMScWiki: IMScVPN (last edited 2010-04-01 21:34:56 by localhost)