Secure Multi-Site Access via Custom OpenVPN Routed Tunnel

by Turab Gilani | Oct 31, 2025

Client Challenge: Accessing Remote LANs Behind NAT

One of our client, in France , required a secure, persistent method for a central machine (PC-A) to access multiple remote machines and their entire local area networks (LANs).

The core challenge involved network topology constraints:

• Central Access Point (PC-A): Needed to reach three remote sites: Remote1/Machine1, Remote2/Machine2, and Remote3/Machine3.
• NAT Barrier: All remote sites and the central PC-A were located behind Network Address Translation (NAT) devices (CPEs).
• Configuration Constraint: While the central server-side CPE could be configured for port forwarding, the access credentials for the remote client-side CPEs were unavailable.

The required solution had to overcome these NAT limitations to establish stable, routed connectivity to machines and subnets at the remote locations.

The dgtel’s Solution: OpenVPN Routed Tunnel (dev Tun)

The team at dgtel proposed and deployed a solution based on OpenVPN , utilizing a routed tunnel configuration (devtun) to establish secure, bi-directional network paths.

Architecture and Deployment:

1. Server and Client Roles: PC-A (the machine needing access) was configured as the OpenVPN Server with a single Ethernet interface. The three remote PCs (Remote 1, 2, 3) were configured as OpenVPN Clients and required dual Ethernet interfaces: one for the CPE and one for the local machine (e.g., Machine 1, 2, 3).
2. Server Access Configuration: The central CPE was configured with a static port forward for UDP port 443 (instead of the default 1194 ) directed to PC-A, allowing the OpenVPN Server to listen for incoming client tunnel requests.
3. IP Subnet Segmentation: To adhere to a specific limitation in the Windows environment requiring a max of /30 subnet over the VPN for a client , the main VPN subnet 10.8.0.0/24 was further segmented into three separate /30 subnets—one for each remote client.
4. Complex Routing Implementation: The key to accessing the remote LANs (Machine 1/192.168.100.0/24, Machine 2/192.168.101.0/24, Machine 3/192.168.102.0/24) was the successful configuration of multiple routing directives on the server:
   • Server-Side Routes: The server configuration file was updated with commands to define routes for all client LAN subnets.
   • Client-Side Push Routes: The server configuration used the push "route..." command to dynamically insert the remote LAN routes into the client’s routing tables.
   • Client Configuration Directory (CCD): The use of the client-config-dir ccd directive allowed for custom per-client configurations using individual files (e.g., remote1) to set client IP addresses and use the critical iroute command to define the client’s internal subnet back to the server.

Critical Technical Note:

A crucial discovery during deployment was the necessity of always running the OpenVPN GUI as an administrator on Windows 7 and 8 (64-bit) systems. Without administrator privileges, the application could not successfully add or remove routes in the operating system’s routing table, leading to a non-functional VPN.

Outcome and Impact

dgtel consulting successfully delivered a robust and secure VPN solution that granted the client’s central PC-A full, direct access to three remote LANs, completely bypassing the complexity of configuring multiple client-side NAT devices. This complex routing problem, which was initially stuck for days was solved with an elegant, documented, and fully operational OpenVPN architecture.

This project demonstrates dgtel Consulting’s deep expertise in solving complex cross-platform networking and routing challenges, even when faced with significant administrative limitations.