Choose the connection method
Join directly, or reach a resource through a gateway.
Enrol a device
Your working device joins in its own right.
- Laptop or desktop
- Phone or tablet
- Server or compute
Install the appropriate Fibmesh software on a supported device and enrol it in your organisation. Each enrollment has its own identity and approved access.
Connect a location
A gateway brings approved resources within reach.
- Office or branch
- Cloud subnet
- Lab or studio
Connect a supported gateway, approve the destination ranges and set access. Resources behind it can stay on their existing network without running their own Fibmesh client.
A directly enrolled device can be a working client, a resource host, or both, depending on its platform and policy. A server might provide an internal application while also connecting to another private service. A mobile client is not assumed to be an always-on server or a site gateway.
Identity and reachability
An enrolled device and a reachable resource are different things.
The laptop is enrolled
It has a Fibmesh device ID, local key material and assigned private addressing. Its identity and membership let the platform determine the intended access. Each additional working device needs its own enrollment.
The printer is behind a gateway
The gateway has the Fibmesh enrollment. The printer remains a LAN resource, reached through an approved route to its existing address. It does not automatically get a Fibmesh device ID or a new private address.
Adding a route makes a destination reachable within the approved configuration. It does not turn every device in the range into a managed endpoint, install software on it or replace its authentication.
Understand identity, addresses and permissions →Connecting an existing network
Put the gateway where it can reach the resource.
Remote laptop: 100.96.1.24
Office gateway: 10.20.0.2 on the LAN
File server: 10.20.0.20 on the LAN
Approve the file server’s destination. Verify the tunnel, local firewall and the reply to the remote laptop.
- Destination scope
- Choose the individual host or subnet the supported configuration needs. Check for clashes with home, office, cloud and other VPN address ranges.
- Return path
- The resource must route its reply through the site gateway. A supported source-NAT deployment may avoid a new LAN return route, at the cost of hiding the remote source IP from the resource.
- Gateway placement
- The gateway needs local access to the destination and a working internet uplink. It need not become the default router for every LAN device just to provide selected incoming private access.
Using that gateway for LAN devices’ outgoing internet traffic is a different requirement: those flows must actually be routed through it. Plugging in an additional device does not redirect the rest of the network’s traffic.
A customer router, supported host or virtual machine can fill the site role where the release supports it. A preconfigured Fibmesh Edge device is a deployment option in development or pilot, not a promise of generally available hardware.
Plan an office or branch deployment →Match the method to the resource
Start with what needs to connect.
| Device or location | Joining approach | What to confirm |
|---|---|---|
| Laptop or desktop | Supported native app | Exact operating-system release, installation rights, existing VPNs and route/DNS behaviour. |
| Phone or tablet | Supported mobile client | App availability, VPN permissions, background behaviour, sleep and reconnection after Wi-Fi or cellular changes. |
| Server or cloud VM | Supported agent or native endpoint | Service ownership, host firewall, service listener and unattended operation on that release. |
| Office, branch or cloud subnet | Supported router or gateway host | Destination routes, address overlap, provider/local firewall and replies back through the gateway. |
| NAS, NVR, printer, scanner or IoT equipment | Approved gateway route, or a verified native agent if available | Stable LAN address, required protocol, application credentials and driver support. |
| Container workload | Supported host/gateway path, assessed for the container network | Network namespace, privileges, address translation and reachability from the tunnel host to the container. |
This is a deployment guide, not a claim that every listed platform has a released client. WireGuard support on a router alone does not establish full managed Fibmesh compatibility.
Check released platforms and availability →Will office printers and scanners appear automatically?
Not necessarily. Networks carries approved IP traffic; it is not a shared Ethernet segment. Configure a compatible printer by address or supported name and install its driver where needed. Discovery broadcasts, USB-only devices and vendor-specific scanning workflows need separate assessment.
Do I need an incoming port open on my home router?
The supported client initiates its tunnel towards Fibmesh. Home-router port forwarding is not normally required for this gateway-based path. The local network must permit the required tunnel traffic; restrictive firewalls or blocked UDP still need assessment.
Can another VPN run alongside Fibmesh?
That depends on the operating system, routes and DNS settings. Some platforms restrict simultaneous VPNs. Check both clients and test for overlapping private ranges before relying on the combination.
WireGuard and Compatibility Mode
The tunnel protocol is only one part of joining.
WireGuard is the currently supported tunnel protocol. A managed Fibmesh client also handles identity, policy and observed state through its supported local service. Its private keys stay on the endpoint by default.
A manual WireGuard profile is Compatibility Mode. It is subject to workspace policy and does not imply the same policy updates, diagnostics or lifecycle behaviour as a managed native endpoint. Confirm the limitations and removal procedure before selecting it for a router or appliance.
Compare managed clients and Compatibility Mode →Set up your first private connection →