Worked resource plan
An office service from the cloud
- Source
- Approved cloud worker
- Destination
- Office-owned subnet resource
- Executor
- Supported office gateway
- Network check
- Destination range, overlap and return routing
Work through the situation
A network path that includes the reply.
An office, branch or lab joins through a supported gateway or router that provides approved private subnet access. An edge gateway is a proposed hardware option, not a required appliance; Fibmesh hardware remains in development.
In this example, a cloud-hosted operations workload needs an internal office service. The service cannot run a native Fibmesh app itself. A gateway on the office network is the intended bridge to the approved resource.
Resource plan: the office service path
| 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 |
Approve the destination range
The gateway owner advertises a legitimate subnet. Backend policy approves the intended route. The source endpoint checks local conflicts before applying it. An access group is not the same thing as a subnet range.
Verify both directions
Check release support, gateway authority, overlapping private ranges, firewall rules and the service’s return path. Test the approved cloud identity and an unapproved source. Confirm that unrelated office and local resources keep their intended boundaries.
If a conflict causes the route to be skipped, record that observed result and resolve the topology. Broadening access does not correct an ambiguous destination range.
Disable the route before retiring the gateway
Withdraw the approved path, verify removal from policy and local route state, then revoke or retire the gateway as appropriate. Confirm no application dependency still relies on it. The network owner needs an alternative operating path during the change.
This scenario is limited approved subnet access. It does not claim automated site-to-site orchestration, public prefixes or HA. Networks explains the current boundary.
If the result is different
Diagnose the boundary before changing it.
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.
- 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 a worked planning example, not a customer case study or a released installation procedure.