What I Ask Before Touching Your VPN

Every migration inquiry I get starts the same way: “our VPN is slow, can you move us to Zero Trust?” And every sketch I send back starts with the same five requests. Not credentials or access. Five command outputs. I learned this the expensive way, by diagnosing a DPI block from timeouts and user reports after production was already down, when a 30-second probe during evaluation would have told me WireGuard was undeployable.

This checklist is the buying process without a services page. It comes straight from the RDS migration case study: every item below is a wall that cutover hit. The verdict behind it is ADR-003, the story behind it is the VPN-blocks post, and the hub for the whole Zero Trust record is the small-business guide.

1. tailscale netcheck from every branch

$ tailscale netcheck
Report:
  * UDP: false

The cutover’s transcript opens with this line: UDP blocked on every branch link, WireGuard handshakes never completing. I diagnosed the DPI block from timeouts and user reports, then ran the decisive netcheck (UDP: false) only after Tailscale was already failing in production. The case states the lesson plainly: a 30-second UDP probe from each branch during evaluation would have flagged WireGuard as undeployable before it became the thing to migrate away from.

Send me one netcheck per branch. If any of them says UDP: false, the protocol conversation is over and the architecture conversation begins.

2. DERP reachability, custom relays included

The VPN-blocks post documents what the ISP did beyond protocol fingerprinting: our custom DERP (Designated Encrypted Relay for Packets) servers were blackholed too. The ISP wasn’t just blocking WireGuard. It was identifying our relay infrastructure by fingerprint and dropping that as well.

So the second output: can your branches reach your relays, custom or provider-run? A mesh that can’t phone its control plane and can’t relay through its fallback has no degraded mode. It has an outage wearing a loading spinner.

3. Certificate subject names on every RDS role

Saturday night of the cutover, the tunnel was healthy and every session still failed: “The server’s certificate subject name does not match the requested hostname.” RDS expects the public FQDN (erp.example.com); Twingate routes over internal DNS (rds-host.example.internal); the self-signed certificate matched neither. The fix — win-acme DNS-01 via Cloudflare plus a PowerShell script binding all four RDS roles every 60 days — is extracted in full in the RDS binding guide.

Send me the subject names your roles present today. If they name a host your ZTNA path will never request, we plan the certificate pipeline before cutover night, not during it.

4. The NAT shape and the public-IP answer

The RDS estate sat behind double NAT (5G modem into an Omada router) with no routable public IP from the ISP. That topology is precisely why hardware IPsec was never an option and why outbound-TLS connectors were. Your topology decides the candidate set before any vendor comparison: no public IP means no inbound anything, and the evaluation collapses to “what dials out convincingly.”

Send me the path from branch client to server: NAT layers, who assigns addresses, whether any public IP is reachable. One paragraph beats a diagram.

5. The written rollback plan

The cutover’s results line reads: zero business days lost within a 36-hour weekend window. The parenthetical matters: 48 hours from incident declaration to full branch connectivity, testing and rollback planning included. The old path stayed routable until the new path carried a full business day.

Your fifth output is a paragraph: if Saturday goes wrong, what carries Monday morning? If the answer is “we’ll figure it out,” the migration isn’t scheduled yet. It’s wished for.

Honest limitations

• This checklist is one estate’s scar tissue. It generalizes to “DPI-filtered network, Windows RDS, no public IP”: a common shape in regulated markets, but not every VPN migration. A greenfield with clean UDP and a public IP has a different five items.
• No pricing, no timeline promises. The sketch I send back is an architecture direction with named risks rather than a quote. The cutover took a weekend because the estate was four branches and one RDS host; your mileage is your topology.
• The vendor trade travels with the recommendation. ADR-003 carries it openly: dependency moves from Tailscale’s control plane to Twingate’s, and the connector host becomes the single egress point to monitor. If that trade is unacceptable, the checklist still diagnoses you. It just prescribes a different chapter.

Skip these five outputs and every migration estimate is fiction: a discovery exercise conducted on production, billed as a plan. The pattern matches the one behind the decade of lessons: probe the path before committing to the protocol, in writing, before the weekend that counts.