Conceptual scenario

Connect the equipment that cannot install an app.

Bring approved access to NVRs, NAS appliances, printers, kiosks and embedded systems through a supported gateway. Keep the equipment in place and choose who can reach each service.

Request access ↗

A worked planning example, not a customer case study or a released installation procedure.

Equipment at real locations

The useful system is often the one already installed.

A security installer needs to maintain a recorder at a customer site. The recorder has a working LAN address and its own login, but cannot install a Fibmesh app. Plan a supported connector beside it and one approved service to reach.

fibmeshSites & GatewaysIllustrative product model

Approved route

A service at a customer location

Approved remote client
Site connector
Existing equipment

Equipment: Keeps its LAN address
Connection: Selected private or public service path
Customer site: Existing router and internet connection

The connector is enrolled. Downstream equipment does not automatically receive its own Fibmesh device identity.

Example configuration, not a connected account or release confirmation.

Keep the appliance in place. Define the remote job.

Equipment: The customer’s recorder, NAS, printer, kiosk or embedded system, with its existing LAN address.
Service: The actual maintenance interface or application listener. Identify its protocol and port before choosing the connection.
Operator: The authorised technician, MSP or cloud application that needs that service. Other people and services need their own approval.
Site: The customer retains the local network, internet connection, equipment credentials and a local administration path.

The connector is enrolled; downstream equipment keeps its LAN identity. A gateway connection does not automatically enroll every appliance or grant access to the whole site.

Choose access by the job

Private maintenance and public services need different boundaries.

Decide who initiates the connection and which service they need. The same site may have separate private and public requirements; each needs its own scope and application authentication.

Approved staff or service team

Private access through Networks

Use an approved private path for administration, storage, printers and equipment maintenance. Give the working device the intended resource grant and verify gateway routing, destination scope and the reply path.

The appliance retains its LAN address and application permissions. A private network grant does not supply its administrator password or automatically expose other customer resources.

Explore Networks →

An external application needs an address

Public reachability through Public IPs

Choose a public destination only for the intended service. Agree the protocol, port, permitted sources and firewall rules. Test an actual application request and its response through the supported gateway.

The equipment’s authentication remains essential. Public reachability exposes the selected service; it does not make an appliance suitable for unrestricted internet access.

Explore Gateway IPs →

Keep unrelated administration private. Neither choice automatically changes the equipment’s default internet route or creates isolation between LAN devices.

Choose how to join

Run an agent where you can. Use a gateway where you cannot.

Choose the supported role before choosing hardware. Software on the host, a connector beside existing equipment and a routed equipment network have different traffic responsibilities.

Supported compute or embedded host: Use its own app or agent where supported. Its enrollment and private identity belong to that device.
Existing LAN equipment: Use Quick Connect for selected remote access without changing the equipment’s default gateway. Confirm LAN reachability and a stable target address.
A protected equipment network: Assess a routed gateway when outbound controls or isolation are required. Traffic must pass through that gateway; two Ethernet ports alone do not establish supported policy enforcement.

Quick Connect / Selected remote access

Follow the service response back.

This placement carries the configured remote connection while the equipment keeps its existing router. Verify the supported forwarding and tunnel routing together.

Remote accessFibmesh public address

Encrypted tunnel to the connector

Preconfigured deviceFibmesh Edge deviceEthernet + power

Configured service
Forwarding + NAT

Your existing LANNVR / serverExisting private address
Existing router and gateway

Quick Connect topology · The connector carries remote-access traffic. Replies to Fibmesh-delivered connections return through Fibmesh. Unrelated internet traffic keeps the existing router; local traffic keeps its LAN routes.

Reply to the remote connection: Returns through the connector and Fibmesh. Forwarding and translation must be paired with the correct tunnel routing; NAT alone does not choose the reply path.
Unrelated new internet traffic: Keeps the customer’s existing ISP router in this Quick Connect arrangement. A separate outbound-routing requirement needs a supported traffic path through the gateway.
Local equipment traffic: Keeps its existing LAN routes. A connector beside the appliance does not become an inline firewall or an independent recovery connection.

Test the actual tool, not just the address.

Check the equipment’s protocol and the client application. Printers and scanners may need drivers or discovery support; routed reachability does not automatically extend local broadcasts. Continuous video and large transfers need a bandwidth assessment.

Confirm the supported device, gateway software and deployment method. Fibmesh Edge hardware remains in development/pilot. Review devices and gateways and current availability before planning the installation.

For vendors, integrators and MSPs

Make customer-site access repeatable.

Standardise the installation around a known connector, an approved resource and a named operator. Keep each customer’s equipment, credentials and access grants separate. The field technician and remote team should share the same service record.

Customer POC evidence

One configured LAN target.

The original Fibmesh Edge customer POC demonstrated an operator-assisted plug-in connection for existing equipment: the customer supplied Ethernet and power, and the operator configured one LAN target. The equipment kept its existing router.

Separate supported design

Distinct ports for distinct services.

Multiple services can share a gateway’s public IPv4 address through distinct protocol and external-port mappings on supported gateway software. Confirm each target and return path for the deployment. This later design is separate from the original single-target POC.

Self-service fleet claiming and multi-target portal management remain unverified development work. The POC does not establish a released fleet-management workflow or universal equipment support.

Before the technician leaves

Record a service result and a way back in.

Use the real application.
From the intended remote source, open the selected interface or run the actual client task. Verify the response, application login and expected performance.
Check the neighbouring boundary.
Try an unapproved source or unrelated service. Confirm that local equipment access and ordinary internet traffic retain their intended paths.
Withdraw and recover deliberately.
Verify local administration before removing the remote path. Remove the grant or mapping, confirm the observed result and retire old connector credentials when appropriate. Keep an on-site contact for loss of power, internet or the connector.

Use the equipment plan for the wider site, or carry the installation record into an OEM service process.

Plan equipment connectivity →Connectivity for vendors and OEMs →

Start with one site

Bring the equipment model and the access problem.

We’ll assess the protocol, local network, required users and supported deployment method. Prepare these five details for the first conversation.

Equipment: Model, operating system or firmware, and whether supported software can run on it.
Protocol: The actual service, port and client tool; include driver, discovery and bandwidth requirements.
Stable target: The intended LAN address, local reachability and who maintains that address.
Owner: The customer, permitted users, connector operator and owner of the equipment’s accounts.
Recovery: Local administrator access, an on-site contact and the plan to remove or replace the remote connection.

Choose one service to evaluate, then confirm support and access scope with Fibmesh.

Discuss equipment connectivity →