Start with an organisation and its resources
Imagine a team with laptops in different cities, a build server in a cloud account and file storage at the office. Their Fibmesh workspace is the place to organise those resources and decide which connections are allowed.
Enrolled devices
A laptop and build server have their own device identities. Private addresses identify their network interfaces; credentials prove their enrollment.
Site gateways
The office gateway has its own identity. It provides approved paths to LAN resources without enrolling every printer or server.
Access and products
Grant private access with Networks. Add a public address, a Publish application or an Outbound profile only where needed.
What gets an identity?
An enrolled device or gateway has its own identity. Networks associates enrolled devices with private addressing, including a private IPv4 address from the shared CGNAT range and private IPv6 within the product scope. Verify automatic IPv6 assignment against the deployed release. An IP address is a routing identifier; possession of an address alone does not authenticate a device.
The office gateway has a separate identity from the laptops. A storage appliance or printer reached through that gateway does not automatically become an enrolled Fibmesh device.
The objects you will work with
| Object | What it means in this example |
|---|---|
| Workspace | The team’s administration and ownership boundary |
| Device or server | Each enrolled laptop and the build server |
| Gateway | The enrolled machine carrying approved traffic to office resources |
| Access group | The people and resources that need a particular private connection |
| Private subnet route | The approved office address range reachable through the gateway |
| Public allocation | A separately assigned public address or routed subnet |
| Publication | A selected web application and hostname in the Publish design |
| Outbound profile | The organisation’s chosen full-tunnel internet-routing policy |
Joining an access group does not create a new device IP for each group. Grant the connections a person needs, and retain the application’s own accounts and permissions.
Saving a setting and applying it are different steps
- Request the change. An administrator selects the resource and permitted behaviour.
- Approve the policy. The backend checks scope and prepares the intended configuration.
- Apply it locally. The supported endpoint or gateway changes its networking within platform constraints.
- Check the result. The resource reports success, partial application, rejection or failure. Test the actual connection too.
“Desired state” is the approved plan. “Observed state” is what the resource last reported. If a change is pending or the resource is offline, the dashboard setting alone does not prove delivery. “Latest Sync” refers to that exchange of policy and reported results.
Add only the capabilities the resource needs
The build server may need private access only. A separate public address might be needed for an external integration. Publish is an available option for sharing one web app. Outbound changes eligible internet traffic to use a chosen exit. These are independent decisions; enrolling a server does not automatically make it public.
Remove access deliberately
Remove private membership when someone leaves. Retire an unused publication or allocation separately. Check that the change was applied, then remove obsolete application accounts and credentials. Network permission and application permission have separate owners and lifecycles.
Plan a first network with a clear test →