Tailscale issues

Symptom: you can't reach a kiosk over Tailscale. Could be:

• The dashboard's Tailscale IP field is blank for this sign
• The device shows up in the Tailscale admin console but you can't ping its tail-IP
• You can ping but RDP / VNC connection is refused
• The kiosk used to be reachable; isn't anymore

This page assumes you've followed Tailscale integration for the image build and Remote access for using it. If those weren't completed during the image build, the kiosk is not on Tailscale at all and needs to be re-imaged.

Quick diagnostic

Three checks tell you which layer is broken:

1. Tailscale admin console. Does the device show up? Is it tagged tag:displaysync-sign? Is it marked as expired?
2. From your laptop: ping <kiosk-tailscale-ip>. Does it respond?
3. From the kiosk (if you have any access — local KB, or via venue LAN): tailscale status. What's it report?

The combination of these three points the way.

The dashboard's Tailscale IP field is blank

DisplaySync reads tailscale ip -4 on every heartbeat. A blank field means either Tailscale isn't running on the kiosk, or the kiosk app can't read its output.

On a freshly cloned sign, give it five minutes first. The boot-time join task on your image waits for the venue network before attempting a join, so a clone's first enrollment can lag its boot by one to five minutes. Past that, it's a real failure.

Read that task's log before anything else — on an imaged kiosk it usually names the problem outright: a successful join, a named failure, or nothing at all for this boot (which means the task never ran — check that it's still registered).

Check from kiosk PowerShell:

# Service running?
Get-Service Tailscale | Select-Object Status, StartType

# Tailscale CLI works?
& "C:\Program Files\Tailscale\tailscale.exe" status

# Tail-IP assigned?
& "C:\Program Files\Tailscale\tailscale.exe" ip -4

Device shows up but ping doesn't respond

Tailscale auth + service are fine, but the device isn't reachable.

Most common cause: Tailscale ACL.

In the Tailscale admin console → Access Controls, run the ACL Tester:

• From: your laptop's tailnet identity (or you@example.com)
• To: the kiosk's hostname or tail-IP
• Port: the protocol you're testing (e.g., 3389 for RDP, 5900 for VNC, 22 for SSH)

If the test reports denied, your ACL doesn't grant your source-tag access to tag:displaysync-sign. Update the policy file — see Tailscale integration → ACL pattern.

Other causes if ACL is fine:

• Both sides on Tailscale exit nodes — exit nodes can mask peer-to-peer routing. Disable exit-node usage on either side.
• Tailscale's MagicDNS confusion — try the raw 100.x.y.z IP instead of the hostname.
• Your client side is paused — check the Tailscale tray icon on your laptop; toggle off/on.

Auth key expired

Tagged devices don't need re-authentication, but if the original auth key you minted has expired, you can't onboard new clones — they'll fail to register.

Symptom: new kiosks (clones, fresh provisions) appear in the kiosk app's logs with tailscale up: auth key expired. Existing kiosks already on the tailnet are unaffected.

Fix: mint a new auth key in the admin console and update your image / USB recovery kit to use it. Old kiosks keep working with their cached node identity.

If it isn't the key, it's the cap. Every new clone coming up with a blank Tailscale IP, all at once, partway through a provisioning run, is the other shape of this failure: your plan's device limit (100 on the free plan). Enrollment hard-stops there and the symptom is identical from the dashboard's side. Check the device count in the admin console against the number of machines you've booted — if it's sitting exactly at the cap, raise the plan rather than hunting for a key problem. Signs already on the tailnet are unaffected either way.

One device entry flapping between machines

Symptom: the admin console shows a single device whose IP, hostname, or online status keeps changing, and two or more signs fight over the same Tailscale IP in the dashboard.

Cause: two machines are running the same node identity — a disk was cloned and nothing reset the copy. Tailscale has no way to tell them apart; whichever connected last owns the entry.

Fix, on the clone: check whether the image's boot-time join task is present and what it decided on the last few boots:

Get-ScheduledTask | Where-Object { $_.TaskName -match "Tailscale" }

If it isn't there, the image was built without it — either add it and reboot, or apply the manual reset under Re-onboarding a kiosk below. Delete the stale device entry in the admin console once each machine holds its own identity.

A sign rejoined as a brand-new device on its own

Symptom: a sign that was working shows up as a second, new entry in the admin console, and its old entry goes stale.

Cause: the join task fingerprints the hardware — typically the BIOS serial plus a NIC MAC — to tell a reboot from a clone, so changing the network adapter changes the fingerprint: a swapped NIC, an added USB Ethernet dongle, sometimes a dock. The task reads that as "this disk moved to new hardware" and enrolls fresh.

Impact: harmless while the auth key is still valid — delete the stale entry and carry on. After you've revoked the key post-event, a machine in this state can't rejoin, so avoid adapter changes on deployed signs, or re-stage a key first.

Used to work, now doesn't

The kiosk was reachable yesterday; today it isn't. Common causes in order of likelihood:

If the venue firewall changed under you, that's a venue IT issue — sometimes resolved by a polite ping to the venue. Bring the Network requirements page; it documents the Tailscale destinations specifically.

What tailscale status on a sign does and doesn't prove

Run tailscale status on a kiosk and you'll see a list of peers — quite possibly every admin device on your tailnet. That reads like the sign can reach all of them, which would mean your isolation grants aren't working. They probably are.

