Fibmesh Outbound / How it works
Follow a request from your existing connection to the Fibmesh exit. Then check the route, the source address and the boundaries that still need verification.
Trace a connection Routing 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 / From request to reply
Your ISP carries WireGuard to Fibmesh. The exit forwards eligible traffic using its public source and maintains the return path for replies to that connection. Explore each leg below.
Traffic takes the ordinary internet route. The service sees the public source provided by the existing connection, which can change when you change networks.
An internet connection remains necessary in every scenario.
The supported full-tunnel profile directs eligible internet traffic to the Fibmesh exit. A stable or dedicated source requires an agreed allocation; ordinary exit routing does not promise either.
The tunnel ends at Fibmesh. HTTPS continues to protect an HTTPS session between the application and its destination.
The exit forwards replies for the established connection back through the tunnel. This does not create a public listener on your device or let a stranger start a new incoming session.
A response to your request is different from an internet-initiated connection to your device.
A local printer, a private server or an approved cloud range may use a more-specific route. Check the effective routes and platform policy; do not assume every LAN or private destination is automatically excluded.
Illustrates the intended exception. Route overlap and native-platform behaviour need deployment verification.
Encryption boundary
HTTPS or another application protocol’s encryption protects the application session beyond that point. The exit is a trusted part of the route, rather than an end-to-end encryption boundary between your device and every website.
02 / Read the policy
All current Outbound profile modes request full tunnel. The requested routes describe the intended result; the endpoint’s effective policy shows what is applied.
Destination selectors, per-application routing and per-device exit selection are not implemented in the current Outbound profile contract. When selected outgoing destinations fit better, examine the supported modes in Public IPs.
Compare Public IP traffic modes →VPN permissions, system-traffic exceptions, sleep and network changes affect the result. Verify local and private reachability. Full tunnel does not promise that every packet on every device follows the same path.
03 / Two different identities
For traffic carried by the exit, the destination sees that exit’s public source. Your endpoint may keep its private tunnel address; it does not need the public exit address installed on its interface.
A private address identifies the supported connection inside the tunnel.
203.0.113.20Example exit source. This documentation address is not an assigned production IP.
A regular exit may share its source or change it. Stable describes continuity; dedicated describes exclusivity. Either needs an agreed allocation and terms. Ordinary exit routing guarantees neither.
An allowlisted source still needs valid credentials and application permissions. Return traffic belongs to an established connection: Outbound creates no public listener or new internet-initiated access to the device.
04 / Separate checks
Verify resolver behaviour and each address family independently. Neither a default-route entry nor a tunnel handshake establishes the whole connection.
Check resolver configuration, private names and applications that use their own encrypted DNS. A full-tunnel route alone does not establish resolver choice. Private workspace DNS remains part of Networks.
Test IPv4 and IPv6 separately. Both default routes in policy do not prove that both exits are provisioned. For an unsupported family, agree explicit blocking or a clearly labelled bypass outside the tunnel.
An unsupported family left on the ISP is an exception to record and verify. It must not be silently described as complete protection.
05 / Enable, verify, disable
Plan the organisation-wide change and its recovery with an owner. Each administrative step needs a separate check of delivery and the actual endpoint.
Record the name, requested mode and optional region. Creation does not provision a working exit. A gateway or public address may still be unassigned; a requested region is not an assigned serving location.
Enabling a profile disables the organisation’s other egress profiles. Review every affected endpoint with the change owner. A one-device evaluation needs an isolated organisation or an agreed change window.
Check assigned delivery, endpoint policy and apply results, the source seen by a real destination, DNS and application behaviour. Administrative active or enabled state, or an accepted API request, does not prove a working route.
Policy intends to restore the ISP route. Open a fresh connection and verify restoration on the actual platform. Disabling does not establish address retention, release or billing terms, or delete all deployment resources.
A kill switch is not a verified current capability. Check actual interruption, ISP fallback and recovery on the supported platform. A deployment that requires guaranteed blocking needs explicit supported blocking before it proceeds. Automatic failover, seamless session continuity and simultaneous per-device exits are not promised by this profile model.
Next / Agree the exit
Outbound is available with assisted setup. Confirm the supported client or gateway, actual exit location, address families and source-allocation terms for your deployment.