Worked planning examples

Work through a real connection problem.

Plan private access, application publishing, public addressing and internet exits. Worked examples explain resources, permissions, verification and removal.

01 / Choose the job

Start with what needs
to reach what.

Each scenario names its resources, permission boundary, verification evidence and removal criteria. Choose a task, then adapt the example to your environment.

Reach the tools you work with.

Give the right person a path to a specific private resource.

  • Networks · Private access

    Reach a development machine ↗

    Developer laptop → private build host

    Plan the approved developer’s access, keep application login separate and test an unapproved identity.

  • Networks · Team permissions

    Keep team tools private ↗

    Project team → internal dashboard

    Give colleagues and a contractor the access their job needs, then withdraw network and application access at handover.

Connect resources across places.

Keep storage and compute where they belong, with a defined path between them.

  • Networks · Storage access

    Reach private storage and files ↗

    Approved device → office storage

    Choose a supported host or gateway path. Check folder permissions, saving over the connection and interrupted work.

  • Networks · Cross-provider access

    Connect hybrid and multi-cloud resources ↗

    Cloud worker → service at another provider

    Connect the selected dependency while accounting for provider firewalls, return routing and the resources outside its grant.

Choose the public-facing path.

An incoming application request and an outgoing provider connection have different needs.

  • Publish · Selected application

    Publish an app or API ↗

    External visitor → selected HTTP application

    Give a portal, webhook or review app an HTTPS entry. Keep application login, API credentials and webhook checks in place.

  • Outbound / Public IPs · Source identity

    Use a provider source-IP allowlist ↗

    Workload → external provider

    Compare Outbound with a Public IP assignment, then verify the source address the provider actually observes.

Account for a changing path.

Include the return journey and a way to restore the previous connection.

  • Networks · Optional Outbound routing

    Plan a roaming laptop ↗

    Working device → private team resource

    Check network changes, sleep and reconnect behavior. Treat an optional internet route as a separate decision from private access.

  • Networks · Gateway-backed access

    Connect an office resource from the cloud ↗

    Cloud worker → gateway → office service

    Approve the destination range, check for conflicting routes and verify replies before planning gateway retirement.

02 / Keep what you already run

Your hardware.
Your customer sites.

Some workloads belong on your own servers. Some equipment needs a nearby gateway. Start with the resource and choose who should reach it.

Networks / Publish / Public IPs

Run on your own infrastructure ↗

Local server, GPU host or colocated workload

Separate private administration from public client access. Plan migration, application checks and cutover while retaining responsibility for power, updates, backups and recovery.

Networks / Public IPs · Edge hardware development/pilot

Reach equipment and IoT ↗

Approved technician or client → existing equipment

Choose private maintenance or a selected public service for an NVR, NAS or kiosk. Assess a supported gateway where the equipment cannot run an agent.

These are planning scenarios. Supported software and hardware are confirmed for the deployment; Edge hardware remains in development/pilot.

03 / Separate managed service · Public IPs

Several workloads.
Their own public addresses.

A small hosting operator or virtualisation lab may need a public block for several servers, VMs or containers. Routed Subnets is a separately scoped, invitation-led managed service.

Illustrative delivery path

  1. Assigned public block

    Fibmesh routes the allocation over a tunnel.

  2. Your router

    Receives the block and forwards it to the workloads.

  3. Your workloads

    Use the assigned addresses with agreed firewall and return routing.

Conceptual model · not a provisioning interface.

Plan the allocation and the delivery.

IPv4 and IPv6 are separate allocations. The worked model covers small IPv4 blocks and IPv6 prefixes from /48 through /64, with firewall boundaries and return routing.

Confirm stock, country, delivery location and quoted terms with Fibmesh. Managed setup defines the assigned block and the customer router’s responsibilities.

Explore the routed-subnet model →

04 / Your next decision

Make the example
your working document.

Replace the example names with your own. A useful connection plan shows how the work starts, what stays outside its scope and how the connection ends.

  1. Name the source.

    Which person, device or workload starts the connection? Record its platform and location.

  2. Define the destination.

    Name the application or resource, its protocol and the job that must work.

  3. Assign the owners.

    Agree who approves access, runs the application and maintains the device or gateway.

  4. Choose a negative test.

    Record an identity, service or route that must remain outside the permitted connection.

  5. Plan the removal.

    Define how access ends, how the previous path is restored and what evidence confirms it.

Available with assisted setup. Confirm supported devices, locations and scope before deployment.

Planning a whole location? Explore offices and branches →

Compare the product decisions →