From request to reply
Follow a connection through the exit.
Your existing ISP carries the encrypted tunnel to Fibmesh. At the exit, traffic is forwarded to the internet using the exit’s public source address. The exit maintains the return path for replies to that connection.
Without the Fibmesh exit
- Your deviceStarts the request
- Existing ISPOrdinary public source
- Internet serviceSees the ISP-side source
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.
A new exit over the connection you already have
- Your devicePrivate tunnel identity
- WireGuard over your ISPEncrypted tunnel to Fibmesh
- Fibmesh exitPublic outgoing source
- Internet serviceSees the exit source
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.
A reply comes back through the same exit
- Internet serviceReplies to the exit source
- Fibmesh exitMatches the outgoing connection
- WireGuard tunnelCarries the response back
- Your deviceReceives the application reply
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.
An approved specific route can keep its own path
- Your deviceLocal or private destination
- Effective route policyMore-specific approved path
- Local or private resourceSeparate from ordinary internet traffic
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.
WireGuard protection ends at the exit. HTTPS or another application protocol’s encryption protects the application session beyond that point. The Fibmesh exit is a trusted part of the route, not an end-to-end encryption boundary between your device and every website.
What the profile changes
Full tunnel means a broad route, with explicit exceptions.
The current policy requests IPv4 and IPv6 default routes through the exit: 0.0.0.0/0 and ::/0. That is the routing intent. A working exit, address-family support and native policy application still need verification.
- Internet destinations
- Eligible internet traffic follows the exit once the supported full-tunnel policy is applied.
- Local and private resources
- More-specific approved routes may keep their own path. Verify LAN, Networks and cloud routes rather than assuming they bypass the exit.
- The tunnel itself
- The connection to Fibmesh still needs the underlying ISP. Platform and control traffic require explicit routing treatment.
Destination selectors and per-application routing are not implemented in the current Outbound profile contract. For a public address with selected outgoing destinations, examine the supported modes in Public IPs.
Native platforms differ. VPN permissions, system-traffic exceptions, sleep and network changes affect the actual result. “Full tunnel” must not be read as a promise that every packet on every device takes the same path.
The address at the far end
The destination sees the exit, not your hotel Wi-Fi address.
For traffic carried by the exit, the destination sees the public source supplied by that exit. Your endpoint can keep a private tunnel address; it does not need the exit’s public IP installed on its interface.
A private address on the supported connection.
Example exit source · documentation address only.
A regular exit may have a shared or changing source. Use an agreed stable or dedicated allocation when an exact address matters. An allowlisted source still needs valid credentials and application permissions. It does not grant internet-initiated access to the device.
A route is only part of the connection
Check names and both address families.
DNS has its own policy
A full-tunnel route alone does not prove which resolver is used. Check resolver configuration, private names and applications that use their own encrypted DNS. Private workspace DNS remains part of Networks.
IPv4 and IPv6 need working exits
A policy containing both default routes is not proof that both address families are provisioned. Test each. Where one is unsupported, agree whether it is blocked or deliberately left outside the tunnel; do not silently describe that as complete protection.
Enable, verify, disable
The profile is an instruction. Traffic is the evidence.
Create a profile
Record the name, requested mode and optional region. A new profile starts disabled; creation does not provision a working exit.
Enable with an owner
The current control plane keeps one active egress profile per organisation. Enabling another disables the previous profile. Review all affected endpoints before switching.
Verify the connection
Check assigned delivery, applied policy, observed source, DNS and application behaviour. An enabled record is not a connection test.
Disable and check restoration
Policy intends to restore the ordinary ISP route. Verify it on the actual platform. Disabling a profile does not establish address retention, address release or billing terms.
A kill switch is not a verified current capability. Automatic failover, seamless session continuity and simultaneous per-device exit selection are not promised by this profile model.
Use the setup and verification checklist →