Before changing a route
Start with a supported deployment and a clear reason.
Outbound is available with assisted setup. Confirm the supported client or gateway, service location and provisioned exit with Fibmesh. This guide explains the checks; it does not provide an installer or a self-service setup flow.
Name the outcome
A different internet path, a stable source for a provider, or an exclusive outgoing address. If only one destination must change, review Public IPs before choosing Outbound’s full-tunnel scope.
Name the change owner
Someone must own the routing change and recovery. For an allowlist, include the person who can edit the external provider’s rules. Do not rely on the connection you are changing as your only recovery path.
Current scope: enabling a profile replaces the organisation’s active egress profile. A small test requires a suitably isolated organisation or a reviewed change window; selecting one laptop in a plan does not isolate the backend change.
A first connection, in six steps
Prove the route before making it routine.
Record the baseline
Check the current public source, IPv4 and IPv6 connectivity, resolver and required LAN or private resources. Keep the supported recovery instructions to hand.
Agree the exit
Confirm the assigned gateway, address-family support and region. For a stable or dedicated source, obtain the actual address and allocation terms. A requested region is not an assigned location.
Prepare the destination
Where a provider checks source IPs, have its owner add the confirmed address. Keep the old rule during the agreed change window when appropriate. Preserve application authentication.
Enable through the supported workflow
Check organisation scope, enable the intended profile, and allow the native service to apply authorised policy. Observe the applied version and result; an administrative success response alone is insufficient.
Test the application and the exceptions
Run a real, controlled request from the actual worker or device. Verify its source, DNS, both IP families, and access to required LAN and private resources.
Test disable and recovery
Disable during the test window and verify ordinary routing returns. Separately test tunnel interruption using the agreed procedure. Re-enable only after the intended behaviour is understood.
Keep a small evidence record
A connected icon cannot answer all of these.
Swipe the table sideways to see all columns.
| Check | What a useful result tells you |
|---|---|
| Source observed by the real destination | The application used the expected outgoing identity. |
| IPv4 and IPv6 tested separately | Each address family follows its agreed route or blocking policy. |
| Resolver and private-name tests | Names resolve through the intended configuration. |
| Required LAN and Networks resources | Local and private routing still works as intended. |
| Disable followed by a fresh connection | The platform restored the expected ordinary route. |
| Tunnel interruption | Actual fail-open or blocking behaviour is known; no assumed kill switch. |
Record the platform, client version, profile ID, assigned source and test time. Redact tokens, keys and application payloads. A generic browser IP check on a different machine does not prove the worker’s route.
When the result is different
Check the boundary that failed.
The destination still sees the ISP address.
Check the actual device and application, active organisation profile, assigned gateway, policy version and apply result. Test IPv4 and IPv6 separately. A cached record or a connected control channel does not prove the data path.
The profile is enabled, but internet access stops.
Confirm that an exit was provisioned and is reachable. Inspect the tunnel handshake, underlying connection and route application. An enabled profile with no assigned gateway or usable source is not ready. Use the agreed recovery procedure rather than changing routes blindly.
IP connections work, but names do not.
Check DNS configuration and resolver reachability. Compare ordinary public names with private workspace names. A resolver problem and a failed exit route need different fixes.
The API accepts the address but rejects the request.
Inspect application credentials, account permissions, provider policy and the response. A correct source-IP allowlist does not replace authentication.
The office printer or private service disappears.
Check local subnet overlap and the effective private or LAN routes after enabling the exit. Confirm the intended exception on the actual operating system. Do not solve it by assuming all local traffic is automatically excluded.
Another device changed exits too.
The current active profile is organisation-wide. Review the affected endpoints, switch back using the approved workflow and use an isolated evaluation scope for subsequent tests.
Traffic uses the ISP when the tunnel drops.
A kill switch is not a verified feature of the current Outbound release scope. If ordinary ISP fallback is unacceptable, stop the deployment until an explicit, tested blocking policy is available for the platform.
Choose how to operate it
A clear handover beats a one-off successful test.
Agree who can change the profile, how an assigned address is retained or retired, and who updates external allowlists. Disabling a profile is not a documented address-release or billing operation.
For a managed evaluation
Share the platform, workload, preferred location, address-family needs and whether an exact public source is required.
Request access to Outbound →For automation
Review the implemented read-only CLI command and the separate API operations before writing scripts.
Read the CLI & API reference →