Direct devices and gateway targets
Reach the equipment through a deliberate path.
An operator reaches a local equipment interface.
- Approved operatorSupported enrolled device→WireGuard
- Fibmesh routing nodePermitted private path→WireGuard
- Site gatewayApproved LAN destination→LAN
- Installed equipmentExisting IP and management tool
Networks provides the path to the approved target while the equipment keeps its local address and management software.
The gateway is enrolled; the LAN appliance is not automatically enrolled. Application login, destination permissions and a return route or supported source NAT remain necessary.
Compare devices and gateways →One public address can serve different local targets.
- External applicationPublic IP + chosen port→Service request
- Fibmesh public deliveryInbound rules→WireGuard
- Site connectorMap each allowed public port→Target mapping
- NVR or local serverSelected LAN IP + service port
A supported mapping can send one public port to an NVR service and a different port to a local server. Only intentionally selected services belong on this path.
Replies to Fibmesh-delivered traffic must return through Fibmesh; unrelated LAN traffic keeps its ISP path. The preconfigured Edge hardware option remains development/pilot.
Explore Gateway IPs →A device calls an external service from a known source.
- LAN equipmentStarts an API request→LAN route
- Configured gatewayRoutes the selected traffic→WireGuard
- Fibmesh public sourceAssigned address / suitable exit→HTTPS
- External APISource check and device credentials
Use a supported outgoing routing arrangement when the external system expects a known source address. The equipment continues to authenticate with its own credentials.
A one-port connector does not automatically reroute LAN traffic. A shared gateway source identifies the outgoing connection point, not each individual appliance.
Plan equipment outgoing identity →For the teams operating installations
Keep the equipment. Improve the connection.
A recorder at a branch, a kiosk in a store and a NAS in a remote office have different jobs, but the same practical question: how can the right person or system reach them? Start with the service the equipment already exposes, then choose a private path, a public endpoint or an outgoing source.
Reach maintenance interfaces privately
Use Networks to give approved operators or technicians a path to supported administration and diagnostic services. Keep application login in place and limit access to the equipment needed for the task.
Private equipment access →Connect existing LAN appliances
Use a supported gateway for equipment that cannot run an agent. NVRs, NAS appliances, printers and kiosks keep their local addresses; only approved destinations need to be reachable.
The gateway deployment pattern →Connect equipment to external systems
Use Public IPs for a selected incoming service or a known outgoing source. A routed gateway can support devices whose external API expects requests from an allowlisted address.
Outgoing identity →An outgoing route requires traffic to reach the gateway; plugging in a connector does not redirect the site. Publish requires a compatible web application, not a raw video stream, proprietary protocol or USB device. Compare the connection options →
Demonstrated deployment pattern · Pilot
A gateway beside the equipment already in place.
A customer POC connected a preconfigured Fibmesh Edge device to a LAN, then made an NVR and server reachable through configured targets. Edge hardware remains in development/pilot.
- Existing NVR and server retained their LAN addresses
- Selected targets were configured remotely
- Hardware release and fleet management remain separate
A practical first deployment
Make one installation easy to support.
Record the equipment and protocol
List the model, firmware, local address, ports and management application. Decide whether it can run supported software or needs a nearby gateway. Reserve stable local target addresses.
Set the permitted path
Name the authorised people and systems. Configure approved private routes or public port mappings, host and gateway firewalls, and the return path. Keep unrelated LAN traffic on its intended route.
Test operation and recovery
Use the real maintenance tool. Check restart behavior, loss of internet, denied access and withdrawal. Record the local recovery method and remove stale enrollments or mappings when equipment is replaced.
For continuous video, large backups or time-sensitive interaction, test the real bandwidth and latency requirements. Remote connectivity does not guarantee the equipment’s performance or remove the need for someone who can recover it locally.
Operating the installation
What changes for the equipment?
Does every appliance get a Fibmesh device identity?
Only individually enrolled devices have their own Fibmesh enrollment identity. A gateway has its own identity; ordinary appliances behind it retain their local addresses and application identities. They do not become enrolled just because the gateway joins.
Does the router need to run WireGuard?
The supported connector or gateway must run the tunnel software. The existing ISP router can remain in place if the network permits the required traffic and the deployment has working LAN and return routes. WireGuard is the currently supported tunnel protocol.
Can several servers share one gateway public IP?
A supported port-mapping deployment can direct distinct public ports to different local IP-and-port targets. The same public IP, transport protocol and port cannot independently identify two destinations without another multiplexing mechanism. Review Gateway IPs.
Will outgoing equipment traffic also use that public address?
Only if the intended traffic is routed through the gateway and the configured service supports that outgoing mode. Replies to Fibmesh-delivered incoming requests must return through Fibmesh. Ordinary LAN internet traffic otherwise retains its existing ISP path.
Is this a fleet-management or remote-control system?
Fibmesh supplies connectivity. Telemetry, diagnostic commands, firmware updates and remote desktop require the equipment’s own supported software. Self-service fleet claiming and automatic lifecycle orchestration are not established by the customer POC.
Can this carry printer discovery or safety-critical control?
Routed IP reachability does not automatically carry local broadcast discovery or USB protocols. Printers and scanners need compatible IP services and drivers. Industrial and safety-critical control require separate suitability and failure assessments; no certification or deterministic timing is implied.
Bring one equipment model, its local network and the task your operator needs to complete. We can assess a direct or gateway deployment.
Plan an equipment deployment →