> For the complete documentation index, see [llms.txt](https://docs.gotempest.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gotempest.app/connections-and-ssh/macos-local-network-permission.md).

# macOS: "No route to host" on Your Own Network

If Tempest reaches the internet but every server on your own network fails with "No route to host" on macOS, it is missing the Local Network permission. Here is how to get it back.

On macOS, Tempest needs the **Local Network** permission to reach servers on the same network as your Mac — home lab boxes, office machines, NAS units, anything on `192.168.x.x`, `10.x.x.x` and so on.

Without it, connections fail in a way that is easy to misread:

* SSH, VNC, RDP and Mosh to a **local** address fail immediately with `Failed to connect: No route to host`
* The internet still works — remote servers, the Tempest sync account, updates
* Your router's own address and your Mac's own address also still work, because macOS exempts them from the check
* The same address connects fine from the built-in Terminal app

The giveaway is that **only other machines on your own network** break, while everything else is fine.

## First: make sure Tempest was asked

macOS grants this permission through a one-time prompt — **"Tempest would like to find and connect to devices on your local network"** — which appears the first time Tempest tries to reach a local address after launch.

1. Quit Tempest completely (⌘Q, not just closing the window).
2. Open it again.
3. Connect to a server on your network.
4. When the prompt appears, choose **Allow**.

The prompt is only offered once per launch, so if you dismissed it or never saw it, quitting and reopening gives macOS another chance to ask.

## If you already answered "Don't Allow"

Re-enable it here:

**System Settings ▸ Privacy & Security ▸ Local Network ▸ Tempest**

## If the prompt said "Electron" instead of "Tempest"

This was a real bug, fixed in **Tempest 3.16.5**. Earlier versions shipped an executable whose internal Mach-O identifier was shared with every other app built on the same Electron release. macOS keys this particular permission on that identifier rather than on the app's signature, so if another such app was already installed, macOS attributed Tempest's request to *that* app:

* the permission alert was titled **"Electron"** instead of "Tempest" — and allowing it granted the permission to the wrong identity, so nothing changed
* or no alert appeared at all, if that other identity already had an answer stored
* either way Tempest never appeared under System Settings ▸ Privacy & Security ▸ Local Network

In practice this affected people who had a second app built on the exact same Electron version — most often developers, since a checkout of Tempest itself contains one.

**Update to 3.16.5 or later**, then quit and reopen Tempest and connect to a local server. The prompt will now correctly say "Tempest".

## If Tempest is not in the list at all

Another reason macOS may never ask is that Tempest is not running from where you think it is. macOS runs an app from a randomized temporary copy — rather than from its real path — when the app was never *moved* into place: launched straight from the `.dmg`, unzipped and run from Downloads, or put in place by a script that copied it.

To check, run this in the Terminal app while Tempest is running:

```sh
ps aux | grep Tempest | grep -o AppTranslocation
```

If it prints `AppTranslocation`, quit Tempest, drag it into the Applications folder (the shortcut in the disk image window is there for exactly this), eject the disk image, and open it from Applications. If it is **already** in Applications, moving it is still what clears the condition: drag it out to the Desktop and back in.

{% hint style="info" %}
Tempest detects this at startup and offers to move itself for you.
{% endhint %}

## Check the server is actually reachable

Rule out the network itself using the built-in Terminal app (not Tempest):

```sh
nc -G 3 -z 192.168.1.50 22   # replace with your server's address and port
```

If that fails too, the problem is the network or the server rather than a permission — check that the machine is powered on, is on the same network, and is not blocking the port.

Note that your router's address and your Mac's own address keep working even without the Local Network permission, so they are not useful as a test.