That list is the set of peers allowed to reach the sign: the sign holds their keys so it can accept connections they initiate. It says nothing about what the sign is permitted to open on its own. Signs that are outbound-only to the internet and unreachable-initiating on the tailnet still list every admin device that's allowed to reach them.

To actually test isolation, use one of these instead:

• The ACL Tester in the admin console → Access Controls: source = the sign (or its tag), destination = whatever you think it shouldn't reach, plus the port. This evaluates your policy directly and is the authoritative answer.
• A plain connection attempt from the sign — ping 100.x.y.z, or a TCP probe like Test-NetConnection 100.x.y.z -Port 3389. If your grants are right, it fails.

Don't use tailscale ping for this. It tests the tunnel layer underneath ACL filtering, so it succeeds between peers that your policy forbids from talking — a misleading pass. It's a fine tool for "is the WireGuard path healthy," and the wrong tool for "is this sign locked down."

A related non-problem: a team member (not an admin) running tailscale status on their own laptop sees only the signs and their own devices, not the whole tailnet. That's Tailscale trimming each device's view to what its grants allow — not a sign missing from your fleet.

Tailscale up but RDP / VNC connection refused

Tailscale ping works (kiosk is reachable), but the actual remote-desktop protocol doesn't connect.

For RDP:

# On the kiosk: is RDP running and listening?
Get-Service TermService | Select-Object Status
Get-NetTCPConnection -LocalPort 3389

# Is the firewall allowing RDP on the Tailscale interface?
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Format-List DisplayName, Enabled, Direction, Profile

For VNC:

The VNC server is whatever you installed (TightVNC, etc.). Failures are usually password-related or service-state-related:

Get-Service tvnserver | Select-Object Status
Get-NetTCPConnection -LocalPort 5900

If the service isn't running, restart it. If it is and connections refuse, the bind-IP is wrong (it should match the kiosk's Tailscale IP, which can change after a major Tailscale update — see Remote access → Path B).

Interpreting tailscale netcheck output

Run & "C:\Program Files\Tailscale\tailscale.exe" netcheck (Windows) or sudo tailscale netcheck (Linux) to see the kiosk's view of its Tailscale connectivity.

Key fields:

If UDP: false and you'd like direct UDP, open UDP/3478 (STUN) and UDP/41641 (WireGuard) outbound at the venue firewall — see Network ports → Tailscale (optional but recommended).

Connection drops every few minutes

A working connection drops mid-session. Common causes:

• Wi-Fi roaming on the kiosk — Tailscale handles this gracefully but RDP/VNC don't, and the session breaks. Wired Ethernet fixes it.
• Tailscale relay (DERP) routing — peer-to-peer failed and you're going through a relay; relays are reliable but introduce more failure paths. Run tailscale netcheck on the kiosk to see whether direct connection is possible.
• Idle timeout — some VNC servers disconnect after N minutes of inactivity. Configure or accept the disconnect.

Tailscale isn't reaching the venue at all

tailscale netcheck from the kiosk reports it can't reach any DERP relay or coordination server. This means the venue is blocking Tailscale outbound:

• Coordination: controlplane.tailscale.com (HTTPS 443)
• DERP relays: *.derp.tailscale.com (HTTPS 443)
• Direct peer (preferred): UDP 41641

Diagnose:

Test-NetConnection controlplane.tailscale.com -Port 443

If that fails, venue IT has blocked Tailscale. Get them to allowlist the destinations in Network requirements → Tailscale.

Re-onboarding a kiosk

When the device's Tailscale state is genuinely broken (service crashes on start, identity corrupted) the cleanest fix is to re-onboard:

# Tailscale service down
Stop-Service Tailscale

# Wipe Tailscale state
Remove-Item "C:\ProgramData\Tailscale" -Recurse -Force

# Bring service back up
Start-Service Tailscale

# Re-authenticate with a fresh auth key
& "C:\Program Files\Tailscale\tailscale.exe" up `
  --authkey "tskey-auth-NEW-KEY-HERE" `
  --hostname $env:COMPUTERNAME `
  --unattended

The device gets a new node identity in your tailnet — admin console will show two entries until you delete the old one.

On a kiosk built from the image, you can skip the last command. Stop the service, delete C:\ProgramData\Tailscale, and reboot: the boot-time join task sees an unjoined machine and re-enrolls it with the key already staged on the image — as long as that key hasn't been revoked yet.

Orphan device record after auth-key reuse: if you re-onboard a kiosk using the same Tailscale auth key (or a fresh key minted from the same tag), the kiosk's old device record stays in the Tailscale admin console. New record appears alongside; old one shows as offline and never recovers. Cleanup: in the Tailscale admin console → Machines → find the kiosk by hostname (e.g. sign-<serial>) → Remove. Wait ~60s for tailnet propagation before the dashboard reflects the cleanup.

Leaving orphan records is harmless but accumulates clutter and counts against tailnet device limits on free plans.

Still stuck

Capture per Getting support:

• tailscale status and tailscale netcheck from the kiosk
• The Tailscale admin console's view of this specific device (screenshot)
• The ACL tester result for your source → kiosk → port
• Get-Service Tailscale and the last 50 lines of the Tailscale Windows Application log