VPN Architecture for Internal Networks

In today's hyperconnected digital landscape, secure internal networks have become a cornerstone of corporate infrastructure. This crucial aspect of operations is often bolstered by robust VPN technologies, such as OpenVPN. 

As a leading solution in the realm of VPN, OpenVPN's architecture plays a critical role in enhancing corporate network security and connectivity. This article provides a comprehensive exploration of OpenVPN's architecture and its implementation for a company's internal networks. 

We will dive deep into different system components, from the client and DNS, to the load balancer server, firewall, service instances, and other core elements. Moreover, we will discuss essential features such as address pool, authentication, authorization, and routing. By the end of this article, readers will gain a profound understanding of how OpenVPN operates within a corporate context, enhancing the security and efficiency of internal communications.

System Components

Client

The client's config specifies:

The address openvpn.xx.com remote-random-hostname. Prepends a random string (6 bytes, 12 hex characters) to the hostname to prevent DNS caching. For example, "foo.bar.gov" would be modified to "<random-chars>.foo.bar.gov"

resolv-retry 60 . The 60 parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

DNS

An external public DNS server, which holds a wildcard sub-domain openvpn.xx.com with all external IP addresses of OpenVPN servers. This is necessary to prevent client-side IP caching and the possibility of taking a server out of operation without updating client configurations. 

Server

IPVS Load Balancer 

IPVS is used as a fast-layer 3/4 balancer. It listens to the standard OpenVPN port and forwards packets to local OpenVPN services in Direct Routing mode.

Balancing is carried out on a Least Connection principle. The IPVS rules and endpoints are managed by pre- and post-scripts of OpenVPN sub-services on systemd.

OpenVPN Services on systemd

A templated systemd service is used to raise the required number of instances, specified via "@" . In this case, each launched instance listens on its loopback address, where the service name loopback address is 127.0.X.10 

Additionally, an openvpn.target target is created, which launches all specified instances. ExecStartPre and ExecStopPost scripts are set for the service, which adds and removes the service from the IPVS balancing.

Firewall

All ports are blocked from the outside except 22 TCP, 1194 UDP, 443 TCP.

22 TCP: This port is used for Secure Shell (SSH) communication. It allows administrators to log into servers, execute commands, and manage files remotely, making it crucial for server maintenance and administration.

1194 UDP: This port is the default port used by OpenVPN for VPN connections. OpenVPN can operate over either the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). However, UDP is usually preferred as it is faster and more efficient for the tunneling protocol used by VPNs.

443 TCP: This port is used for HTTPS traffic. Port 443 is also often used as an alternative port for VPNs, especially in environments where port 1194 might be blocked.

OpenVPN Service

Instances

Since the OpenVPN server is single-threaded, the optimal number of user sessions that do not lead to a dramatic increase in jitter on one instance = 40-60.

To ensure the ability to hold the specified number of users, many OpenVPN instances are launched on one physical server.

To eliminate context switches and reduce OS overheads for scheduling, an OpenVPN instance should be pinned to a specific CPU core.

Thus, the number of OpenVPN instances on a server should be determined as the number of cores of the physical server minus four cores for the OS. For a 96-core server - this is from 40 (without HT) to 90 (with HT).

Address Pool

For a clear mapping of the client, its external and internal IP, all clients are given a real internal address. The gateway for clients is the OpenVPN server.

Each physical server is allocated one /19 subnet, which is divided into ranges for each of the OpenVPN instances. For example, 64 addresses are allocated to one OpenVPN instance, so up to 128 instances can be on one physical server.

Authentication

Authentication is carried out through LDAP.

To speed up the work of single-threaded OpenVPN, a local caching LDAP proxy is used.

Authorization

The right to access the OpenVPN service is determined at the level of the Active Directory group. At this stage, the division into access groups with different network access rights is not implemented.

Routing

The OpenVPN server gives the client routes to internal networks. The rest of the client's traffic goes through the client's networks.

Access to the Service

Authentication

Authentication is carried out in two variants, depending on the profile:

1. Password authentication is based on Active Directory accounts.
2. Certificate-based authentication

Authorization

The right to access the OpenVPN service is determined at the level of the Active Directory group.

Conclusion

This one architecture of OpenVPN offers a robust and secure solution for establishing and managing a company's internal network. Its versatile components, from the client configuration, DNS setup, load balancing, firewall rules, and service instances to the address pool management, authentication, authorization, and routing, all work in tandem to deliver a secure and efficient network system. 

However, the effective implementation of OpenVPN doesn't stop at its architecture. Regular maintenance, monitoring, and updating are required to keep the system secure and efficient. Additionally, given the complexity of the system, proper training for IT staff is essential for managing and troubleshooting the system.