Bypassing ISP Blocks: The Business Case for Zero Trust

In Oman, the Telecommunications Regulatory Authority (TRA) maintains strict control over VoIP and VPN traffic. For businesses that depend on remote access, this creates a persistent operational risk that most IT strategies ignore until it becomes a crisis.

This is the story of how a single ISP-level DPI (Deep Packet Inspection) update crippled our operations for an entire day, and how migrating to Zero Trust architecture eliminated the entire class of failure — permanently. It’s one of several hard-won lessons from a decade of digital transformation at Maryana Group.

The Incident

Thursday, 9:00 AM. Four branch managers call within 15 minutes. Remote users can’t connect to the Tally Prime ERP hosted on our central Windows Server 2019 RDS.

The symptoms were consistent: connection attempts timing out, no error messages, services that worked yesterday failing silently.

Running tailscale netcheck confirmed the diagnosis: UDP was being blocked. The ISP had deployed a new DPI rule targeting WireGuard signatures. Our custom DERP (Designated Relay) servers were also being blackholed — the ISP wasn’t just blocking the protocol, it was identifying our infrastructure by its fingerprint.

Operations across all four branches stopped. No invoices could be generated. Inventory checks were impossible. The IT team had six hours to find a solution or escalate to leadership with a business-stoppage declaration.

Why Traditional Fixes Don’t Work Against DPI

The instinct from the team was to find a workaround — change the port, try a different protocol, find a way around the block. This instinct is wrong and it wastes critical time.

Changing ports: DPI analyzes traffic behavior, not just port numbers. WireGuard has a recognizable packet signature that doesn’t change regardless of which UDP port it travels on. The ISP wasn’t inspecting port 41541 — it was recognizing the protocol itself.

OpenVPN over TCP: We tested this. It’s too slow for RDP traffic. The protocol overhead combined with TCP’s congestion control makes remote desktop unusable. It also gets flagged by the ISP, though less consistently than WireGuard — which creates unreliable connectivity that’s sometimes worse than no connectivity at all.

Dedicated VPN lines: Physically leased lines that bypass internet infrastructure entirely. Expensive (thousands of dollars in setup fees) and takes weeks to provision. Not a solution for a 48-hour crisis.

The common thread: all of these approaches try to make the same thing look different. DPI is sophisticated enough to see through the disguise.

The Strategic Pivot: Zero Trust Network Access

Instead of finding another way to make a VPN work, I asked a different question: what if we didn’t use a VPN at all?

Zero Trust Network Access (ZTNA) works on a fundamentally different architecture. The old model is a gate around the network. The new model is a gate around every single resource.

What we needed:

A protocol that doesn’t have a recognizable fingerprint — standard TLS that looks like normal web traffic
No inbound port forwarding — our gateway sits behind Double NAT, so anything listening on a public port was immediately ruled out
Outbound-only connections — the client initiates, the server never opens a listener

The solution: Twingate.

The architecture uses outbound-only TLS connections that are indistinguishable from regular HTTPS traffic. There’s no VPN protocol to recognize. No special headers. No packet signatures. It’s web browsing.

The Architecture Shift

Old Model: VPN Tunnel

User Laptop → VPN Client → VPN Gateway → Full subnet access → ERP Server

The user authenticates once and gets access to the entire corporate network. This is the threat model you accept when you use traditional VPN:

If the user’s laptop is compromised with ransomware, the tunnel gives it access to every machine on the subnet
If the VPN credentials are stolen, the attacker has persistent network access without needing to be on-site
The VPN gateway is a single point of failure that, when compromised, exposes everything

This was acceptable risk in 2010. It’s not acceptable risk in 2024.

New Model: Zero Trust

User Laptop → Twingate Client → Twingate Relay (outbound TLS) → Internal Connector → ERP Server (only)

The user authenticates via our Identity Provider (IdP) — in our case, Google Workspace. Twingate’s client initiates an outbound TLS connection to Twingate’s relay. The relay proxies the connection to our internal connector, which validates that the user is authorized for the specific resource — specifically, 10.0.1.25:3389 (RDP to the ERP server).

That’s it. Nothing else is accessible. The connector has no other ports open. The server has no presence on the public internet.

The critical difference: There are zero inbound ports open on our firewall. The connection is established from the inside out using standard web traffic. A Shodan scan of our public IP returns nothing. There’s nothing to discover.

The Hidden Technical Hurdle: SSL Certificates

Zero Trust handles the routing, but Windows RDS has a stubborn requirement: it expects a valid SSL certificate for the hostname being accessed (rdgateway.company.com).

Since Twingate routes the connection internally using the private IP, the hostname on the certificate didn’t match the routed address. The RDP client rejected the connection with a certificate name mismatch error.

The fix: win-acme with Cloudflare DNS validation to generate a Let’s Encrypt certificate for the internal server hostname. Then bound it to all RDS roles via PowerShell.

# Bind the certificate to RDS roles
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*rdgateway*" } | Select-Object -First 1
$thumb = $cert.Thumbprint

# Apply to RD Gateway, RD Web Access, and RD CAP
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\SSL" -Name "MachineSSLThumbprint" -Value $thumb

This took two hours to implement and document. It’s a detail that would have blocked the entire migration if I hadn’t anticipated it in the architecture planning phase.

The Business Results

Operations restored within 48 hours. From incident declaration to full branch connectivity. The migration itself took six hours; the rest was testing and rollback planning.

Security posture improved dramatically:

Server has zero public internet presence — Shodan returns nothing
Microsegmentation: users can access the ERP server and nothing else on the subnet
Access is tied to identity, not network location — working from a coffee shop is the same security model as working from the office
Compromised laptop doesn’t mean compromised network — the ransomware can’t reach anything through the tunnel because there’s no tunnel

Operational improvements:

“VPN is down” support tickets: eliminated entirely
New branch provisioning: instead of configuring VPN tunnels and firewall rules, it’s now a Twingate connector install + DNS update
Incident response: compromised credentials are revoked at the IdP level, access is terminated within seconds

The Takeaway

Zero Trust isn’t a product category. It’s an architectural philosophy: assume the network is hostile, verify every request, minimize blast radius.

In regulatory environments where traditional VPN protocols are blocked, ZTNA isn’t a preference — it’s survival. But even in unrestricted environments, the security properties are worth the migration complexity.

The cost of the migration is one week of engineering time. The cost of not migrating is a single incident that halts operations for four branches simultaneously. That’s the business case that justified this project to leadership.