This series of posts explores useful OpenVPN server configuration options, including secure cryptographic algorithms, private network access, client-to-client communication, and traffic routing.

Important: Ensure that all required options are added to and saved in your OpenVPN server configuration file, typically /etc/openvpn/server.conf. Configuration paths may vary depending on your installation.

1. Configure Access to a Private Network

OpenVPN can provide remote users with secure access to resources on a private network behind the VPN server.

This is particularly useful when remote users need to access internal resources such as file servers, printers, databases, or other networked devices that are not directly accessible from the internet.

To enable access to a private network, the OpenVPN server can push a route to connected clients.

For example, if your internal network uses the subnet 192.168.1.0/24, add the following directive to your server configuration:

# Allow VPN clients to access the internal private network
push "route 192.168.1.0 255.255.255.0"

Understanding the Configuration

• push — Sends a configuration option from the OpenVPN server to connecting clients.
• route — Instructs the client to add a route to the specified network.
• 192.168.1.0 — Specifies the destination network address.
• 255.255.255.0 — Specifies the subnet mask, equivalent to a /24 prefix.

In this example, the route allows clients to direct traffic destined for 192.168.1.0/24 through the VPN.

Important: Pushing a route to the client does not, by itself, guarantee access to the private network. The OpenVPN server must also be able to forward traffic to the internal network, and the return traffic must have a valid route back to the VPN clients.

Depending on your network architecture, you may need to configure IP forwarding, firewall rules, and routing on the internal network.

Adjust the Private Network Route

Replace the example subnet with the actual network you want to make accessible.

For example:

# Example: Internal network using 192.168.10.0/24
push "route 192.168.10.0 255.255.255.0"

Use the correct network address and subnet mask for your environment.

Also, ensure that the internal network does not overlap with the VPN client's local network. Overlapping subnets can cause routing conflicts and prevent clients from reaching the intended resources.

2. Enable Client-to-Client Communication

OpenVPN also supports direct communication between connected VPN clients through the client-to-client directive.

Add the following option to your server configuration if clients need to communicate with one another:

# Allow communication between connected VPN clients
client-to-client

When enabled, OpenVPN can forward traffic between connected clients internally, provided that the relevant client routes, firewall policies, and access controls permit the communication.

For example, consider a VPN network using the subnet 10.8.0.0/24:

OpenVPN Server
10.8.0.1
     |
     |--------------------|
     |                    |
     v                    v
 Client A              Client B
 10.8.0.2              10.8.0.3

With client-to-client enabled, Client A can communicate with Client B through the OpenVPN server without routing that traffic through the separate internal LAN.

How Client-to-Client Communication Works

1. Direct communication between VPN clients

Connected clients can communicate using their VPN-assigned IP addresses, subject to their routing and firewall configurations.

For example, Client A might access a service running on Client B at 10.8.0.3.

2. Traffic remains within the VPN

Traffic between clients is forwarded through the OpenVPN server rather than being sent through the physical internal network behind the server.

This can simplify network configuration when clients need to communicate over their VPN addresses.

3. Internal network routing remains separate

The client-to-client directive does not replace the route needed to access a private LAN such as 192.168.1.0/24.

These are separate configuration requirements:

• push "route ..." provides clients with a route to a specified network.
• client-to-client enables OpenVPN to forward traffic between connected VPN clients.

Use each option according to your network requirements.

Security Consideration

Enabling client-to-client can increase the reachability of connected clients.

If your VPN serves users or devices that should remain isolated from one another, consider leaving this option disabled and implementing appropriate firewall rules and access controls.

Do not enable client-to-client communication unless it is required by your VPN's intended design.

3. What Happens Without client-to-client?

When client-to-client is disabled, OpenVPN does not automatically forward client traffic directly between connected VPN clients through its internal client-forwarding mechanism.

Communication between clients may still be possible through other network paths, depending on your routing and firewall configuration.

For example, clients might communicate through a separate LAN if the necessary routes and forwarding rules exist.

However, without client-to-client, you should not assume that clients can communicate directly using their VPN-assigned addresses.

Comparison

The important distinction is that private network access and client-to-client communication are separate capabilities.

4. Verify Private Network Connectivity

After updating the server configuration, restart the appropriate OpenVPN service:

$ sudo systemctl restart openvpn@server.service

Check that the service is running:

$ sudo systemctl status openvpn@server.service

Reconnect your VPN client to ensure it receives the updated configuration.

Test Access to an Internal Device

From the connected VPN client, try pinging a device on the internal network:

$ ping 192.168.1.1

Replace 192.168.1.1 with the IP address of a device that should be reachable.

If the ping succeeds, it confirms basic IP connectivity to that device.

However, a failed ping does not necessarily indicate a routing problem. The target device or an intervening firewall may block ICMP traffic.

Inspect the Client Routing Table

On a Linux client, run:

$ ip route

Look for a route to the intended private network, such as:

192.168.1.0/24 via <VPN_GATEWAY> dev tun0

The actual gateway and interface name depend on your OpenVPN configuration.

If the route is missing, check whether the server is pushing the correct network address and subnet mask and whether the client has accepted the configuration.

Verify Client-to-Client Communication

If client-to-client is enabled, test connectivity between two connected clients using their VPN-assigned addresses.

For example, from Client A:

$ ping 10.8.0.3

Replace 10.8.0.3 with Client B's actual VPN address.

If communication fails, check the client routing tables, host firewalls, OpenVPN configuration, and applicable access controls.

OpenVPN provides two useful capabilities for managing network access:

• Private network access: Use push "route ..." to tell clients how to reach an internal network through the VPN.
• Client-to-client communication: Use client-to-client when connected VPN clients need to communicate with one another through the OpenVPN server.

When configured correctly, these options allow remote users to securely access internal resources while providing flexibility over communication between VPN clients.

Remember that routes alone do not guarantee connectivity. Server-side forwarding, return routing, firewall policies, and access controls must also be configured appropriately.

We hope this guide proves useful in configuring and securing your OpenVPN deployment.