# Routes

> Publish a site prefix through a Linux or OpenWrt device so other devices can reach it through the overlay.

Source: https://www.widewired.com/page/docs/route

## Use cases

A site route binds a site LAN IPv4 prefix to a Linux or OpenWrt device. Other desktop, server and mobile devices can then reach that prefix through WideWired.

## Creating a route

Under **Configuration → Routes**, click **New route**, select an approved Linux or OpenWrt device that can reach the target network, and fill in the fields before saving. Cancel discards unsaved input:
- **Advertised prefix**: an IPv4 network prefix, such as `192.168.20.0/24`.
- **Next hop (optional)**: leave it empty to have the selected device reach the prefix through its existing routes (for example a directly connected network, or routes a downstream router already provides) and only publish it. Fill it in to also install a route for the prefix via the gateway; the gateway must be a unicast IPv4 address in a network directly connected to the device.

The route is published to the whole network once the selected device applies it. An empty gateway needs a current device client; older clients are asked to upgrade first.

## Reading effective state

Existing routes remain available to view and delete when a device is blocked. Approve the device before creating or editing a route.

Check the **Readiness** column. **Effective** means that the site route has been applied and advertised. Application access still depends on reachability through the gateway or the device's own routes, firewalls and a working return path. The list shows short states. Click the row’s **Edit ›** action to read component status and error details in the dialog’s read-only runtime section.

Edit configuration and save in that dialog. Existing routes have a bottom danger zone: **Delete** requires confirmation and runs without another save. Creation dialogs do not offer deletion.

## Verify access

From another approved device, access a real host inside the published prefix, such as a service at `192.168.20.10` for prefix `192.168.20.0/24`. Confirm the service port as well as basic reachability. Check that the site gateway can return traffic to the source network address; a successful route save alone does not verify the remote service.

## Overlap with forwarding

Traffic to a site prefix goes to the device that advertises it by default. Only when a forwarding rule explicitly matches does the rule's action apply; the check before saving a rule flags rules that overlap site prefixes.

## Quick troubleshooting

| Symptom | Check and action |
| --- | --- |
| The target device is missing from the list | Confirm that it runs Linux or OpenWrt and is approved; actual forwarding also requires it to be online |
| The route remains non-effective | Confirm that the selected device is online and has applied the latest configuration; without a gateway, confirm the device has its own route to the prefix (a default route alone does not count); inspect the readiness reason and device health |
| Other devices cannot reach the site prefix | Confirm that the route is effective, then check gateway reachability, the site firewall and the return route |
| Overlapping traffic uses the forward exit | Narrow or remove the rule that matches the prefix under **Configuration → Forwarding** |
| An old connection remains after route deletion | New connections use the current routes; close and re-establish the old connection before testing again |