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:
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).
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.
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.
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.
Metric
Before dgtel Consulting
After dgtel Consulting
Remote Access
Impossible due to client-side NAT/CPE configuration constraints25.
Full routed access to all remote machines and their LANs via a single tunnel26262626.
Security
No secure link to remote machines.
All communication secured via an OpenVPN tunnel with custom certificates and cryptographic keys (e.g., DH keys)27272727.
IP Management
Subnet conflicts and routing difficulty.
Efficient subnetting into /30 blocks to comply with Windows client constraints 28and clear routing via CCD/iroute29.
This project demonstrates dgtel Consulting’s deep expertise in solving complex cross-platform networking and routing challenges, even when faced with significant administrative limitations.
Client Challenge: Bridging Public Access with Private Security
A small hotel client required a critical upgrade to their network infrastructure to securely integrate both guest-facing and administrative systems using a limited block of assigned public IP addresses.
The client was using a Mikrotik RouterBoard (R1) as their edge device, successfully providing general internet access via a single public WAN IP. The challenge was to assign two specific public IP addresses from their small /29 subnet (50.146.26.82 – 50.146.26.86) to key systems:
Guest WiFi Router (R2): The third-party vendor required a dedicated public IP address on their WAN interface for remote management, bypassing the need for complex NAT/Port Forwarding.
CCTV/NVR System: The property owner required a dedicated public IP for remote, direct monitoring.
Crucially, the solution needed to maintain strict network segregation, ensuring guest devices connected to R2 had absolutely no access to the hotel’s internal administrative computers or the CCTV system.
The dgtel Consulting Solution: Strategic IP Segmentation and Firewall Policy
Our expert consultant, quickly assessed the client’s architecture and proposed an optimal solution that prioritized security, public IP conservation, and simplified remote access.
Initial Strategy: IP Segmentation (Option 2)
The initial proposal was to split the single /29 public IP block into two separate /30 subnets. This ensured distinct, dedicated network segments for the CCTV and Guest WiFi systems. While this approach is typically straightforward, it consumes more IP addresses (e.g., losing the first and last address in each new subnet).
Refined Strategy: Maximizing IP Utilization with Bridging and Static Mapping
After further discussion, a more efficient and elegant solution was adopted to conserve the limited public IP addresses: Utilizing a single Layer 2 bridge interface on R1 for the LAN and using static IP assignments for public-facing devices.
This approach allowed the hotel’s administrative computers, printers, and other internal devices to remain on the existing Private DHCP subnet (connected via a switch on a designated port) while simultaneously enabling the public-facing devices to receive their static public addresses.
Key Implementation Steps:
Unified LAN Bridge: All internal ports intended for the hotel’s LAN (including the switch for Admin PCs and the ports connecting to R2 and the NVR) were grouped into a single Mikrotik Bridge Interface on R1.
Private DHCP Coexistence: The existing Private IP DHCP Server remained active on the bridge, ensuring the Admin computers and printers continued to receive their internal, private IP addresses automatically.
Static Public IP Assignment:
The Guest WiFi Router (R2) WAN port was manually configured with a specific, usable Public IP from the /29 block.
The CCTV/NVR System was manually configured with its own specific, usable Public IP from the /29 block.
Security Layer: Critical IP > Firewall rules were implemented on R1 to enforce the security requirement. These rules specifically blocked all traffic originating from the subnet of the Guest WiFi Router (R2) from accessing the IP ranges of the Admin computers and the CCTV system, achieving complete network segregation.
Outcome and Impact
By leveraging advanced MikroTik configuration techniques, dgtel consulting successfully delivered a network that was both functional and fundamentally secure.
The solution provided the required remote manageability for the third-party Guest WiFi provider and the property owner, all while preserving the internal network’s security and conserving the client’s limited public IP resources.
This project exemplifies dgtel consulting’s ability to translate complex business needs into precise, robust, and elegant network architecture solutions.
