Reach a private network from the bot's computer

What this does for you

Your bot's computer can reach a private network you already use, such as your company's intranet behind a VPN or a mesh network, once a networking client runs on the computer. The network policy still decides every destination: the client gives the computer a route, not a way around the policy.

Before you start

• You have the networking client's sign-in for the bot's computer, for example a pre-authorised key that your network's admin issued for a server.
• You know the names of the hosts the bot needs on that network.
• If your organisation uses an allowlist-only network policy, ask an admin to add the client's coordination hosts (the client's own sign-in and relay servers) and the internal hosts the bot needs. Until they are listed, the client refuses to connect, and the refusal names the host it tried.

Steps

1. Install and start the client on the computer. Ask the bot to install your networking client (it may install packages) and bring it up with your key. The client creates its own network interface on the computer's tun device, which every computer has. Bringing an interface up needs root on the computer: until bots may run commands as root, a client that runs only as root cannot be started this way.
2. Check the route. Ask the bot to open an internal page, for example https://wiki.corp.example. The bot's browser and its shell commands reach it through the computer's proxy, which follows the client's route.
3. Keep the policy in charge. A host your network policy does not allow stays refused, even when the client could reach it. Add hosts under Network policy in Organisation → Policies as usual.

What stays closed

• Private addresses the client does not route. The computer's own private network, other computers and the cloud provider's metadata address stay refused, and the refusal says the address is inside the private network.
• Loopback and link-local addresses. No route opens them.
• A route through the client for everything (an exit node) does not open private addresses; only the networks the client names do.
• Programs that ignore the proxy settings. A raw connection from the bot's shell is refused by the computer's packet filter. Only the computer's proxy, which applies the network policy, reaches outside.

On the home edition

Your home computer has the tun device too. The packet filter for programs that ignore the proxy settings needs the container to have the network-admin capability, which the home installer does not grant; without it, the computer starts and its log says that raw connections are not held to the network policy. Hosted computers always have the filter, and do not start without it.

What can go wrong

• "egress denied by policy: … is not in this organisation's network policy": the host is not allowed. Ask an admin to add it.
• "egress denied: … is inside the private network, which no network policy mode reaches": the client does not route that address. Check that the client is up and that your network advertises the range.
• The client cannot sign in: under an allowlist-only policy, its coordination hosts must be listed first.