System Catalog › Gateways › VPN - Virtual Private Networking Appliance

VPN - Virtual Private Networking Appliance

Latest version: 2.0.1-1

Functional Overview

VPN is a Virtual Private Networking appliance that operates in IPv4 and IPv6 networks, designed to provide secure and reliable tunnels for inter-grid communications and remote access to applications and appliances. VPN can also operate without using VPN tunnels, in which case it functions as a combined cleartext IN/OUT gateway. VPN may also be used to seamlessly interconnect IPv4 and IPv6 CA 3Tera AppLogic grids. VPN is based on the OpenVPN, OpenSSH and Racoon open source software packages.

VPN has three basic modes of operation: Server, client, and both.

• When operating as a server, traffic received through the external interface is sent through the srv terminal. If VPN is using a tunnel, traffic from the tunnel established over the external interface is decrypted prior to being forwarded through the srv terminal. In this mode of operation, VPN operates as a IN gateway with VPN tunnel support.
• When operating as a client, traffic received through the clt terminal is sent forwarded through the external interface. If VPN is using a tunnel, traffic is encrypted prior to being sent through the tunnel established over the external interface. In this mode of operation, VPN operates as an OUT gateway with VPN tunnel support.
• When operating as both a server and a client, both of the above traffic flows are supported providing for operation as a combined IN/OUT gateway.

VPN supports IPSec, shared secrets files, SSL certificates and ssh key files for authentication and encryption. A regular OpenVPN/OpenSSH client may be used on a remote workstation to connect to VPN, which in turn provides secure access to the internal components of an application running on CA 3Tera AppLogic. The VPN appliance supports the generation of shared secrets files, SSL certificates and ssh keys.

To remotely access an CA 3Tera AppLogic application over a secure VPN tunnel using VPN, the OpenVPN client-side software, or OpenSSH may be used on the client's machine (or some other compatible software).

Boundary

Resources

Terminals

Properties

General properties

Important! At least one pair of addresses (IPv4 or IPv6) must be defined.

VPN properties

Server properties

Client properties

Volumes

Custom Counters

The VPN appliance reports the following custom counters through the mon terminal.

Performance

Two test applications were residing on the same CA 3Tera AppLogic grid. 100mbit bandwidth was assigned to both VPN appliances (client and server), and to server and client appliances. Multiple object, each 1Mbyte in size, were fetched, 10 objects in parallel, for 60 seconds.

Error Messages

In case of appliance startup failure, the following errors may be logged to the system log:

Types of Tunnels

Cleartext

This mode supports a single server - multiple clients scenario, allowing access to the VPN server from multiple locations. In this mode VPN tunnels are not established, and a data store is not required (neither a data volume nor a NAS appliance connected to the fs terminal). This mode operates in IPv4 and IPv6.

On the server VPN appliance, traffic received on the external interface is filtered through the tcp_ports, udp_ports, aux_protocols properties and forwarded to the srv interface.

On the client VPN appliance, all traffic received on the clt interface is forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway, mode, tunnel, allowed_hosts, tcp_ports, udp_ports, aux_protocols.

Properties that must be configured on the client side: ip_addr, netmask, gateway, mode, tunnel, remote_host.

Server-side property remote_host must be configured with client's address if IPv6 mode is in use.

Certificate

This mode supports a single server - multiple clients scenario, allowing access to the VPN server from multiple locations. A data store is required (either a data volume or a NAS appliance connected to the fs terminal). This mode operates in both IPv4 and IPv6.

Upon start, the server appliance generates necessary certificates and key files if these files are not already present. These files may be re-generated with the security.sh script, located in the /appliance/ directory. Prior to configuring any VPN clients, certificates must be generated for them. A user may login into the running VPN server appliance and generate a client key pair as follows:

grid> comp login VPN-1:main.VPN
CentOS release 5 (Final)

[VPN-1:main.VPN ~]# /appliance/security.sh generate_client
Generated client SSL certificate and key file.
==============================================
These files, with CA certificate file, should be copied to VPN server into
/client/ subdirectory of data volume or fs-mounted volume.
Path to client files (client.829de5afcac564b3) should be specified in auth_path property.
Location of files:
client certificate: /mnt/fs/server/client.829de5afcac564b3.crt
client key file: /mnt/fs/server/client.829de5afcac564b3.key
CA certificate file located at /mnt/fs/server/ca.crt

The client certificate and key file must be copied to the client VPN appliance to the /client/ subdirectory of the data store, and the auth_path set to the appropriate value, client.829de5afcac564b3 in this case. The CA Technologies certificate from the VPN server (/mnt/fs/server/ca.crt) must be copied to the /client/ subdirectory on the client appliance too, and named "ca.crt". Every client VPN appliance should have it's own certificate.

