Business IT / A distributed organisation
One organisation. More places to work.
Connect approved people, offices and cloud resources over existing internet connections. Keep private access, public services and outgoing routing deliberate.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / Start with the work
One team.
One approved application.
A company’s resources no longer sit behind one office router. Start with the people who need one resource, then choose the path that serves them. The connection is useful when the application works and the access boundary holds.
Connect the organisation around the resources it uses.
- Remote employeeSupported enrolled device→WireGuard
- Fibmesh routing nodeIdentity and permitted routes→WireGuard
- Office / cloud gatewaySelected destination ranges→Private network
- Business resourcesApps, storage and devices
Networks provides a private path across existing internet connections and providers. A site or cloud gateway can bring approved subnet resources within reach.
This is routed connectivity, not one broadcast LAN or a dedicated cloud circuit. Each destination needs a working return path and the appropriate application permissions.
Explore Networks →Expose the service that needs an outside audience.
- Partner systemUses a public service endpoint→Application traffic
- Fibmesh public deliveryPublic address + firewall→WireGuard
- Business server / gatewayTunnel delivery to the target
Use Public IPs for an address-based service that an external system must reach without enrolling into your private network.
For browser-facing applications, Publish offers a hostname-based alternative. Public reachability requires authentication, patching and an explicit inbound policy.
Explore Public IPs →Choose the source external services see.
- Company device / routed LANEligible outgoing traffic→WireGuard
- Fibmesh exitSelected internet exit→Internet
- Cloud / SaaS serviceObserved public source
Outbound serves internet-routing needs. Public IPs is another option when a specific allocation or selected-destination source identity is the central requirement.
Outbound’s current profile model is full tunnel. Do not assume destination-by-destination rules, concurrent department profiles or a verified kill switch.
Explore Outbound →These are separate connection choices over supported existing internet access. A private path does not inherently reroute everyone’s browsing.
02 / Build around the organisation
Keep the resource.
Give people a path to it.
People move between locations, applications run in different clouds, and some equipment stays on site. Fibmesh gives these connections a common place to be managed, while each resource keeps its intended audience.
People and the tools they use.
Use Networks for approved access to applications, servers, storage and supported IP peripherals. People join with supported devices; sites can join through gateways. Application accounts and permissions still apply.
Offices and clouds, in their own places.
Keep resources with the providers and locations that suit them. Use supported hosts or gateways for selected private routes between working environments. Confirm destination ranges, return routing and the actual application path.
External systems, with an explicit audience.
Some integrations need to reach a server; others expect your requests from an agreed address. Use Public IPs for address-based service reachability, or assess an Outbound source for a cloud or SaaS allowlist. Choose incoming and outgoing policies separately.
03 / Choose the scope
Private access is the starting point.
Choose each additional connection for a specific job. The organisation does not need every product to begin.
Compare the connection options →Keep team resources private.
Networks supplies the approved private path. A gateway can make selected office or cloud destinations reachable; it does not turn the organisation into one broadcast LAN.
Open only the service that needs visitors.
Keep incoming public services separate from private access. Public IPs serves address-based reachability; Publish offers a hostname-based option for compatible web applications. Authentication, patching and an explicit audience remain necessary.
Make an internet exit a separate change.
Current Outbound profiles use full tunnel, with one active profile per organisation. Check the effect on staff traffic, platform and address-family support before rollout. Concurrent department exits and complete per-application routing are not assumed.
Check addressing and IPv6 boundaries →04 / Your first working result
One team reaches one approved application.
Build the first rollout around a useful working path. Verify private resource access independently from public service exposure and outgoing internet routing.
Explore working across locations →Record the request. Prove the result.
A saved configuration is a starting point for verification.
- The application works
- Requested
A representative team is approved to use one application from supported enrolled devices.
- Working result
Use the real application from another internet connection. Check its login, a useful task and the return route.
- The boundary holds
- Requested
Only the named people and destinations are permitted.
- Working result
Verify both permitted and denied resource access. Joining the network must not make an unrelated resource reachable.
- Someone can take over
- Requested
A named owner holds the recovery process and removal procedure.
- Working result
Test reconnecting, loss of connection and removal. Record how the owner can recover local access and verify that withdrawn access stops.
05 / A practical first deployment
Prove the path.
Then plan the rollout.
Bring a representative team, one resource and your network constraints. Expand from the connection you can demonstrate, with someone responsible for operating it.
Inventory people and resources.
Choose a team, supported devices, one application and any gateway. Record destination ranges, application accounts and the person responsible for the resource.
Choose private and public paths.
Start with the minimum required access. Separate resource access from internet routing; connecting a private network does not inherently reroute everyone’s browsing.
Verify and expand.
Check permitted and denied access, return routing, actual application use, loss of connection and removal. Add another site or service after that path is understood.
Keep an owner with the connection
Keep the access decision, application owner, local recovery route and removal procedure together. Recheck the working path when its people, gateway or destination changes.
Before you connect
Plan around the boundaries.
Is this a replacement for our ISP or a private leased line?
No. Fibmesh runs over supported existing connectivity. It does not provide an access circuit, dedicated cloud interconnect or a blanket performance guarantee.
Can printers, scanners and storage be reached remotely?
Supported IP services can be reached through an approved gateway route. Drivers, application support and permissions still apply. This is not automatic broadcast discovery, USB sharing or a local Ethernet extension.
Can we give different departments different Outbound profiles?
The current Outbound implementation supports one active profile per organisation. Do not assume simultaneous department-specific exits or a complete per-application routing policy.
What about identity, security and automation?
An enrolled device has its own identity; reaching a resource also requires the relevant permission and application login. Security explains the trust boundaries, and the developer reference describes current CLI/API scope. Confirm specific enterprise controls and contractual commitments before procurement.