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: Securing Guest Networks and Corporate Branding
A client managing network infrastructure for over 400 hotel locations required an urgent and robust solution to two critical problems on their MikroTik RouterOS devices:
Effective BitTorrent Mitigation: Their existing Layer-7 (L7) script for blocking BitTorrent traffic was failing, leading to excessive bandwidth consumption and, critically, exposing the hotels to potential copyright infringement complaints. The solution needed to be secure enough to deter “lazy users” while having a “failover” method to limit bandwidth if sophisticated users managed to bypass the block.
Corporate Branding Implementation: The client needed assistance fixing issues with the MikroTik Branding Package Maker to ensure their corporate logo and branding correctly replaced the default MikroTik elements across the router’s web interface and terminal.
The dgtel Consulting Solution: Multi-Layered Security and Expert Package Configuration
Our consultant, engaged with the client on a test environment to develop, test, and deploy a robust, two-part solution addressing both security and branding.
1. Robust BitTorrent Blocking
Recognizing the limitations of relying solely on L7 filtering for modern, encrypted P2P traffic, our consultant first focused on finding the most effective L7 signature and then implementing a multi-step Firewall Filter approach:
L7 Signature Refinement: After testing several scripts, the optimal, battle-tested L7 RegEx signature that scans for BitTorrent protocol handshakes and known P2P data patterns was deployed. This method targets the communication between peers, making it highly effective even when torrent trackers are accessed via encrypted connections.
Firewall Filter Automation: The crucial step was implementing a set of three sequential Firewall Filter rules:
Detection and Listing: Any traffic matching the specific L7 BitTorrent signature automatically adds the client’s source IP address to a temporary address-list called Torrent-Conn.
Blocking (TCP/UDP): Subsequent rules immediately and automatically DROP (block) all high-port TCP and UDP traffic (the ports typically used by P2P protocols) originating from the IPs now listed in the Torrent-Conn list.
This approach was confirmed to successfully block P2P sessions—even when a user attempted to use a basic VPN—by triggering the address-list blockage seconds after a torrent connection was initiated.
Optimal Firewall Rule Placement: Critical to network performance, the final security rules were placed immediately after the connection-state=established,related rules. This ensures that legitimate, ongoing traffic does not waste CPU cycles being checked against the torrent rules, while new connections are scanned immediately for P2P signatures.
The client was facing difficulties replacing the default logo on the main router login page. Our consultant provided the technical insight needed for a successful branding overhaul:
Identifying Specific File Requirements: The core issue was often related to specific file naming conventions and technical requirements. The consultant confirmed the necessity of correct file names like mikrotik_logo.png (for the web page logo) and the specific process of creating and installing the Branding Package via Netinstall or direct upload.
CLI vs. Winbox Configuration: A critical piece of troubleshooting for the BitTorrent L7 rule was the discovery that some complex Mikrotik configurations would not accept the long RegEx string directly via the Command Line Interface (CLI), requiring the use of the Winbox application for successful copy-paste and configuration, a technique shared with the client.
Outcome and Impact
dgtel consulting provided a sophisticated and resilient security architecture that immediately mitigated the client’s risk exposure and bandwidth challenges.
Area of Impact
Resolution Provided
Client Benefit
P2P Blocking Effectiveness
Deployment of a signature-based Layer-7 detection combined with address-list dynamic blocking.
Eliminated copyright infringement risks and restored control over bandwidth utilization.
Network Performance
Optimized Firewall rule ordering (Established/Related first, then Torrent rules).
Reduced router CPU load and ensured legitimate web traffic remained fast and responsive.
Corporate Presence
Technical consultation on Branding Package Maker file requirements and implementation.
Enabled the client to enforce corporate brand consistency across their 400+ device network.
The project demonstrated dgtel’s ability to move beyond simple configuration fixes, delivering expert-level, tested, and high-performance solutions essential for large-scale, security-conscious network environments like the hospitality industry.
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.
