Offices and branches / A site, with a deliberate connection
Keep the resources on site. Bring them within reach.
Bring selected office servers, storage and equipment within reach through a supported gateway. Choose private access, public delivery or a stable outgoing source.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / The resource stays on site
A gateway at the site.
A path to the right resource.
Start with the server, storage or equipment people need to use. A supported gateway can provide the route to selected local destinations while those resources keep their LAN addresses. Choose access and outgoing routing separately.
The gateway joins. The printer keeps its address.
- Approved teammateOutside the office→WireGuard
- Fibmesh routing nodePrivate network→WireGuard
- Office gatewayApproved LAN route→LAN
- Server / NAS / printerExisting local IP
Reach supported resources at the location without installing Fibmesh on each appliance.
Gateway enrollment does not individually enroll LAN equipment. Printer/scanner support depends on IP protocols and drivers; broadcast discovery and USB-only devices are not automatically carried across the network.
See device and gateway options →Forward selected ports to selected local services.
- External clientAssigned public IP and port→Service request
- Fibmesh public deliveryInbound firewall→WireGuard
- Site connector / gatewayTunnel and target mapping→LAN
- NVR or serverApproved LAN IP and port
A supported gateway deployment can map different public ports to different local targets. Replies to Fibmesh-delivered connections return through Fibmesh.
Ordinary LAN internet traffic keeps its ISP route unless routing is changed explicitly. The preconfigured Fibmesh Edge device approach has a customer POC; hardware remains development/pilot.
Explore Gateway IPs →Outgoing identity needs traffic to reach the gateway.
- Selected LAN devicesRoute via configured gateway→LAN route
- Customer router / gatewayExplicit traffic selection→WireGuard
- Fibmesh public sourceDelivery / exit location→Internet
- External serviceSees configured source
Give routed LAN traffic a stable public source for approved third-party access, using Public IPs or a suitable Outbound deployment.
Simply plugging a one-port connector into the LAN does not redirect the other devices’ outgoing traffic. Gateway placement, routes, return traffic and supported address families must be configured.
Explore traffic routing →The illustrations show three different gateway jobs. Enrolling a gateway does not individually enrol the equipment behind it, or make every resource reachable.
02 / Place it for the job
Beside the router.
Deliberately in the path.
A shop may need shared billing, an office may need remote files, and a service team may need an equipment interface. Plugging in a one-port connector can serve selected incoming targets. Making it the route for outgoing traffic is a separate configuration.
The existing site
Illustrative placement · paths depend on the selected configuration
Ordinary internet connections
Existing ISP router
LAN devices continue to use their existing default route unless the customer changes it.
LAN devices ISP router Internet
Selected resource connections
Supported Fibmesh gateway
A connector beside the router reaches approved local targets. For public delivery, replies must return through Fibmesh.
Fibmesh Gateway LAN target
For outgoing identity, add an explicit route.
Selected LAN traffic must reach the gateway through customer routing, policy routing or a downstream network. A one-port connector sitting on the LAN does not capture unrelated devices’ internet traffic.
Reach the office resource.
Approved staff can use supported applications, storage and IP peripherals through Networks. Permit the selected LAN destinations and keep application credentials in place. Private targets need a return route or supported source NAT.
Open the selected service.
Gateway IPs can deliver permitted public traffic to a local server or appliance. Different public ports can map to different approved local targets where supported. Keep replies on Fibmesh and keep the service firewall and application login deliberate.
Use the address a provider expects.
Route the intended LAN traffic through a suitable gateway and Fibmesh public source for third-party allowlisting. The rest can retain its existing ISP path under the chosen setup. Verify the source the external service actually sees.
03 / Choose the connection scope
One site can have
different audiences.
Keep a private file server, a public application and an outgoing source as separate decisions. Verify their combined behavior on the chosen gateway.
Compare the connection options →Private resources → Networks
Start with approved people and selected destinations. A routed connection does not make the sites one broadcast LAN.
Public service → address or web link
Public IPs supports selected address-based service access. A Publish hostname serves compatible web applications; it does not carry arbitrary equipment protocols or USB.
Internet exit → a routing change
LAN traffic must be routed to a supported gateway. Current Outbound profiles use full tunnel, with one active profile per organisation. Confirm scope and address-family support before changing the site’s internet path.
04 / From a customer deployment
Shared billing across restaurant locations.
An anonymous restaurant-chain deployment used Public IPs with full tunnel for access to shared billing. It demonstrates that address-based arrangement; it does not establish a private branch mesh.
Read the shared billing example →Demonstrated application arrangement
One billing application,
used from another location.
The application server remained at one restaurant, with access from another location. The host used Public IPs with full-tunnel routing.
- Public IPs
- Address-based application reachability
- Full tunnel
- Routing on the application host; no claim that every site device used it
- Anonymous example
- No performance figures, automatic failover or private branch-mesh inference
For your site, check the whole path.
The customer example informs one deployment pattern. Verify the devices, routes and recovery process for your own installation.
- 01Targets and people
Record each local address, protocol and port, the allowed users and the application owner. Check overlapping ranges across offices, homes and clouds.
- 02Routes in both directions
For private access, provide a return route or supported source NAT. For public delivery, keep replies on Fibmesh. For outgoing identity, explicitly route the intended LAN traffic to the gateway.
- 03Local operation and recovery
Name the site contact, keep a local administration method and record the existing router settings. A failed ISP connection or powered-off gateway still affects availability; this design does not add automatic failover.
05 / A practical first deployment
One site.
One service to prove.
Bring a local resource, the person who operates it and the intended users. Decide whether the gateway provides access to a resource, routes outgoing traffic, or does both.
- 01
Choose the first targets.
Start with one site and one useful service. List its local addresses and ports, site ranges, allowed users and application credentials. Check overlapping addresses before joining another location.
- 02
Commission both directions.
Place a supported gateway for the chosen job. Verify the private return route or supported source NAT, the public reply path, and any explicit outgoing route. Keep the original ISP configuration available for recovery.
- 03
Test with the site owner.
Use the real client from another internet connection. Check permitted and denied ports, the observed source and application login. Reconnect, restart the connector and verify local recovery before extending the deployment.
06 / Questions, answered
Before you connect.
Does plugging in a connector change all the office’s internet traffic?
No. A connector can serve selected incoming targets without becoming the LAN’s default gateway. Outgoing routing needs explicit configuration; ordinary LAN traffic otherwise follows the existing ISP path.
What was demonstrated with the preconfigured Edge device?
The customer evidence covers NVR and server reachability through a preconfigured device on the LAN. The original POC artifact configured one target; it does not demonstrate simultaneous multi-target forwarding. A supported gateway design can separately map distinct public ports to multiple targets. The Fibmesh Edge device remains a deployment option in development/pilot, not a generally released hardware product.
Can one site use both private access and public services?
Yes as a deployment design, with separate permissions, rules and supported routing. A private file server and a public application should not inherit each other’s exposure. Verify combined behavior on the chosen gateway, including the private return route and Fibmesh public reply path.
Do branch printers and scanners just appear automatically?
No. Address-based protocols and appropriate drivers may work through an approved route. Broadcast discovery, USB-only equipment and local-only software need separate handling. Test the actual printer, scanner or storage workflow before extending access.