Bring the connection in.
Forward permitted connections to an NVR, server or other LAN service. Those connections and their replies use Fibmesh. New, unrelated internet connections keep the existing ISP path.
Fibmesh Public IPs / Gateway IPs
One public address.
Your network behind it.
Reach a LAN service, give selected outgoing traffic a stable source, or route internet traffic through Fibmesh. Choose the policy, then put a supported gateway in its path.
Choose the traffic policy Gateway deployment guide · Confirm platform and deployment support during assisted setup.Available with assisted setup. Confirm the supported platform, serving location, inventory and traffic policy for your deployment.
01 / Decide what crosses the gateway
Three traffic policies.
One deliberate choice.
Start with the connections the site needs. Incoming access and outgoing routing are independent policy decisions.
Choose a stable source.
Send selected LAN traffic to partner APIs, cloud services or approved business systems through Fibmesh. Those destinations see the assigned public address; other destinations can keep the ISP route.
Route internet traffic.
Send eligible internet traffic from chosen devices or a network through the gateway and Fibmesh. Define local-network exceptions, IPv4 and IPv6 handling, and tunnel-disconnection behaviour.
02 / Put the gateway in the right place
In the traffic path.
Or beside the existing router.
Both placements can bring permitted incoming connections to a LAN service. Outgoing traffic must actually traverse the gateway to use its public source.
A supported router,
firewall or gateway host.
Selected LAN traffic→Supported gateway→Fibmesh
For selected outbound or full tunnel, send the affected traffic to the gateway through router policy, a downstream network or explicit device routes.
With shared IPv4 source NAT, several private devices use one assigned public identity. They do not each receive a separate public IP.
A prepared Fibmesh Edge
on the existing LAN.
Fibmesh→Edge on the LAN→Selected service
Quick Connect delivers selected incoming traffic without changing the equipment’s default gateway. The existing router stays in place.
Plugging in Edge does not redirect outgoing traffic. Selected outbound or full tunnel needs a supported routing configuration that sends that traffic through Edge.
WireGuard is the only supported tunnel.
Use a Fibmesh-supported WireGuard-capable router or gateway, or a preconfigured Fibmesh Edge device. WireGuard support alone does not establish router compatibility. Edge hardware remains a development/pilot deployment option.
Confirm address-family support.
Single-address delivery can be dual-stack or IPv6-only on supported deployments. This does not establish public IPv6 forwarding on Edge; the original Edge proof of concept excluded public IPv6. Use Routed Subnets for separate public addresses or downstream prefixes.
03 / One address, distinct public entries
Different ports.
Different LAN services.
The external and internal ports can differ. Two servers listening on TCP 443 can have distinct public entry ports.
Client connects to
203.0.113.24:8443Gateway forwards to
10.20.0.10:443NVR HTTPS interface: public TCP 8443 maps to TCP 443 on the recorder. Video or native clients may need other ports and protocols.
Documentation addresses. Each address + protocol + public port selects one target. The application supplies its authentication and, for HTTPS, its certificate.
See all three example mappings
| Public entry | LAN destination | Service example |
|---|---|---|
203.0.113.24:8443TCP | 10.20.0.10:443 | NVR HTTPS interface |
203.0.113.24:9443TCP | 10.20.0.20:443 | Server HTTPS application |
203.0.113.24:22222TCP | 10.20.0.30:22 | Partner SFTP server |
One entry selects one target.
The public address, protocol and external port identify the mapping. Plain NAT cannot send the exact same entry to two targets. Use different external ports, separate public addresses, or an application-aware proxy where the protocol supports it.
NAT does not select a target by hostname or supply HTTPS certificates. Confirm that the chosen gateway software supports multiple targets and the required TCP or UDP mappings.
Test beyond the login page.
Reserve platform management ports, restrict permitted caller sources and retain application authentication. Some equipment advertises addresses, negotiates extra connections or uses several TCP and UDP ports.
A reachable login page does not prove video, native clients or every device feature works. Prefer private access through Networks for administration that does not need a public endpoint.
04 / A customer proof of concept
The router stayed.
The service became reachable.
The customer needed remote access to NVRs and servers. Their existing router could not connect directly to Fibmesh.
We supplied a preconfigured Fibmesh Edge device. The customer connected Ethernet and power, and we configured the selected target remotely. The equipment needed no client installation, and the existing router stayed in place.
The original proof of concept reached a single target using destination NAT (DNAT) and LAN-side masquerading, with a reserved management port. The three mappings above illustrate a separate configuration; they were not tested together in that proof of concept.
Remote accessFibmesh public address
Encrypted tunnel to the connector
Preconfigured deviceFibmesh Edge deviceEthernet + power
Configured service
Forwarding + NAT
Forwarding + NAT
Your existing LANNVR / serverExisting private address
Existing router and gateway
Existing router and gateway
05 / Follow the incoming connection and its reply
Reach the LAN service.
Bring its reply back.
Quick Connect needs both forwarding and a verified return path. Follow the example, then compare an unrelated outgoing connection.
First, the supported device or gateway establishes its WireGuard tunnel to Fibmesh over the existing ISP connection.
- External client198.51.100.50
- Fibmesh203.0.113.24Assigned public address
- WireGuard deliveryYour gatewayForward the selected port
- LAN application10.20.0.20:443Existing private address
Forwarding example203.0.113.24:9443 → 10.20.0.20:443
The gateway translates the selected public destination to the LAN server. In this Quick Connect example, LAN-side source NAT makes the server reply to the gateway.
Separate connectionDevice / LAN → existing router → ISPUnrelated outgoing traffic in the inbound-access preset
Replies to Fibmesh-delivered connections need the Fibmesh return path. Gateway NAT alone does not select it. Selected outbound and full tunnel deliberately change the covered outgoing routes.
The reply comes back to Edge.
Destination NAT selects the LAN service. In this plug-in design, LAN-side source NAT makes the service reply to Edge. Connection tracking reverses the translations, and routing policy sends the response back through WireGuard and Fibmesh.
NAT rewrites an address or port; translation alone does not choose the outgoing interface. The gateway must keep the return path for each connection.
The ISP still has its job.
In this inbound-only setup, new, unrelated outgoing connections use the existing router and ISP. Local traffic keeps its existing LAN routes.
Selected outbound or full tunnel changes the routes covered by that separate policy. A reply to an incoming connection is part of that connection, not an unrelated outgoing request.
What source address does the LAN service see?
With LAN-side source NAT, the equipment normally sees Edge’s LAN address as the caller. Preserving the visitor’s real source address needs a different return-route design. Account for this in application logs and source-based access rules.
06 / Plan the deployment
Start with the job.
Verify both paths.
For an office needing an approved source, an integrator supporting equipment, or a vendor reaching a customer-site service: agree the permissions, supported gateway and traffic policy for that site.
- 01
Choose the job.
Name the services that need incoming access, destinations that require a stable source, or devices whose internet traffic should use Fibmesh. Agree the customer’s permission to connect and expose each service.
- 02
Place the gateway.
Use a supported router or gateway, or connect a prepared Edge device to power and a reachable LAN. Agree the routing changes needed for selected outbound or full tunnel.
- 03
Set the rules.
Keep LAN target addresses stable. Configure permitted caller sources, forwarding mappings, outgoing routes and address-family handling. Reserve management ports and retain application authentication.
- 04
Test the real paths.
Verify every mapped service and its replies from an external permitted client. Check rejection of excluded callers, the public source seen by selected destinations, ISP routing for excluded traffic, and tunnel disconnects and recovery.
Next / Your gateway setup
Bring the network.
Choose its public path.
Tell us which services need incoming access, which destinations need a stable source, and what gateway the site can run. We’ll scope the supported setup with you.