Route private networks

Not every machine can run an agent: printers, cameras, PLCs, managed databases and appliances cannot, and there are always servers nobody will let you touch. Routing solves that: the agent runs on one device inside the network, a routing device, and everything behind it becomes reachable through it.

There are two ways to publish what sits behind a routing device. Networks and resources is the main one, and the better choice for reaching hosts and subnets: you list what should be reachable, and access rules name it. The Routes tab, described here, publishes a whole CIDR range to the groups you choose.

Internet gateways are routes too: a route to 0.0.0.0/0 is listed on the Internet gateways tab, even when you add it here. Sending internet traffic through your own gateway walks through setting one up.

Networks → Routes → Add route opens it: four screens, Route, Groups, Name and Settings, with Continue between them and Add Route at the end.

Give a route more than one routing device and devices keep reaching the range when one goes offline. There are two ways, and they differ in how you steer traffic:

• A device group as the routing device: every device in the group carries the route, with one shared metric, so none is preferred. The route's Failover column then shows Go to Devices, because you add a device by putting it in the group. Put each device of the group in the Access Group too, as in step 4.
• Several routing devices, added one at a time: create the route with one device, then choose Add Device in its Failover column for each further device, and put that device in the Access Group, as in step 4. The Add routing device sheet asks for the device and, for this entry alone, Applies to and Access Groups (optional); give it the same groups as the first. Add Route saves it with metric 9999 and masquerade on.

To prefer one routing device, give it a lower metric. Click the route's row to expand it, and choose Edit in that device's row menu. In the sheet, titled Update followed by the Network Identifier, set Metric on the Settings tab, then choose Save Changes; Masquerade is there too. The lowest metric is preferred.

Each device chooses for itself, in this order:

1. A routing device it has a live connection to beats an idle one.
2. Then the lower metric wins.
3. Then a direct path beats a relayed one.
4. Then the lower latency wins.

It moves away from the routing device it uses only for a gain of more than 10 ms, so routes do not flap. Connections that were open through the old routing device break when it moves.

Two routing devices per site are cheap insurance; the second can be a Raspberry Pi. Make sure both actually have a path to the range - two routing devices on the same switch fail together.

A device that receives a route uses it on its own; there is no accept step. Each device keeps a list of the networks it has switched off and uses everything else. A route that applies to a group therefore reaches every device in it that an access rule connects with the routing device. The route is part of the device's network map, the list of devices and routes that the management service keeps up to date on each device.

People opt out on their own device: in the apps, on the Resources screen; with the CLI, with sxaccess reach. The ID is the route's Network Identifier, or a resource's name.

sxaccess reach list shows every network published to this device as Selected or Not Selected. sxaccess reach remove stops using one, sxaccess reach add -a uses it again and keeps the others, and sxaccess reach add all uses every network, including ones published later.

Some options of sxaccess start change what a device does with routes. Check them when a route that looks right does not work; the CLI reference lists them all. start saves no setting while the device is connected, so to change one there, stop and start the agent in one command: sxaccess stop && sxaccess start --<option>. Run it as one line: a connection that goes through SXAccess, such as an SSH session to this machine, drops until start has finished. It does not work in a session opened with sxaccess shell: stopping the agent closes that session and ends the command, so use the console or an OpenSSH session.

• --disable-server-routes or --block-inbound on the routing device: it stops routing for others. --block-inbound also refuses every inbound connection, whatever the access rules allow.
• --disable-client-routes on a device: it uses no routes at all.
• --block-lan-access on the routing device: routed traffic may not reach the subnets on the routing device's own network interfaces. It is meant for an Internet gateway; on a routing device for its own LAN it blocks exactly the traffic the route is for.

Check these in order. The first three cover almost every case.

1. The device has the route. sxaccess reach list should list it with state: Selected. If it is missing, check that the device is in an Applies to group and that an access rule connects it with the routing device, for example because the routing device is in the Access Group.
2. An access rule lets the traffic in. With Access Groups set, a rule from the device's group to an Access Group must allow the protocol and port. Test with that port: under a TCP rule, ping fails even when the route works.
3. Forwarding is actually on. The agent sets it on Linux, but a hardened host or a configuration-management run can put it back. sysctl net.ipv4.ip_forward should print net.ipv4.ip_forward = 1.
4. The routing device can reach the target itself. Test the same port from the routing device, for example with nc -vz -w 5 192.168.10.20 443, before blaming SXAccess.
5. Return path. With masquerade off, the LAN needs a route back to the overlay range.
6. Host firewall on the target. It may accept its own LAN and drop the overlay range.
7. Agent options. See the options above, on the routing device and on the device that uses the route.
8. Overlapping subnets. Two routes publishing the same CIDR to one device.