Routes
Publish a site prefix through a Linux or OpenWrt device so other devices can reach it through the overlay.
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 |