01 / Choose the job
Make it something people actually need.
A shared folder for a colleague working from home. An internal app for a project team. A private server for an engineer. Choose one familiar resource and a small group so you can tell whether the connection is useful.
Networks is available with assisted setup. Confirm the supported platform and workspace with Fibmesh before installation. This guide explains the checks; it does not provide an installer or a self-service enrollment flow.
Name the destination
Record the application or device, where it runs and who owns it. Include its private address or name, required ports and the account needed to use it.
Name the people
List the approved users and working devices. Include one device that should be denied access: it gives you a useful boundary to test.
02 / Choose how to join
A device joins for itself. A gateway connects approved resources behind it.
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.
Understand connection methods →A supported gateway or router
For selected resources on an office or cloud network. Check destination ranges, route overlap and the return path. Devices behind the gateway keep their existing local addresses.
Plan a location connection →Confirm platform and version support, country eligibility, workspace entitlement and who can administer the host or gateway. A device’s operating system alone does not establish compatibility.
Compare supported devices and site gateways →Check availability and prerequisites →03 / Put the connection together
Enrol, grant access, connect and verify.
Use the supported software and configuration confirmed for your assisted deployment. These are the operational steps; button labels and installation procedures depend on the released platform.
Establish the workspace and administrator
Confirm the organisation, the person authorised to grant access and the resource owner. Identify the network or access group for the first connection.
Enrol the working device
Install the approved client, complete the supported enrollment and check the device record. Each device needs its own identity; do not share a WireGuard private key across colleagues.
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.
Grant the intended access
Add the approved device or identity to the correct group using the supported administration flow. Check membership, route approval and local/application firewall requirements. Keep unrelated resources outside the intended scope.
Check the applied configuration
Confirm that the client and any gateway have received and applied the intended policy. Record errors or skipped routes before testing the resource. An accepted administrative request is not a successful tunnel test.
Use the application
Resolve its private name, or use the agreed address, and complete a real task with the application’s own credentials. Keep a second, unapproved device for the denied-access test below.
Keep a deployment record
A plan your IT team can act on.
Use this example as a starting point. Replace the names and scope with your own; it is an evaluation worksheet, not a configuration file.
Example: two colleagues and an office file server
- Useful outcome
- Two authorised colleagues can reach the project file server from outside the office.
- Resource and owner
- Office file server; the IT team owns its accounts, permissions and backup.
- Connection
- Approved laptops through Fibmesh to the selected resource behind a supported office gateway.
- Permission
- Only the intended users, destination and file-sharing protocol. Other office resources remain outside scope.
- Traffic choice
- Private resource access for this evaluation. General internet traffic keeps its existing path.
- Success and handback
- Open and save a test file, deny an unapproved device, then remove access and check the result. Record who restores the original routes.
Keep a local way to administer the gateway during testing. Agree a maintenance window and rollback steps before altering routes or firewalls.
04 / Verify the result
Test the permission as carefully as the connection.
- Allowed
Use an approved device to resolve the intended name, reach the resource and complete a real application task.
- Denied
Try the same resource from the unapproved device. Check that unrelated destinations remain outside the granted scope.
- Removed
Withdraw the grant or retire the enrollment, inspect the applied state and test access again. Review existing application sessions separately.
- Restored
End the evaluation and verify the original routes, DNS behaviour and local administration path.
Record the device and gateway versions, intended policy, observed result and application behaviour. A saved dashboard rule is only one part of that evidence.
See how identity, policy and routing fit together →When a connection does not work
Check the failing step before changing the whole network.
| What you observe | What to check first |
|---|---|
| The device is enrolled but cannot reach the resource | Correct workspace and membership, applied policy, tunnel state and the intended route. Registration alone is not connectivity. |
| The private IP works but the name does not | Private DNS record, resolver reachability and the client’s split-DNS configuration. |
| The name resolves but the application does not open | The service is running, listening on a reachable interface and permitted by the host/application firewall. A localhost-only listener is not reachable on the tunnel address. |
| An enrolled server works but a LAN resource does not | Site gateway reachability, route approval, LAN firewall, address overlap and the resource’s reply path. |
| It works from the office but fails on home Wi-Fi | Overlapping LAN/VPN ranges, a conflicting route or another VPN. Record the conflict instead of replacing all routes. |
| A mobile client stops working after sleep or a network change | Client reconnect behaviour, platform VPN restrictions and refreshed routes/DNS. Test the actual app session separately. |
| Files are slow or large transfers stall | Existing uplink quality, latency, packet size/MTU and the application protocol. A private network cannot remove distance or ISP capacity limits. |
| A removed grant seems to remain usable | Applied policy version, offline clients, route state and existing application sessions. Use the supported withdrawal procedure and verify the result. |
Keep device IDs, client versions, the destination and redacted diagnostics for support. Do not send private keys, session tokens or passwords.
Do my 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 you change routing.
Can I add more people or another office later?
Yes, expand the intended network 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 the intended local routes and DNS. Application account removal is a separate action.
Your next step
Bring the brief. We’ll assess the fit.
Include the resource, users, device platforms, location and gateway requirements. Keep credentials and private keys out of the brief. Expand to another team or location once the first evaluation meets its agreed criteria.
Request access to Networks →