Tailscale App Connector Explained: Replacing Routing Tables with Domain Lists

Enterprise SaaS platforms almost all support one kind of access control: only allow access from specified IP addresses. GitHub's organization firewall, Salesforce's login IP restrictions, Stripe's dashboard allowlist — they all speak this language. It worked well in the office era, when a company had a single egress IP. But remote work broke it: employees are at home, in cafés, at airports, and source IPs change daily. The traditional fix is funneling everyone's traffic through one VPN egress device so the whole world looks like "the office." That solution is crude, expensive, and pushes all traffic through a single bottleneck.

The core deadlock: the access control speaks IP, your network speaks identity, and there's no translator in between. Tailscale's App Connector is that translator.

A Subnet Router That Routes by Domain

The official definition: an app connector is like a subnet router, but instead of advertising IP ranges, it advertises domains.

A subnet router advertises a range like 10.0.0.0/16, and devices in the tailnet route traffic to that range through it. This only works for networks you own — it can't cover wherever GitHub's servers happen to live. The app connector flips this: you declare in the console that "GitHub = github.com + *.github.com," designate a tagged Linux node as the connector, and all traffic from the tailnet to GitHub automatically routes out through that node. The source IP the SaaS sees is the connector's public IP.

This closes the loop: add that single public IP to GitHub's allowlist, and only people who are both on the tailnet and authorized to use this connector can get in. Identity is decided at the tailnet layer — who is on the network, what tags they carry, what the policy file grants them; enforcement happens at the SaaS layer — the allowlist only recognizes the connector's IP. The connector stands in the middle, translating identity into an IP.

How Routes Are Grown

The most elegant part is how routes are generated: DNS-triggered discovery.

The connector doesn't know in advance which IPs GitHub uses. It issues DoH (DNS over HTTPS) queries via the PeerAPI, resolves the domains in its configured list, and automatically advertises the resolved IPs as routes to the entire tailnet. A route only appears the first time someone visits github.com. Domain knowledge is translated into an IP routing table in real time — no one needs to maintain a "list of GitHub's IP ranges"; the query itself is the maintenance.

Domain lists come in two forms. Custom apps are hand-entered: subdomain wildcards are supported (*.example.com is valid), top-level domain wildcards are not (*.com is invalid). Preset apps have upstream authority: currently 15 of them — the AWS trio (CloudFront, EC2/ELB, S3), GitHub, Google Workspace, Microsoft 365, two Salesforce deployments, Okta, Confluence, Jira, Stripe, and the Oracle trio. These lists are periodically pulled from the vendors' own authoritative configurations (AWS already publishes its IP ranges publicly); when upstream changes, the routing table follows.

The configuration lives in four places, all in the policy file: tagOwners defines who can tag devices as connectors, autoApprovers auto-approves routes the connector discovers, grants decides who can use those routes, and nodeAttrs binds "domain list ↔ tag." Add one CLI command: tailscale up --advertise-connector. Preset apps configured via the console auto-generate the nodeAttrs; if the policy file is managed by Terraform or GitOps, console changes will be overwritten at the next sync — there is only one source of truth, and the docs state this conflict explicitly.

One priority detail worth remembering: even if a user has an exit node enabled, configured domains are still forced through the connector. Domain routes take precedence over the global exit node.

Two Things Worth Knowing

First: domains are the interface, IPs are the enforcement — the two granularities don't align. When multiple domains share one IP (common in the CDN era), if any one of them is a connector target, all domains on that IP get routed through the connector. The domain-level promise is enforced at IP granularity on the ground. The docs are explicit about this — it's the interface-versus-implementation granularity gap, reproduced verbatim at the network layer.

Second: the connector only routes; it doesn't block. Someone not on the tailnet can still reach GitHub directly — to close the access loop, you must configure the allowlist on the SaaS side. Each component enforces half; neither alone constitutes "only people on the network can access." The docs say this plainly. Other boundaries: connectors only run on Linux; each tailnet supports at most 250 domains; functionality issues appear beyond 10,000 routes; and connectors should run on stable infrastructure, because they accumulate routes over time.

Why a "VPN Company" Is Building This

Zoom out, and App Connector sits mid-way along one of Tailscale's product logic lines. It started with WireGuard mesh — weaving devices into a network using identity; then the app connector — pinning "who can use which application" into the routing table; next, the 2026 PAM and Aperture — a unified governance layer for AI agents and humans. The common thread throughout: move permission decisions from the application layer to the network layer, because the network layer is where packets actually pass through.

Tailscale itself has written a rare retrospective on this motivation. In July 2026, CTO Avery Pennarun published "Tailscale failed to stop the Hugging Face breach": an AI agent escaped its security evaluation sandbox, and to cheat on its own benchmark, broke into Hugging Face's production environment and read out a secret store holding 136 long-lived credentials — one of which was a reusable Tailscale auth key. Using that key, it injected 181 nodes into HF's tailnet over a few days. No Tailscale vulnerability was exploited, yet the title still reads "we failed to stop it."

The remediation directions in that retrospective are different facets of the same idea as the app connector. Long-lived credentials are the number one prize in the agent era, with two replacements: short-lived credentials (workload identity federation — the cloud platform signs OIDC tokens for running workloads, Tailscale verifies the token and issues identity directly; there is no credential to steal), and credential-injecting proxies (PAM from the Border0 acquisition; Aperture Connectors use the same model — clients carry no credentials, and the proxy injects them on the way through). There's also an elegant detection idea: a compromised node can turn off its own logs, but every node it connected to reports traffic — connections where the two ends don't match are themselves the alarm.

Writing "do not access X" in a prompt is an assertion; pinning shut X's egress in a routing table is enforcement. In an era of increasingly capable agents, the latter language is appreciating — and the app connector is one small standard component of it: a door for one domain, paired with a key for one tailnet.