Who Gets In, and Through Which Door

Tailscale has released MagicRoute in beta for its Premium and Enterprise plans. MagicRoute is a new way to decide which gateway machine each client uses when several machines advertise the same network routes. It replaces "regional routing," which matched clients to gateways through Tailscale's relay regions. Under that scheme, jitter of a few milliseconds could make gateways switch regions repeatedly, and every switch broke the connections of every client using them.

The problem: overlapping connectors

Admins add a second connector that advertises the same routes for three reasons: redundancy (one crashed machine shouldn't take the subnet offline), capacity (one machine can't carry all the traffic), or proximity (put connectors near users around the world). Once two connectors overlap, every client needs a rule for choosing between them.

What went wrong with regional routing

The authors list several ways this broke:

• Flapping on near-ties. A connector on a fast backbone or at a major internet exchange point can have latencies to several DERP regions within a couple of milliseconds of each other. Tiny amounts of jitter then make it switch its home region, switch again, then switch back.
• Cascades. When a connector flaps, every client using it loses its existing connections: SSH sessions drop and large file transfers stop partway. When a client switches connectors, the other clients in its DERP region switch too, so one wobble spreads into many broken sessions.
• Bad internet weather. Even connectors in ordinary data centers could be pushed, by a temporary slowdown, to choose a home DERP region in another country. That moved clients and broke their connections.
• Custom DERP excluded. Tailnets that run their own DERP servers couldn't use regional routing at all, because their regions don't line up with Tailscale's public ones.

The design flaw underneath all four is that one noisy measurement, latency to relays, set the routing assignment directly, with nothing to damp it. The authors' conclusion is that "the internet is too complex to make routing decisions based on one set of data points."

How MagicRoute works

MagicRoute scores and ranks every connector from each client's point of view. For each subnet route and each app, the client is matched to its highest-ranked connector. When several connectors tie for first place, clients are spread evenly among them.

Today the score comes from coarse location. Tailscale estimates where each node is, keeps only enough precision to find the nearest connector, and compares approximate distances. The authors chose distance over latency because it doesn't change unless the device moves. Latency changes all the time.

The second piece is stickiness. A client keeps its preferred connector as long as that connector is healthy, even if the ranking shifts. Failover runs down the ranked list. If the top choice is unhealthy, the client tries the next one, and so on until it finds a healthy connector.

A worked example, based on the article's diagrams:

• Client A has two connectors tied at the top rank. One is offline, so 100% of A's traffic goes to the other.
• Client B has one top-ranked connector and sends all its traffic there.
• Client C has two healthy top-ranked connectors, so it has a 50/50 chance of landing on either. Across many clients, that spreads the load.
• If both of A's top choices go offline, A moves to its second-ranked connector.

Configuration and scope

The admin console's single regional-routing switch is now a Route Selection setting with four options:

MagicRoute applies to the whole tailnet. Individual connectors can't opt out. The authors argue that per-node routing rules lead to "unexpected interactions and bad behavior." Every client version supports MagicRoute for subnet routers, app connectors and Service hosts. For recommended exit nodes, clients need version 1.86.0 or later.

Trade-offs and open questions

Several things go unexplained. The article doesn't say how location is estimated (IP geolocation is a plausible guess, but it isn't stated). It doesn't say how health is determined or how fast failover happens. It also doesn't say what happens when a failed connector comes back: stickiness implies clients stay where they failed over to, but the article doesn't confirm it. Load is spread only among connectors tied for first place, so nothing in the article suggests it accounts for capacity. One busy nearby connector could still be overloaded while a slightly farther one sits idle. There are no measurements either. The post gives no before-and-after numbers for flapping rates or dropped sessions, only the description of the mechanism.

Why it's harder than it looks

Some public access is deliberate, so "anonymous request succeeded" is not automatically a finding. The real question is whether exposure matches policy, across many teams whose services keep changing.

Shopify's first attempt read Kubernetes YAML in the infrastructure repository. It looked for Ingresses on public hostnames with no authentication setting, then sent each one a live request. It failed in three ways:

The team's summary: the repository shows intent, the cluster shows what is enforced.

Step 1: ask the cloud what is running

Step 2: probe like a stranger

The inventory says what could be exposed. Only an outside request shows what is. The scanner sends one anonymous request per endpoint under strict rules:

• Send HEAD first, and fall back to GET only if the server rejects it.
• Follow at most three redirects, by hand, checking each one. A redirect to an identity provider means the endpoint is protected.
• A 401 with an authentication challenge means protected. A 200 with real content means exposed.
• If only /admin is protected, also try /ADMIN and similar variants, because path rules can be case-sensitive.

Not becoming an SSRF tool

Step 3: classify without guessing

The six verdicts are:

• exposed: anonymous access worked and no allowlist entry matched, so it needs review
• expected: anonymous access worked and matched an approved entry
• protected: authentication or another control blocked the request
• not found: the service answered but the path doesn't exist
• unreachable: the scanner couldn't connect
• inconclusive: there was a response, but not enough evidence to decide

