Tally Prime Remote Access: Migrating RDS from blocked Tailscale to Twingate

Overview

Remote access to the core Tally Prime ERP system at Maryana Group — served via Windows Server 2019 RDS RemoteApp — was abruptly cut off when ISPs in Oman began blocking the VPN protocols we relied on.

I migrated the architecture from Tailscale (WireGuard-based) to a Twingate Zero Trust Network Access (ZTNA) setup. Twingate’s connectors use outbound TCP/TLS connections, which look like standard HTTPS traffic to ISP firewalls, bypassing Deep Packet Inspection (DPI) without requiring a public IP or inbound firewall rules.

The migration was completed over a weekend. Remote access was restored before the next business day.

Tech Stack: Windows Server 2019 RDS RemoteApp, Ubuntu Linux (Hyper-V Connector), Let’s Encrypt (win-acme), custom PowerShell automation for certificate lifecycle management.

---

1. The Challenge: DPI Blocks Disrupt Remote Access

Remote access to the Tally Prime ERP system — hosted centrally via Windows Server 2019 RDS RemoteApp in the Muscat datacenter — was severed.

The existing setup relied on Tailscale. However, the Telecommunications Regulatory Authority (TRA) in Oman enforces regulations on encrypted communications, and local ISPs implemented Deep Packet Inspection (DPI) firewalls that identified and dropped unauthorized VPN packets.

Diagnostics & Root Cause Analysis

Branch managers reported complete connection timeouts. My investigation revealed that remote Tailscale clients could no longer authenticate with the Tailscale control plane or establish peer-to-peer data planes.

• Deep Packet Inspection (DPI) Fingerprinting: Running tailscale netcheck from affected branches consistently failed, reporting UDP: false. Tailscale relies on the WireGuard protocol (UDP). The ISP firewalls were fingerprinting WireGuard handshakes and silently dropping packets.

Command line output showing blocked UDP traffic indicative of ISP DPI filtering.

• Double NAT Complexity: The central server sat behind a restrictive Double NAT topology (Huawei 5G Modem → TP-Link Omada Router). Direct hardware IPsec VPNs weren’t possible since the ISP didn’t provide a routable public IP.

---

2. The Solution: Zero Trust Architecture with Twingate

The business needed a way to punch through Double NAT and evade ISP DPI without drawing regulatory scrutiny.

I chose Twingate as the replacement. Unlike Tailscale’s UDP-based peer-to-peer mesh, Twingate’s Connectors rely on outbound TCP/TLS connections to its cloud relays. To an ISP firewall, Twingate traffic looks like standard HTTPS web traffic.

High-Level Network Architecture

Zero Trust Data Flow: The Remote Client requests access. The Twingate Cloud Relay brokers the connection. The Ubuntu Connector (running inside the protected LAN) establishes an OUTBOUND TLS connection to the relay, pulling authorized traffic back in, bypassing inbound Double NAT restrictions entirely.

Phase 1: Infrastructure Deployment

1. Headless Connector Deployment: I provisioned an Ubuntu Server 24.04 LTS virtual machine on the host Hyper-V hypervisor. This lightweight Linux VM acts as the “Twingate Deployer” — the bridge between the cloud controller and the internal Windows LAN.
2. Network Bridging: Configured a Hyper-V External Virtual Switch, assigning the Ubuntu VM a static local IP on the 192.168.0.x subnet, giving it local line-of-sight to the Windows RDS host without exposing the Windows Server to the internet.

---

3. The Certificate Challenge (Critical Engineering)

The most complex hurdle emerged during final testing. While the Twingate tunnel was successfully routing TCP traffic to the Windows Server over ports 3389/443, the Remote Desktop Gateway (RDG) rejected the connections.

• The Error: Clients attempting to launch the Tally RemoteApp received “The server’s certificate subject name does not match the requested hostname” errors.
• The Cause: RDS expects clients to connect using a public FQDN (e.g., erp.maryana.com). But Twingate routes traffic using internal DNS (e.g., winserv-01.local). The Windows self-signed certificate had a subject name mismatch.

The Let’s Encrypt Automation Fix

To resolve the SSL conflict without purchasing premium certificates or retraining users to ignore security warnings, I built an automated Let’s Encrypt pipeline using the win-acme CLI tool and Cloudflare DNS validation.

1. Created a private DNS A-record (erp.internal.maryanagroup.com) resolving to the internal IP.
2. Configured win-acme to use the Cloudflare API for DNS-01 challenges, bypassing the need for port 80 to be open.

The PowerShell Binding Script: Generating the certificate was half the battle. RDS requires the certificate to be bound across four separate roles. I modified the win-acme JSON config to force "PrivateKeyExportable": true, and authored the following PowerShell script to automate the cryptographic binding on renewal:

# PowerShell script triggered automatically by win-acme upon successful 60-day renewal
Import-Module RemoteDesktopServices
$CertPath = "C:\Certs\erp-internal.pfx"
$Password = ConvertTo-SecureString -String "SecureAutomatedPassphrase!2025" -AsPlainText -Force

# Bind the Let's Encrypt wildcard certificate to the entire RDS deployment topology
Set-RDCertificate -Role RDRedirector -ImportPath $CertPath -Password $Password -Force
Set-RDCertificate -Role RDPublishing -ImportPath $CertPath -Password $Password -Force
Set-RDCertificate -Role RDWebAccess -ImportPath $CertPath -Password $Password -Force
Set-RDCertificate -Role RDGateway -ImportPath $CertPath -Password $Password -Force

Write-Host "Tally Prime RDS Infrastructure TLS Certificates updated successfully."

Verification of the valid Let’s Encrypt certificate successfully bound to the RDS Gateway.

---

4. Final Outcome

The migration was completed within a 36-hour weekend window, restoring full remote access before the business week started.

• Bypassed Restrictions: Twingate’s TCP/TLS outbound architecture evades the ISP’s UDP-blocking mechanisms entirely.
• Improved Performance: User-reported latency when typing within the Tally Prime RemoteApp decreased compared to the previous Tailscale setup.
• Lockdown Security: Zero inbound ports are open on the corporate firewall. Access is governed by Identity Provider (IdP) SSO authentication, following a true Zero Trust model.
• Zero-Touch Maintenance: The Let’s Encrypt SSL certificates now auto-renew via the injected PowerShell script, requiring no ongoing administrative intervention.