For IT departments

This page is for the IT team at an organization using siteaccess.io. It is not needed by staff who are simply connecting a laptop — they have their own instructions.

If you are the administrator who configured the identity connection, this is what is worth knowing while we finish setting things up, and what to check if a user reports a problem.

1. How your users get access

Your staff do not need to be approved before they connect. They sign in with their normal work account and their device joins the network straight away. There is no request to raise and no queue.

What is configured separately is what each person can reach. Until we set that up for your organization, a connected device will not be able to reach servers, shared drives or other systems — that is the expected first state, not a fault, and we tell your staff so on their instructions page.

You do not need to tell us who has signed in. We are notified automatically when someone authenticates for the first time and when a new device joins. Tell us what people need to reach, and we configure it.

What this means for you day to day: you keep control of who exists — access follows your own directory, so disabling someone's work account is what removes their ability to sign in. We control what they can reach on the network.

2. The most common failure: other security software

This is the one that costs the most time, and it looks like the user's mistake when it is not.

The pattern: Tailscale installs cleanly — often by you, as an administrator — and then the machine will not actually connect, or connects and no traffic flows.

What your user will report: it sits on Connecting… or drops immediately; a message about "Windows network configuration failed" or "Failed to set the network category to private on the Tailscale adapter"; or it reports Connected but nothing responds at all and stays that way. Sometimes it worked and then stopped after a security-software update.

We have hit this with Bitdefender. The same applies to any suite that ships its own firewall — Norton, McAfee, ESET, Sophos, CrowdStrike and similar.

What to change

⚠ Start here: trust the Tailscale virtual adapter — an application allow-rule is not enough. Security suites classify a new adapter as Public/Untrusted by default and then filter it hard, so the setting that actually decides this is the adapter's network profile, not the app rule. On Bitdefender, users report TCP being blocked over the Tailscale adapter even with an explicit allow rule present. If you have already "allowed Tailscale" and it still fails, this is why. Set the Tailscale adapter to the trusted/home/private profile.

Then, in the same suite:

• Allow both executables in the application firewall: tailscaled.exe — the service, which does the actual networking — and tailscale.exe/the GUI. Allowing only the GUI is a common half-fix that leaves the symptom unchanged.
• Exclude the install directory from real-time scanning if the client is being quarantined. Antivirus engines occasionally false-positive a new Tailscale release.
• Do not let the suite reset or remove the virtual adapter. If the Tailscale Tunnel adapter is deleted or cycled by another product, the service is left inoperative until it is restarted.

The partial fix that hides itself

If the suite's firewall blocks peer-to-peer traffic but allows HTTPS, connections still work — they just fall back to an encrypted relay and are noticeably slower. Users have reported exactly this after switching from Windows Firewall to a third-party firewall. It presents as "the network is slow", not as a failure, so it is worth checking even when nobody has complained about connecting.

3. Network firewall — outbound only

No inbound rules. No port forwarding. Devices only ever make outbound connections.

⚠ Read the port off your own server address — do not assume 443. Most organizations are on 443, and for them the address has no port shown. Some are on a different port, in which case the address carries it explicitly, like example.siteaccess.io:8080. Where to find your address: the go-live email we send when your account is ready carries it, and so does the connect page your staff are given. Either is authoritative; they are the same value. If you are reading this while waiting for that email, you do not have the address yet — that is expected, and the rest of this table does not depend on it. If the address shows a port, that is the port to allow; if it does not, it is 443. Allowing the wrong one blocks every device, and the only symptom your users get is a 404 with nothing naming the cause.

Relays: devices choose the closest relay by measured latency, so the list has to cover the fallbacks as well as ours. Allowing only derp1.siteaccess.io can remove the relay nearest your office and make everything slower.

Two things that are the opposite of what people expect

• Blocking UDP does not break it. If UDP is blocked entirely, traffic falls back to the encrypted relay over TCP 443. It still works, just slower. So blocked UDP is a performance problem — blocked TCP 443 is what stops it dead.
• Do not rate-limit or deep-inspect UDP 3478. Throttling STUN prevents devices from discovering a direct path, which silently pushes every device onto the slower relay. This shows up as "the network is slow", never as a firewall alert.

Also worth checking

• Another VPN client on the same machine — two virtual adapters competing for routes is a common conflict.
• TLS-inspecting proxies. If outbound HTTPS is intercepted, the client's long-lived connection to the control plane can be broken. Exempt the destinations above.
• Aggressive idle-session reaping. The client holds a long-lived connection open; devices that reap idle sessions will cause repeated reconnects.

4. When someone leaves

Disabling or removing their account in your own directory stops them signing in, which is the control that matters and stays entirely with you.

Their already-enrolled devices are a separate record on our side. Tell us when someone leaves and we will remove their devices — or ask us to remove a specific device if one is lost or replaced.

5. Getting help

When you write, telling us which device, what security software is in play, and what the client reported gets you a useful answer far faster.