Fibmesh Outbound / Getting started
Make the first exit
a controlled change.
Agree the deployment, record the current route and verify the exit from the application that will use it. Keep the evidence and a tested way back.
Prepare the change Setup & handover guide · Confirm platform and deployment support during assisted setup.Available with assisted setup. Confirm the supported platform, source address and full-tunnel policy before connecting.
01 / Prepare
Agree the outcome.
Name the owners.
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.
- Outcome ownerWhat needs to change?
- 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.Review Public IPs →
- Change + recovery ownerWho can bring it back?
- Someone must own the routing change and recovery. Include the person who can edit the external provider’s allowlist rules. Agree the supported recovery procedure and the change window before enabling the profile.
02 / A first connection, in six steps
Prove the route.
Then make it routine.
Move from a recorded baseline to a controlled application test. Treat disable and tunnel interruption as separate checks before handing over the deployment.
- Before enabling
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.
- Assignment before assumption
Agree the actual exit
Confirm the assigned gateway, address-family support and region with Fibmesh. For a stable or dedicated source, obtain the actual address and allocation terms. A requested region is not an assigned location.
- Allowlist + authentication
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.
- Policy before proof
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.
- Use the actual worker or device
Test the application and exceptions
Run a real, controlled request from the application that will use Outbound. Verify its source, DNS, both IP families and access to required LAN and private resources.
- Two separate observations
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.
03 / Keep a small evidence record
A connected icon
cannot answer all six.
Check the actual destination and the actual platform. The application’s behaviour is the evidence that the intended route was delivered.
On a narrow screen, scroll the table sideways to read all columns.
| Boundary | Check to record | What a useful result tells you |
|---|---|---|
| Source | Source observed by the real destination | The application used the expected outgoing identity. |
| Families | IPv4 and IPv6 tested separately | Each address family follows its agreed route or blocking policy. |
| Names | Resolver and private-name tests | Names resolve through the intended configuration. |
| Exceptions | Required LAN and Networks resources | Local and private routing still works as intended. |
| Disable | Disable followed by a fresh connection | The platform restored the expected ordinary route. |
| Interruption | Tunnel interruption | Actual fail-open or blocking behaviour is known; no assumed kill switch. |
Keep / redact / attribute
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.
04 / When the result is different
Check the boundary
that failed.
Start with the observed symptom. Administrative state, a tunnel handshake and a working application each answer a different question.
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.
05 / Handover
Leave an operating plan,
not a one-off test.
Agree who can change the profile, how an assigned address is retained or retired, and who updates external allowlists. Keep the supported recovery procedure with the evidence record.
- Profile changes
- Name the authorised operator and the organisation affected.
- Source + allowlists
- Confirm address terms and the owner of the provider’s rules.
- Recovery
- Record how to disable, verify the ordinary route and recover independently.
Disabling a profile is not a documented address-release or billing operation.
Review the implemented operations first.
Review the implemented read-only CLI command and the separate API operations before writing scripts.
Read the CLI & API reference →For a managed evaluation
Bring the workload.
Agree the first change.
Share the platform, workload, preferred location, address-family needs and whether an exact public source is required. Confirm the supported deployment with Fibmesh during assisted setup.