Theory for Running OpenVPN on Server

OpenVPN is a free software for building a Virtual Private Network (VPN) via an encrypted TLS connection. For encryption OpenSSL or mbed TLS can be used. OpenVPN uses either UDP or TCP for transport.

OpenVPN is under the GNU GPL and supports the Linux operating systems, Solaris, BSD, MacOS, QNX, Windows, Android, iOS. Also, there are customized implementations for a variety of Linux-based devices, such as for the set-top boxes. Often a secure, unreadable third party communication over an insecure network should be performed. Such an insecure network is about the Internet or even a local non-encrypted wireless LAN. Two aspects are essential here: adequate encryption of the communication contents and authentication of the communication partners involved. These security properties can be provided by appropriate protocols (eg SSH, HTTPS, SFTP ) from any application. Alternatively, this security may also be desirable from a central location, regardless of the individual applications. The benefits of this centralized approach are the one-time implementation of security features, reduced maintenance, and the ability to secure communications from third-party software that has no impact. One such centrally provisioned backup is a Virtual Private Network (VPN). OpenVPN is one of many implementations of a VPN.

Communication partners can be individual computers or a network of computers. Typical use cases are the connection of individual sales representatives in the network of their company, the connection of a branch with the data center or the connection of locally distributed servers or data centers among themselves. In any case, one of the two communication parties establishes the connection (client) and the other waits for incoming connections (server). For this, the server must be reachable under a fixed IP address or under a fixed host name . This can also be done with the help of a dynamic DNS service for computers that are facing dial-up connections with constantly changing IP addresses.

If a packet filter or proxy is present in front of the VPN gateway, or if an address translation (NAT) is carried out, then these services must be configured in such a way that a UDP or TCP port to be assigned in the OpenVPN configuration is passed through for input, Forward and Output. An OpenVPN server instance can only be configured for one port and one protocol. A mixed mode, in which a client connection is optionally possible on TCP or UDP, can only be implemented with two parallel server instances. OpenVPN moved after the beta phase of version 2.0 of the then standard port 5000 used on the OpenVPN registered port 1194. The specific port used can be changed as required in the configuration.

OpenVPN connections can be trivially recognized by a deep packet inspection on the known header data of the transmitted packets, regardless of which protocol or which port is used. Although the Deep Packet Inspection can not determine the content in the encrypted tunnel, it can, for example, block the connection with the detection, determine the communication partners and log the data to it. This is especially important when the use of VPN connections is not allowed in certain environments, such as countries that prohibit encrypted communications, or civil law when bypassing network blocks on corporate networks.

 

Operating Modes of OpenVPN

 

OpenVPN has two operating modes: Routing and Bridging. The routing mode is the simplest form of secure communication and establishes an encrypted tunnel between two remote sites over which only IP packets are routed (Layer 3). For this purpose, each remote station is assigned a virtual IP address of a fictitious subnet (eg 10.8.0.1 and 10.8.0.2). Access to the underlying network is basically not possible directly (point-to-point connection). In order to reach the addresses there, the remote station must forward the data packets by means of IP forwarding and entries in the routing table or resort to Network Address Translation. In contrast to routing, full tunneling of Ethernet frames (Layer 2) is possible in Bridging mode. It also allows, for example, the use of alternative protocols such as IPX and the transmission of Wake-On-LAN packets.

A client integrates completely transparently into the dial-up network and receives an IP address of the subnet assigned there, so that broadcasts can also be forwarded. The latter is especially necessary for the automatic Windows name resolution of the SMB protocol. In order to be able to plug into the existing subnet, the virtual network card used by OpenVPN, the so-called TAP device , must be connected to the actual network via a network bridge. Bridging is a little more inefficient than routing (poorly scalable). In addition, restricting client access is more difficult to accomplish than routing.

 

Authentication of OpenVPN

 

For authentication, OpenVPN provides two main methods – Pre-shared Key and Certificates. When exchanging a “pre-shared key” (a static key/password), the data is encrypted and decrypted with it. This procedure is easy to use. It is used, for example, in commercial proxy providers, which also offer anonymization services based on OpenVPN. This method has two disadvantages: the key can be compromised due to improper handling (like, writing in which the annihilation is forgotten after use) and brute force attacks on the key similar to a password

Therefore, the selected key should be generated in sufficient length and consist of the largest possible character set. The key should not be chosen as a password itself. A storage of the key should be reduced to a minimum, because the key lies only on the end points of the VPN connection. The recording or entering of the key in a password management is an additional security risk. On the terminal, the pre-shared-key should be encrypted by a password, so as not to endanger the network in the event of loss of the device.

When using certificate-based authentication through the TLS protocol, private and public key pairs, or X.509 certificates, are used. The server and the respective users each have their own certificate (public/private). The OpenVPN server only allows connections that have been signed by a known certification authority. OpenVPN contains scripts that enable easy certificate creation without any previous knowledge based on OpenSSL (easy-rsa).
To establish a connection, the client sends data to the server (SSL version and random data). The server sends the same data and its certificate back. The client authorizes the certificate. With two-sided authentication, the client also sends its certificate to the server. If the check has worked, the client creates the pre-master secret and encrypts it with the public key of the server. The server decrypts the data with its private key and creates the master-secret. This will create session keys. These are unique keys used to encrypt and decrypt the data. The client tells the server that from now on all data will be encrypted with the session key. The server confirms this, the tunnel is set up. After a period of time, OpenVPN automatically replaces the session key.
Certificate-based authentication is considered the safest form of login. To increase security, it is recommended to outsource the certificates on a smart card. OpenVPN supports all maps that can be accessed using Windows Crypto API or PKCS # 11.

 

Graphical frontends OpenVPN

 

For OpenVPN, there are various graphical frontends besides the command line. For example, the OpenVPN GUI for Windows, the Tunnelblick program for macOS, OpenVPN Admin, Securepoint OpenVPN Client Windows, Viscosity, OpenVPN Connect and so on.

So far, we have published several articles on VPN so far, which may be interesting for some of the readers. Here are some of them :

 

1. Role of VPN in the Field of IoT for Maintaining Session Privacy
2. Who Needs a VPN
3. Basics on VPN Logs and Zero Logging VPN
4. Connection to Cloud Infrastructure by VPN Tunnel

This Article Has Been Shared 2618 Times!

Facebook Twitter Google+ Pinterest