Conceptual scenario
Bring office resources into your wider private network.
A supported gateway or router can connect approved office, branch or lab resources to a distributed team. Follow one cloud-to-office path to understand route approval, access and the reply journey.
Explore products ↗A worked planning example, not a customer case study or a released installation procedure.
The working situation
An office service from the cloud
A cloud-hosted operations workload needs an internal office service. The service cannot run a native Fibmesh app itself. A supported gateway on the office network provides the intended bridge to the approved resource.
Approved route
The office service path
- Cloud worker
- Office gateway
- Office service
- Destination
- 10.50.20.0/24 · example range
- Approval
- Administrator-approved private route
- Return path
- Gateway and destination routing
Other sites and unrelated ranges have no route grant in this example.
Plan the destination range and the journey back.
- Source
- Approved cloud worker
- Destination
- Office-owned subnet resource
- Executor
- Supported office gateway
- Network check
- Destination range, overlap and return routing
A supported gateway or router is the deployment decision. An edge gateway is an optional proposed hardware choice; Fibmesh hardware remains in development.
Resource plan
Resource plan: the office service path
Keep a named owner on the source, gateway, range and application. Approval for this service does not add a route to another site.
Scroll sideways to compare all columns. With a keyboard, focus the table region and use the arrow keys.
| Resource | Owner | Intended boundary |
|---|---|---|
| Cloud endpoint | Cloud operations | Approved source identity |
| Office gateway | Office IT | Supported route executor |
| Approved subnet | Network administrator | Explicit destination range |
| Office service | Application owner | Destination with its own login |
| Other site | Separate network owner | No route grant in this example |
Before the route is used
Approve the destination range
Advertising a subnet starts the decision. Backend approval and the source endpoint’s local validation determine whether the intended route can be applied.
- Advertise
- Gateway owner
Advertise a legitimate office subnet that this gateway is authorised to reach. Confirm the gateway’s authority and release support before using it as the route executor.
- Approve
- Backend policy
Approve the intended private destination range for the permitted source. An access group identifies approved members; it is not the subnet range or CIDR itself.
- Check and apply
- Source endpoint
The supported native executor checks local route conflicts before applying backend policy. If a conflicting route is skipped, record that observed apply state and resolve the topology before retrying.
A broader grant cannot resolve overlapping addresses.
Permission and destination ambiguity are separate problems. Keep the intended scope while the network owner resolves conflicting private ranges.
The service test
Verify both directions
A successful advertisement does not prove a working service connection. Check the request at the office service and its reply at the cloud worker.
- Request / cloud to officeDoes the approved worker reach the service?
- Use the actual cloud identity and intended service listener. Check the approved destination range, source route state and gateway and destination firewall rules. The service’s own login still applies.
- Reply / office to cloudDoes the response return to the worker?
- Verify the destination’s return routing through the gateway and the supported return-path configuration. Record a real service response at the worker, not only a request arriving at the office.
Check the boundary around the working path.
Test an unapproved source as well as the permitted worker. Confirm that unrelated office resources, other sites and the worker’s local resources keep their intended boundaries.
Plan the end of the path
Disable the route before retiring the gateway
Agree the service dependency and the alternative operating path with the network owner before changing the gateway.
Withdraw the route.
Remove the approved path deliberately. Confirm which applications still depend on the office service before ending their access.
Observe removal.
Verify that the route is removed from backend policy and local route state. Check the resulting application reachability.
Retire the gateway.
Once removal is checked, revoke or retire the old gateway and its credentials as appropriate. No automatic handover is assumed.
Keep another way to administer the site.
The network owner needs an alternative administration and operating path during the change. Verify it before withdrawing the route that might otherwise be needed to manage the gateway.
If the result is different
Diagnose the boundary before changing it.
Find the failing route, service or lifecycle step before broadening access or removing the gateway.
The route conflicts with the worker’s existing network.
Record the conflicting ranges and skipped apply state. Resolve the topology before retrying; a broader grant cannot disambiguate overlapping addresses.
The request arrives, but no reply returns.
Inspect destination firewall and return routing through the gateway. A successful advertisement does not prove a bidirectional service path.
The gateway needs to be replaced.
Withdraw or migrate the approved route deliberately, verify the application dependency and retire old gateway credentials. No automatic high-availability handover is assumed.
Acceptance criteria
Three results worth recording.
Keep the service response, destination scope and route removal evidence together. Each answers a separate operating question.
Service response
The specific office service responds to the permitted worker.
Route scope
The approved range does not imply a public grant or arbitrary LAN access.
Gateway retirement
The private route is withdrawn and checked before the gateway is removed.
This is limited approved subnet access. It does not establish automated site-to-site orchestration, public prefixes or high availability. The example is a planning aid, not released installation instructions.
Explore Networks →