On the server VPN appliance, traffic received on the external interface is decrypted, filtered through the tcp_ports, udp_ports, aux_protocols properties and forwarded to the srv interface.

On the client VPN appliance, all traffic received on the clt interface is encrypted and forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, allowed_hosts, tcp_ports, udp_ports, aux_protocols.

Properties that must be configured on the client side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, remote_host, auth_path.

Shared Secrets File

This mode supports only the single server - single client scenario, allowing access to the VPN server from only single client at one time. A data store is required (either a data volume or a NAS appliance connected to the fs terminal). This mode operates in both IPv4 and IPv6.

Upon the start, the server appliance generates a shared secrets file /server/secret.key, if this file is not already present. This file may be re-generated with the security.sh script, located in the /appliance/ directory. Prior to configuring any VPN clients, this shared secrets file must be copied to it's data store into the /client/ subdirectory. Te generate a new shared secrets file, a user may login into the running VPN server appliance and issue the following command:

[VPN-1:main.VPN server]# /appliance/security.sh generate_secret
Generated OpenVPN shared secrets file.
======================================
This file should be copied to VPN server into /server/ subdirectory of data volume or fs-mounted volume,
and to the VPN client into /client/ subdirectory of data volume or fs-mounted volume.
Path to it should be specified in auth_path property of the VPN client.
Location of file: /mnt/fs/server/secret.key

A freshly-generated secrets file overwrites the old one, if it existed. This shared secrets file /mnt/fs/server/secret.key must be copied to the client VPN appliance into /client/ subdirectory of the data store, and auth_path property set to the correct value, secret.key in this case. Multiple client VPN appliances may be configured, but only one can be connected at any time.

On the server VPN appliance, traffic received on the external interface is decrypted, filtered through the tcp_ports, udp_ports, aux_protocols properties and forwarded to the srv interface.

On the client VPN appliance, all traffic received on the clt interface is encrypted and forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, allowed_hosts, tcp_ports, udp_ports, aux_protocols.

Properties that must be configured on the client side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, remote_host, auth_path.

Ssh Key

This mode supports a single server - multiple clients scenario, allowing access to the vpn server from multiple locations. A data store is required (either a data volume or a NAS appliance connected to the fs terminal). Only tcp traffic may be tunnelled through the ssh tunnel, so only tcp_ports property is used on the server side. Port ranges are not supported - every ports that should be forwarded must be specified explicitly in ssh_ports client-side property. This mode operates in both IPv4 and IPv6.

vpn server generates the default ssh keypair upon start; default keys are located at: server key (public key): server/ssh-server.pub client key (private key): server/ssh-client.key Additional keys may be generated manually using the security.sh script:

[VPN-1:main.VPN ~]# /appliance/security.sh generate_ssh
Generated SSH keypair.
======================
Public key should be copied to VPN server into /server/ subdirectory of data volume or fs-mounted volume.
Private key should be copied to VPN client into /client/ subdirectory of data volume or fs-mounted volume.
Path to key files should be specified in auth_path property on both VPN client and server.
Location of files:
Public key: /mnt/fs/server/ssh.11179ebbfa3f6852.pub
Private key: /mnt/fs/server/ssh.11179ebbfa3f6852.key

The public key should be copied to the VPN server into the /server/ subdirectory; the private key should be copied to the client into the /client/ subdirectory. The auth_path property should be set on both client and server. If auth_path is empty on the server, the default SSH key is used.

On the server VPN appliance, traffic received on the external interface is decrypted, filtered through the ssh_ports property and forwarded to the srv interface. Only tcp port forwarding is supported. The auth_path property defines the public SSH key to use. When the appliance is working in both client and server mode, both public and private keys should be named the same, and located in /server/ and /client/ subdirectories. The ssh_ports property should be configured on both server and client in the same way.

On the client VPN appliance, all traffic received on the clt interface is encrypted and forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, allowed_hosts, auth_path, tcp_ports.

Properties that must be configured on the client side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, remote_host, auth_path, ssh_ports.

Important! SSH server-server mode. Two VPN appliances may both be configured in both mode and connect to each other. To use this mode, appliances must be configured in a special way:

Assuming you have 2 appliances named VPN1 and VPN2: 1. create 2 sets of public/private key files (1.key/1.pub, 2.key/2.pub , using "/appliance/security.sh generate_ssh" script) 2. configure auth_path property on both appliances to "ssh.key" 3. copy 2.pub to VPN1:/mnt/data/server/ssh.key (or to ssh.key file in /server/ subdirectory of the NAS drive) (public key goes to /server/ subdirectory) 4. copy 2.key to VPN2:/mnt/data/client/ssh.key (private key goes to /client/ subdirectory) 5. copy 1.pub to VPN2:/mnt/data/server/ssh.key (public key goes to /server/ subdirectory) 6. copy 1.key to VPN1:/mnt/data/client/ssh.key (private key goes to /client/ subdirectory).