The rules live in a single lookup table keyed on (surface, status code), so reviewers can audit them in one place. The table showed that one status code can mean different things depending on the surface. Take 404:

• Behind an Ingress: the proxy answered and the path doesn't exist, so the verdict is not found.
• On Cloud Run: Google's front end can return 404 before the application ever runs, which says nothing about authentication. The verdict is inconclusive.

403 is inconclusive on both surfaces, because many applications return it for reasons unrelated to authentication. Any 5xx, and any status the table doesn't list, is also inconclusive. The governing rule: uncertainty does not mean protected.

The allowlist is context, not a skip list

Approved public endpoints sit in a code-reviewed allowlist, matched by exact host and path. They are still probed on every run. If one is open, the verdict becomes expected instead of exposed. If it turns out to be protected or gone, the entry is probably stale and gets flagged for review.

Each result stores what was configured, what the probe saw, whether an allowlist entry applied and, where known, the owning team. Response bodies and credentials are deliberately not stored.

Results

Early runs were mostly noise. In one July run, about three in four results were inconclusive. The team grouped results by reason and worked through the biggest groups. They added verdicts such as not found and unreachable only where the evidence supported them. Before shipping any rule change, they replay it against saved results from earlier scans and diff every verdict. Within a few weeks, inconclusive Ingress results fell by about 80%.

What's left open

The post gives no absolute numbers: how many endpoints were scanned, how many were truly exposed, or what share stays inconclusive after the 80% cut. It covers only GCP and two service types. It also doesn't say how paths beyond the hostname and allowlisted entries are chosen. A single anonymous probe can't see, for example, an unprotected API path that nobody listed. Shopify says it has published a starter kit for building a similar scanner.

The incident

In this post, Cloudflare's Grant Bourzikas argues that the deeper problem is not one bug. It is that the gateway's login page is reachable by anyone on the internet. His first instruction is blunt: if you haven't patched, go do that first.

Why patching and WAF rules leave a gap

A patch only helps once every instance has been found, updated and tested. On a production desktop fleet that can mean downtime for employees, and for the customers and patients who depend on them. A WAF rule, which inspects HTTP requests for known attack patterns, can buy time. But it is reactive: it matches signatures of exploits already seen, and says nothing about the next variant. Bourzikas says attackers are finding variants faster than before. His case is for defense in depth, where no single software flaw leads straight to compromise.

How a Citrix login flows

In a typical deployment:

None of this works unless step 1 is open to the internet, and that is the exposure the exploit used.

Layer 1: decide access before the gateway sees the request

An analogy (ours, not the article's): a WAF is a guard who checks visitors against a list of known criminals. An access policy is a locked lobby door that opens only for badge holders. The second doesn't need to know what the next criminal looks like.

The article states one limit plainly: this protects only the web login path. DTLS listeners and other gateway services are outside that boundary and need their own exposure review and patches.

Layer 2: make the origin refuse anything that skipped the check

Changing DNS to route through Cloudflare is not enough. Access enforces a policy on a specific hostname. If the gateway still answers on its raw IP address or on another hostname, an attacker can go straight to it, and Bourzikas says the policy is then "worthless." The options, roughly from strongest to weakest:

Layer 3: inspect what gets through

None of these layers removes an attacker who is already inside. The article points to Citrix's suspected-compromise guidance: preserve evidence, revoke credentials and certificates, investigate connected systems, and rebuild or restore from a known-good state.

Beyond the login page

Over time, the ICA desktop traffic itself can sit behind device- and identity-aware network access using the Cloudflare One Client. The article notes this needs its own routing and policy design. Some uses can drop ICA entirely: browser-based remote desktop to Windows hosts over Tunnel, or Browser Isolation where a virtual desktop exists only to open web apps.

Bourzikas's broader point is that whether a service is reachable from the internet should be a design decision, not a default. Consumer login pages and the identity-provider endpoints that bootstrap a session must stay public. Those need deliberate protection, and you should avoid circular dependencies, such as an access proxy that needs the very identity provider it protects.

Verify the boundary

The most broadly useful part of the article is its test plan:

• Request the protected hostname without signing in and confirm the request stops at Cloudflare.
• Sign in as a user outside the allowed group and confirm they are denied.
• Try direct origin IPs and alternate hostnames and confirm none gets around the policy.
• Sign in as an approved user and confirm login, desktop launch and reconnection all work.
• Check the policy, firewall and origin logs, not just what the browser shows.

Re-run these whenever routing, identity or failover settings change.

What to keep in mind

This is a vendor post, and every control it names is a Cloudflare product. It gives no data on how many exploited gateways sat behind any such layer, and no measurements of the latency or operational cost. The ideas carry over to other vendors, though: put an identity decision in front of pre-auth attack surface, bind the origin to that decision cryptographically, and test for bypass paths.