A supported app or agent.
For a computer, mobile device or server that can run a supported native client. Each enrollment has its own identity; access is granted separately.
Explore connection methods →Fibmesh Networks / Getting started
Start with one
useful connection.
Choose a private resource, give the right devices access and test the result. Begin with one connection before adding a whole team or site.
Follow the setup steps Setup guide · Confirm platform and deployment support during assisted setup.01 / Define a useful outcome
Choose the work.
Define the boundary.
A shared folder for a colleague at home. An internal app for a project team. A private server for an engineer. Start with a familiar resource and a small group, so you can tell whether the connection is useful.
- The destination
- Record the application or device, where it runs and who owns it. Include its private name or address, required ports and application account.
- The people
- List the approved users and working devices. Include one device that should be denied access, so you can test the boundary.
- The handback
- Agree who can restore routes and firewalls. Keep a local way to administer the gateway and choose a maintenance window before making changes.
02 / Choose how to join
On the device.
Through a gateway.
A supported gateway or router.
For selected office or cloud resources. Check destination ranges, route overlap and return routing. Devices behind the gateway keep their local addresses.
Plan a location connection →Confirm the platform and version, country eligibility, workspace entitlement and administrator access. An operating system alone does not establish compatibility. Check availability & prerequisites →
03 / Put the connection together
Six steps.
One working path.
Use the software and configuration confirmed for your assisted deployment. Installation procedures and button labels depend on the released platform.
Establish the workspace.
Confirm the organisation, the administrator authorised to grant access and the resource owner. Choose the network or access group for the first connection.
Confirm:The approver and resource owner are identified.
Enrol the working device.
Install the approved client, complete its supported enrollment and check the device record. Every device needs its own identity; do not share a WireGuard private key across colleagues.
Confirm:The device record belongs to the intended workspace.
Connect the destination.
Enrol a supported server directly, or enrol the site gateway and configure the approved LAN destination. For a gateway route, check the destination range, address overlap and return routing.
Confirm:The destination and its reply path are both reachable.
Grant the intended access.
Add the approved device or identity to the correct group through the supported administration flow. Check membership, route approval and host or application firewall requirements.
Confirm:Unrelated resources remain outside the intended scope.
Check the applied policy.
Confirm that the client and any gateway received and applied the intended configuration. Record errors or skipped routes before testing. An accepted administrative request is not a successful tunnel test.
Confirm:Observed state matches the intended configuration.
Use the application.
Resolve the private name, or use the agreed address, and complete a real task with the application’s own credentials. Keep an unapproved device ready for the denied-access test.
Confirm:A real application task succeeds, such as opening and saving a project file.
For configuration and diagnosticsExplore CLI status, policy inspection & the API →
04 / Verify the result
Test the connection.
And the permission.
Record device and gateway versions, intended policy, observed results and application behaviour. A saved dashboard rule is only part of the evidence.
See how identity, policy & routing fit →Use the resource.
From an approved device, resolve the intended name, reach the resource and complete a real application task.
Test the boundary.
Try the same resource from the unapproved device. Check that unrelated destinations remain outside the granted scope.
Withdraw and check again.
Withdraw the grant or retire the enrollment, inspect the applied state and retest. Review existing application sessions separately.
Verify the way back.
End the evaluation and verify the original routes, DNS behaviour and local administration path.
When something does not work
Find the failing step.
Keep the scope small.
Start with the symptom. Check the specific path before changing the whole network.
The device is enrolled, but the resource is unreachable.+
Check the workspace and membership, applied policy, tunnel state and intended route. Registration alone is not connectivity.
The private IP works, but the name does not.+
Check the private DNS record, resolver reachability and the client’s split-DNS configuration.
The name resolves, but the application does not open.+
Check that the service is running, listening on a reachable interface and permitted by the host or application firewall. A localhost-only listener is not reachable on the tunnel address.
An enrolled server works, but a LAN resource does not.+
Check site gateway reachability, route approval, LAN firewall, address overlap and the resource’s reply path.
It works in the office, but fails on home Wi-Fi.+
Check overlapping LAN or VPN ranges, conflicting routes and other VPNs. Record the conflict instead of replacing all routes.
A mobile client stops after sleep or a network change.+
Check reconnect behaviour, platform VPN restrictions and refreshed routes and DNS. Test the actual application session separately.
Files are slow, or large transfers stall.+
Check uplink quality, latency, packet size or MTU, and the application protocol. A private network cannot remove distance or ISP capacity limits.
A removed grant still seems usable.+
Check the applied policy version, offline clients, route state and existing application sessions. Follow the supported withdrawal procedure and verify the result.
For support, keep device IDs, client versions, the destination and redacted diagnostics. Do not send private keys, session tokens or passwords.
Before you expand
Prove the first path.
Then add the next.
Do general internet connections change?
Not in the private-resources-only configuration. An internet exit is a separate choice. Test ordinary browsing and local LAN access as well as the private application when changing routing.
Can we add more people or another office?
Yes. Expand one group or location at a time using supported releases. Each site still needs its own gateway, route and overlap checks where applicable. Do not assume automatic site-to-site routing or high availability.
How do we remove access safely?
Agree the operator procedure for removing membership and routes before starting. Retire unused enrollments, verify the applied result and restore intended local routes and DNS. Application account removal is a separate action.
Your first deployment
Bring the brief.
We’ll assess the fit.
Tell us about the resource, users, device platforms, location and gateway requirements. Keep credentials and private keys out of the brief.