IPSec Certificate

This mode supports a single server - multiple clients scenario, allowing access to the VPN server from multiple locations. A data store is required (either a data volume or a NAS appliance connected to the fs terminal). This mode operates only in IPv4.

Upon start, the server appliance generates necessary certificates and key files if these files are not already present. These files may be re-generated with the security.sh script, located in the /appliance/ directory. Prior to configuring any VPN clients, certificates must be generated for them. A user may login into the running VPN server appliance and generate a client keypair as follows:

grid> comp login VPN-1:main.VPN
CentOS release 5 (Final)

[VPN-1:main.VPN ~]# /appliance/security.sh generate_client
Generated client SSL cerfiticate and key file.
==============================================
These files, with CA certificate file, should be copied to VPN server into
/client/ subdirectory of data volume or fs-mounted volume.
Path to client files (client.829de5afcac564b3) should be specified in auth_path property.
Location of files:
client certificate: /mnt/fs/server/client.829de5afcac564b3.crt
client key file: /mnt/fs/server/client.829de5afcac564b3.key
CA certificate file located at /mnt/fs/server/ca.crt

The client certificate and key file must be copied to the client VPN appliance to the /client/ subdirectory of the data store, and the auth_path set to the appropriate value, client.829de5afcac564b3 in this case. The CA Technologies certificate from the VPN server (/mnt/fs/server/ca.crt) must be copied to the /client/ subdirectory on the client appliance too, and named ca.crt. Every client VPN appliance should have it's own certificate.

Important! An exception exist when VPN is used in both mode. In this case all certificates, client and server ones, must be generated by the same VPN instance, and distributed together with it's ca.crt certificate to other instances.

On the server VPN appliance, traffic received on the external interface is decrypted, filtered through the tcp_ports, udp_ports, aux_protocols properties and forwarded to the srv interface.

On the client VPN appliance, all traffic received on the clt interface is encrypted and forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, allowed_hosts, tcp_ports, udp_ports, aux_protocols.

Properties that must be configured on the client side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, remote_host, auth_path.

IPSec Shared Secret

This mode supports a single server - multiple clients scenario, allowing access to the VPN server from multiple locations. A data store is required (either a data volume or a NAS appliance connected to the fs terminal). This mode operates only in IPv4.

Upon the start, the server appliance extracts first line of the file specified in auth_path property and uses it as a shared key. This file must be present on both parties. Prior to configuring any VPN clients, this shared secrets file must be copied to its data store into the /client/ subdirectory.

On the server VPN appliance, traffic received on the external interface is decrypted, filtered through the tcp_ports, udp_ports, aux_protocols properties and forwarded to the srv interface.

On the client VPN appliance, all traffic received on the clt interface is encrypted and forwarded to the remote VPN server, specified in the remote_host property.

Properties that must be configured on the server side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, allowed_hosts, tcp_ports, udp_ports, aux_protocols.

Properties that must be configured on the client side: ip_addr, netmask, gateway (or corresponding IPv6 properties), mode, tunnel, remote_host, auth_path.

Typical Usage

Remote Access to an External Service

The following diagram illustrates an example of how you configure remote access to an external service:

In this example a web appliance, running on Grid A, accesses a remote MySQL database running on Grid B over a secure VPN tunnel.

vpn1 on Grid A is configured to connect to the IP address assigned to vpn2 on Grid B. The srv terminal of vpn1 and the clt terminal of vpn2 are left unconnected. External interfaces of vpn1 and vpn2 are configured with appropriate routable IP addresses.

Example property configuration:

vpn1:

vpn2:

Remote Access to Internal CA 3Tera AppLogic Appliances

The following diagram illustrates an example of how you configure remote access to internal CA 3Tera AppLogic appliances:

In this example, a user from his/her PC needs to access several different appliances through a secure VPN connection using the OpenVPN client. OpenVPN is used to connect to the IP address assigned to vpn. Vpn establishes a VPN tunnel with the user's PC and forwards all incoming traffic to the sw port switch, which is configured to distribute traffic to four different appliances within the application.

OpenVPN must be installed on the user's PC prior to accessing an CA 3Tera AppLogic application that uses the VPN appliance as described in this example. The steps below describe how this application is configured and what a user must do to access the application over a secure VPN tunnel:

