4. Amrita VPN Configuration - Essential Features

Follow these steps to quickly start up AmritaVPN once you have run make install. You need to do two things now:

• Edit /etc/amvpn.conf (If you've installed this in an alternate location use that).
• Run amvpn-keytool to generate keys/certificates.

Note:

One running amvpn instance can only handle one point-to-point VPN connection with another machine. One amvpn process cannot establish multiple point-to-point connections. If you need multiple VPN connections from your machine simply run multiple instances of amvpn with different amvpn.conf files. A different amvpn.conf file from the default can be specified using the -c or --config-file command-line parameter. For instance: amvpn -c /etc/amvpn_xyz.conf. See Running multiple instances section for more details.

Note:

All configuration parameters can be specified in either short (eg: -c) or long form (eg: --config-file) in the command line. Also, all configuration parameters except config-file and daemon-mode can be specified in the configuration file. In the configuration file, the long name of the configuration is used without the preceding hyphens (--). One configuration option is specified per line in the config file. Eg: The line: 'log-level verbose' in the config file is equivalent to the command line '--log-level verbose' or its short command line form: '-l verbose'.

4.1 Configuring amvpn.conf

Following are changes required in amvpn.conf

• Set tunnel-ip to an IP address in the private IP range. The n/w portion of tunnel-ip must be same and the host portion must be unique for each machine in the VPN. For example one machine can have tunnel-ip set to 192.168.16.1 and the other machine can have tunnel-ip as 192.168.16.2.
• Set server-ip: If you want to connect two machines through Internet using VPN (usually these machines would be acting as routers for internal networks) then one machine must act as the server and the other machine as the client. Your machine acts as the client if in amvpn.conf 'server-ip' parameter is set, and as the server if 'server-ip' is not set. Note that in one of the machines server-ip must not be set for it to act as the server. server-ip must be the public IP address or the domain name of the other machine.

4.2 Running amvpn-keytool

amvpn-keytool can be used to:

• Generate VPN CA (Certificate Authority) key/certificate. Only one machine must do this.
• Generate VPN key/cert - for all the machines involved.
• Securing VPN key/cert directory with appropriate privileges that AmritaVPN can read key/cert files at run time, but nobody else except 'root' can.

Let's say you have two machines M1 and M2 and you want M1 to act as VPN CA. Then you need to do:

[Note: CSR stands for Certificate Signing Request.]

Important Note:

Make sure that system time in the machine acting as the CA does not exceed system time in the client machines which will use the CA key and CA cert. Otherwise SSL authentication would fail till the system time in the client machines reach the timestamp present in the notBefore field of the CA certificate.

In M1:

1. amvpn-keytool genca - generate CA key/cert
2. amvpn-keytool genkey - VPN key/CSR for M1
3. amvpn-keytool gencert - VPN cert for M1 signed by CA

In M2:

1. amvpn-keytool genkey - VPN key/CSR for M2
2. To generate VPN cert for M2 there are two methods:
   • From M2 run: amvpn-keytool -r root@M1:/usr/share/amvpn -c gencert. The -c option means that we're running amvpn-keytool from the client machine, hence the -r option contains path of the CA machine. When running from client machine the generated certificate is automatically checked for clock skews.
   • From M1 run: amvpn-keytool -r root@M2:/usr/share/amvpn gencert. Since -c option is absent, by default, amvpn-keytool assumes that it is being run from the CA machine, hence the -r option contains path of the client machine. When running from CA machine the generated certificate has to be manually checked for clock skews by running: ampvpn-keytool validate in the client machine.

Now in both M1 and M2 run:

amvpn-keytool secure amvpn

Note:

In genkey and genca steps you'll be prompted to enter information used to distinguish the certificate (this information is kept in CSR and is used when generating certificate). At least the common-name must be different for each certificate (including CA cert) - otherwise SSL authentication would fail.

Note:

Do not enter any value for the challenge password, if prompted during the genkey/genca steps. If challenge password is given AmritaVPN may not be able to read the key information at run time.

4.3 Connecting through proxy

The amvpn client can connect to amvpn server through a proxy. This option may be required if the amvpn server is sitting behind a firewall. AmritaVPN currently supports proxy authentication using Basic HTTP authentication.

The following options need to be set at the client side for connecting through proxy:

• proxy - IP address or domain name of the proxy.
• proxy-port - Proxy TCP port to use. Default value of 3128 is used if not specified.
• proxy-user - If the proxy is configured for 'Basic' authentication then a valid user name must be provided in this option.
• proxy-password - Password for the proxy-user. Note that the user name and password is transmitted in plain text (base64 encoded but without encryption) in HTTP Basic authentication.

The HTTP CONNECT method is used for connecting through proxy server.

4.4 Automatic Reconnecting

The amvpn client will automatically reconnect to the server if the connection fails because of network reasons. Reconnect will not occur if the connection fails because of Certificate authentication failure.

By default amvpn client will attempt to reconnect indefinitely with a delay of 30 seconds between each reconnect attempt. These defaults can be changed using the following options:

• reconnect-attempts - Number of times client must attempt to reconnect to server on a connection failure. A negative value implies infinite number of times, which is the default.
• reconnect-delay - Delay between each reconnect attempt in seconds (default: 30).

If domain name of the server is specified in the server-ip configuration option (instead of its public IP address), at each reconnect the amvpn client will freshly look up the server's IP address through a DNS query.

4.5 Connecting two remote Microsoft/Samba networks

AmritaVPN can be used to connect two remote Microsoft/Samba networks together over Internet. This can be easily achieved by setting a few configuration parameters in the amvpn.conf file.

Note:

For this feature to work Microsoft network must be configured to work over TCP/IP. This is normally the case with Microsoft network configuration.

To connect your local and remote MS/Samba networks provide the following configuration options in amvpn.conf file:

• local-net - The local network's IP address (obtained by setting host portion of the IP address to all zeroes). Eg: local-net 192.168.5.0.
• local-mask - The subnet mask of the local network. Eg: local-mask 255.255.255.0
• remote-net - The remote network's IP address. Eg: remote-net 192.168.4.0.
  • Important Note: You must also have a corresponding route-ip and route-mask entries for the remote network since the Microsoft Networking protocols generate TCP/IP traffic that will be routed only if the route-ip and route-mask entries are present. If route-ip and route-mask entries are not present for the remote network then proper connectivity won't happen. See Routing via VPN section on more details on routing.
• remote-mask - The remote network's subnet mask. Eg: remote-mask 255.255.255.0.
• route-smb - After properly setting the above configuration options, set this option to yes to activate the feature. Eg: route-smb yes.

The local-net, local-mask, remote-net, and remote-mask values are internally used by AmritaVPN to route broadcast messages generated by Microsoft Networking protocol, transparently to the remote network.

The broadcast messages will not be routed over multiple VPN hops. As an example, let us assume we have three networks 192.168.0.0, 192.168.1.0, and 192.168.2.0. We have connected 192.168.0.0 with 192.168.1.0 through amvpn. Then we've linked 192.168.1.0 with 192.168.2.0, also through amvpn. The broadcast messages coming from 192.168.0.0 network to 192.168.1.0 network, will not be taken by amvpn and routed to 192.168.2.0. This feature has been put in place to avoid broadcast loops.

In the previous example, if 192.168.2.0 network was, in turn, connected to 192.168.0.0 network, directly or indirectly, without this feature we would have broadcast loops. In other words, packets generated 192.168.0.0 will be transmitted to 192.168.1.0, which, in turn, will be transmitted to 192.168.2.0, and then back to 192.168.0.0. This cycle would repeat. By setting Time-To-Live (TTL) in the IP Packet (based on a configuration parameter) to a cut-off value we could solve this, but we feel that improper setting of TTL would create havoc. So we decided to have a limitation rather than have a potential problem for all our users.

In this example we can have a VPN link between 192.168.0.0 and 192.168.2.0 networks to overcome this limitation.