01 / Identity and addressing
A device of its own. A place in your network.
- Fibmesh device ID
device-example-01- Private IPv4
100.96.1.24- Private IPv6
- Release verificationPart of the product scope. Confirm assignment support for your deployment.
Example values · Not a live enrollment
Which device is this?
A Fibmesh device ID identifies an enrollment in your organisation. Another working device gets its own enrollment. Joining another access group does not create a new identity.
How can it be reached?
An assigned private address provides a destination within the network. The IPv4 shown uses the shared 100.64.0.0/10 range, often called CGNAT address space. It is not a public IP; the address range alone does not mean the private connection uses NAT. Private workspace names make resources easier to find where supported.
What can it reach?
Backend policy determines access. Having an address, knowing a name or belonging to the same organisation does not grant access to every resource.
Enroll supported devices in the correct workspace. Each enrollment uses a local keypair; the backend receives the public key, not the endpoint private key by default. A gateway has its own enrollment, while resources behind it retain their existing local addresses.
02 / Who can reach what
The device joins. Access is granted separately.
An administrator grants access to the resources a person or device needs. The backend is the source of policy; a supported native executor validates the signed policy and applies authorised networking changes locally. The app shows state and diagnostics.
Private workspace DNS makes internal resources easier to find where supported. A resolved name is not permission, and a network connection does not sign you into the application. Keep its accounts, roles and data permissions in place.
- Workspace
- The organisation boundary for administration, enrolled devices and resources.
- Network or access group
- A grouping used to organise membership and intended private reachability. The dashboard calls these Access groups.
- Resource
- An enrolled host or a destination behind an approved gateway route. Its application permissions remain under the resource owner’s control.
Keep the group and route scope as small as the job permits. Exact enforcement and supported granularity must be verified on the deployed client and gateway; a route record alone is not proof of per-user or per-port isolation.
What changes when a device leaves?
Remove the relevant membership and revoke affected enrollments. Review observed state as well as the administrative change. Revocation is not a claim of instantaneous deletion across every offline device. Retire application accounts separately when their work ends.
03 / The actual traffic path
Follow the request. Then follow the reply.
A Fibmesh routing node is part of the service. A site gateway is the connector in your office or cloud network. An enrolled server can terminate its own tunnel; a LAN-only resource needs the site gateway to reach it.
A private connection to an enrolled host
- Your laptopOwn device identity
- Fibmesh routing nodeApproved private path
- Enrolled serverOwn device identity
The laptop sends the approved private traffic through its WireGuard tunnel. The Fibmesh routing node forwards it over the server’s tunnel. The server’s application and host firewall still decide what it accepts.
Two tunnel legs. The routing node is a trusted part of the path; application encryption protects the application session across it.
A private connection to equipment on a LAN
- Your laptopEnrolled client
- Fibmesh routing nodeApproved private path
- Office gatewayEnrolled site connector
- Office NASExisting LAN address
The client reaches an approved office destination through Fibmesh and the office gateway. The NAS keeps its LAN address and does not need a Fibmesh app. Only the agreed destination range is routed.
WireGuard protects the tunnel legs. The final gateway-to-NAS hop uses the local network; use the storage service’s own encryption where available.
The reply needs a route back to the client
- Office NASResponds to the request
- Office gatewayReturn route or supported NAT
- Fibmesh routing nodeReturn tunnel path
- Your laptopReceives the reply
The destination must be able to send its reply back through the office gateway. Use a return route, or a supported source-NAT arrangement when the LAN cannot route the client’s private address. NAT alone does not create the required routes.
With source NAT, the NAS usually sees the gateway’s LAN address. Application accounts remain necessary to identify the person using it.
Private access can leave internet traffic on the ISP
- Your laptopStarts an internet request
- Existing ISPCurrent internet route
- Public websiteOrdinary destination
In the private-resources-only configuration, unrelated internet traffic keeps the existing ISP path. Joining Networks does not automatically select an internet exit or assign a public IP.
This illustrates the private-only choice. Outbound is a separate option for changing the eligible internet route.
Where does encryption end?
WireGuard protects each configured tunnel between an endpoint and its gateway. A Fibmesh routing node terminates those tunnels and is part of the trusted path; it is not an opaque relay carrying an end-to-end encrypted peer tunnel. Keep application encryption such as HTTPS or SSH enabled. A final LAN hop needs the application’s own protection.
Can two devices connect directly?
Direct peer-to-peer connectivity is planned. The current architecture uses Fibmesh routing nodes. A future direct path will depend on compatible clients, local network conditions and approved access; neither direct connectivity nor seamless fallback is promised for every connection.
04 / Finding the resource
Use a name people can remember.
Private workspace DNS lets supported clients resolve internal resource names through the configured private resolver. The resource owner still needs a valid record, a working route and the correct application listener.
files.team.example → private resolver → 10.20.0.20
The name finds the office file server. Its approved gateway route carries the connection. The file server checks the user’s account and folder permissions.
With split DNS, selected private names use the configured private resolver; this is separate from choosing an internet exit. A name resolving successfully does not grant access. If an IP works but the name does not, check the record, resolver reachability and the client’s DNS configuration.
Private DNS is not a promise of automatic printer discovery, public DNS hosting or a browser-trusted HTTPS certificate. Confirm private-zone and record support for your deployed release.
Where traffic goes
Your private resources. Your choice of routes.
You may need only an office file server, a set of cloud destinations, or internet access through an exit. Start with that requirement, then assess the supported routing configuration.
Keep work resources private. Leave ordinary browsing on its usual path.
- Your device
- Approved private route
- Work resource
Use Fibmesh to reach the private resources you have permission to use. Other internet traffic follows the device’s existing connection.
Joining a private network does not, by itself, move all your internet traffic through Fibmesh.
Understand private access →Bring the destinations you need into reach.
- Your device
- Approved gateway route
- Office or cloud subnet
Reach selected office or cloud resources through a supported gateway. Define the destination ranges, check for address conflicts and verify the return path.
A gateway route does not grant access to an entire cloud account or remove provider firewall rules.
Explore the hybrid-cloud example →Give outgoing traffic a chosen way out.
- Your device
- Supported exit
- Internet destination
Where supported, Outbound can route internet traffic through an eligible exit. Assess the destination scope, exit location and source address your application needs.
Exit routing is a separate capability. It needs its own entitlement and supported client configuration.
Explore Outbound →Illustrative routing choices · This is not a dashboard setting. Availability and combinations depend on the product, platform and approved configuration.
Connecting cloud resources here uses existing internet connectivity. A dedicated cloud interconnect would be a separate service with its own provider arrangements and delivery requirements.
Plan a deployment
Start with one path you can verify.
Identify the resource, its owner and the devices that need access. Confirm a supported release, workspace eligibility, local firewall rules and the underlying internet connection. For a site or cloud subnet, check approved destination ranges, overlapping addresses and return routing.
Connect a device or location
Compare native clients, agents, supported gateways and the limits of manual WireGuard Compatibility Mode.
Compare device and gateway joining →Check the release
Networks is available with assisted setup. These diagrams explain the architecture; confirm supported platforms and service locations for your deployment.
Check availability →