1. The user must install OpenVPN on their PC. OpenVPN may be obtained from either here or here (there has been reports of OpenVPN not working on Windows Vista). After installation, a separate configuration file must be created that defines the properties of the OpenVPN tunnel that the user will use to access the CA 3Tera AppLogic application. The steps below describe how to do this.
2. It is strongly recommended to use the shared secret mode of operation of the VPN appliance. Configure vpn as follows:

vpn:

3. Assign the desired protocols and ports that need to be forwarded through the sw appliance. In this case 4 ports (122,422,522,822) are forwarded to the ssh ports of the appliances connected to sw:

4. Start the application. After the application is started, extract the shared secrets file from the vpn appliance:

grid> comp ssh APPLICATION:main.VPN
vpn> cat /mnt/data/server/secret.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
431e845f2ca67f2a31649b20e3ba3291
...
fe991cdbfe82525a9367b9afbfd0f922
-----END OpenVPN Static key V1-----

5. Paste the contents of secret.key above into a new file on the user's PC and save the file. This is a shared secrets file that is used for authentication.

6. Prepare a client OpenVPN configuration file. Copy the following lines into a new file on the user's PC (a different file from step 5):

dev tun
proto udp
resolv-retry infinite
persist-key
persist-tun
cipher AES-128-CBC
comp-lzo
keepalive 10 120
remote 11.22.33.44 1194
secret "C:\\Program Files\\OpenVPN\\sample-config\\secret.key"
nobind
ifconfig 169.254.215.101 169.254.215.102

IP addresses in the ifconfig line may be any, as long as they are: a) from the 169.254.0.0/16 network block b) in the same /30 subnet c) are not first or last addresses in the /30 subnet. B and C are the limitations of the OpenVPN client running on Windows platform.

7. Replace the remote IP address with the IP address that is assigned to the vpn appliance. Replace the path to the shared secrets file in the secret line with the path to the key file created in step 5. If you are using a Microsoft Windows operating system on the user PC where OpenVPN was installed, enclose all lines in quotes and replace every slash with a double-slash.

8. Launch the OpenVPN client:

c:\program files\OpenVPN\bin\openvpn.exe --config "c:\client.ovpn"

Note: Replace "c:\client.ovpn" with the path to the configuration file created in step 6.

9. After few seconds, you will see the following message from OpenVPN:

Wed Jul 01 09:41:12 2009 Peer Connection Initiated with XX.XX.XX.XX:1194
Wed Jul 01 09:41:12 2009 Initialization Sequence Completed

Now you can access the appliances of the CA 3Tera AppLogic application using the IP address defined in the configuration file (169.254.215.102 in this case). Port 169.254.215.102:122 is forwarded by sw to port 22 of the srv1 appliance, likewise port 169.254.215.102:422 is forwarded to the srv4 appliance, and so on. For example, execute

ssh -p 122 root@169.254.215.102
to access the first appliance.

Providing Secure VPN Tunnels for MySQL Replication

The following diagram illustrates an example of how you can provide secure VPN tunnels for MySQL replication:

In this example two applications are running on different grids, Grid A and Grid B, where both applications use the same MySQL database which is replicated through a secure VPN tunnel.

vpn1 and vpn2 are configured with routable IP address on their external interfaces. vpn1 is configured to establish a tunnel to vpn2, and vice versa.

db1 from Grid A sends traffic to vpn1 for replication purposes, where it is encrypted and transmitted to vpn2 which decrypts the traffic and sends it to the rin terminal of db2 on Grid B. Likewise, replication from db2 on Grid B to db1 on the Grid A behaves in the same manner.

vpn1:

vpn2:

Alternatively, the IPSec shared secret mode may be used:
vpn1:

vpn2:

Providing Secure IPv6 VPN Tunnels for MySQL Replication

The following diagram illustrates an example of how you can provide secure IPv6 VPN tunnels for MySQL replication:

Here we use the same two applications from the previous example, but running on the IPv6 network.

vpn1 and vpn2 are configured with routable IP address on their external interfaces. vpn1 is configured to establish a tunnel to vpn2, and vice versa.

db1 from Grid A sends traffic to vpn1 for replication purposes, where it is encrypted and transmitted to vpn2 which decrypts the traffic and sends it to the rin terminal of db2 on Grid B. Likewise, replication from db2 on Grid B to db1 on the Grid A behaves in the same manner.

vpn1:

vpn2:

Notes

OpenVPN must be used on the client's machine to access a secure VPN tunnel exposed by the VPN appliance.

3rd party open source software used inside of the appliance

VPN uses the following 3rd party open source packages in addition to the 3rd party open source packages used by its base class LUX5.