Three traffic options
Reach your LAN. Use a stable outgoing IP.
Bring connections to your services.
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.
Give chosen traffic a stable source.
Route selected LAN traffic through Fibmesh so partner APIs, cloud services and approved business systems see the assigned public address. Other destinations can keep the ISP route.
Use Fibmesh for internet access.
Route eligible internet traffic from the chosen devices or network through the gateway and Fibmesh. Define local-network exceptions, IPv4 and IPv6 handling, and what happens if the tunnel disconnects.
Incoming access is a separate firewall choice. You can combine it with selected outbound: accept connections to an office server and let that server call a partner API from the same public address. An outbound-only setup denies new incoming connections while allowing replies.
Compare the traffic presets and their requirements →Choose the gateway placement
Use your router, a dedicated gateway or a Fibmesh Edge device.
A gateway in the traffic path
Use a supported router, firewall or gateway host for inbound access, selected outbound or full tunnel. For outbound policies, affected LAN traffic must reach that gateway through router policy, a downstream network or explicit device routes.
With a shared IPv4 source, source NAT lets several private LAN devices use the assigned public address. They share that public identity; it is not a separate public IP for each device.
A plug-in Edge device
When the existing router cannot run the tunnel, place a preconfigured Fibmesh Edge device on the LAN. Quick Connect brings selected incoming traffic to local services without changing their default gateway.
Plugging it in does not redirect the site’s outgoing traffic. Selected outbound or full tunnel needs a supported routing configuration that sends that traffic through the Edge device.
Connection requirement: WireGuard is currently the only supported tunnel protocol. Use a Fibmesh-supported WireGuard-capable router or gateway, or connect a preconfigured Fibmesh Edge device to your existing LAN.
Single-address delivery can be dual-stack or IPv6-only on supported deployments. The IPv4 port-forwarding example below does not establish IPv6 forwarding support on every Edge device. Use Routed Subnets when workloads need separate public addresses or downstream prefixes.
One address / Several services
Send different ports to different servers.
A gateway can map distinct public ports to services on different LAN devices. The external and internal port numbers can differ, so two servers listening on the same local port can each have a separate public entry.
203.0.113.24:844310.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 · TCP 8443 | 10.20.0.10 · TCP 443 | NVR HTTPS interface |
| 203.0.113.24 · TCP 9443 | 10.20.0.20 · TCP 443 | Server HTTPS application |
| 203.0.113.24 · TCP 22222 | 10.20.0.30 · TCP 22 | Partner SFTP server |
Each public address, protocol and external port identifies one mapping in this example. Confirm the chosen software supports multiple targets and the required TCP or UDP mappings. Reserve management ports, limit permitted sources and retain each application’s authentication.
Can two servers share the same external port?
Plain port forwarding cannot distinguish two targets with the same public address, protocol and external port. Use different external ports, separate public addresses, or an application-aware proxy where the protocol supports it. NAT alone does not select a server by hostname or provide HTTPS certificates.
Will the service work after changing its external port?
Check its client and protocol. Some applications advertise addresses, negotiate additional connections or use several TCP and UDP ports. A reachable login page alone does not prove every feature works. Prefer private access through Networks for administration that does not need a public endpoint.
Customer proof of concept
Their router stayed. Their equipment became reachable.
A customer needed remote access to NVRs and servers, but the existing router could not connect directly to Fibmesh. We supplied a preconfigured Fibmesh Edge device. The customer connected Ethernet and power; we configured the target addresses remotely.
The equipment became reachable without installing a client on it or replacing the router. This operator-assisted proof of concept demonstrated the plug-in access path. The multi-server port mappings above are a configuration example, not a claim that the original POC tested that configuration.
Encrypted tunnel to the connector
Forwarding + NAT
Existing router and gateway
Quick Connect / Follow the replies
Connections arriving through Fibmesh return through Fibmesh.
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.
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 remote-access connection
Fibmesh delivers the connection to the Edge device. Forwarding sends it to the selected LAN service. In this plug-in design, LAN-side source NAT brings the reply back to the Edge device, which returns it through the Fibmesh tunnel.
The gateway must maintain that return path for each connection. Translation alone does not choose the outgoing interface.
The equipment’s other traffic
New, unrelated internet connections continue through the existing router and ISP. Local traffic keeps its existing LAN routes. Neither needs to pass through the Edge device in this inbound-only setup.
If you separately enable selected outbound or full tunnel, the traffic covered by that policy also uses Fibmesh.
What source address does the LAN server see?
With LAN-side source NAT, the server normally sees the Edge device’s LAN address. Preserving the remote client’s source address requires a different return-route design. Keep this in mind for application logs and source-based access rules.
NAT means network address translation: the gateway rewrites an address or port as a connection crosses it. Destination NAT selects the LAN service; source NAT can make the gateway appear as the caller to that service.
A one-port connector does not isolate equipment from its LAN or provide an independent recovery connection when the ISP fails.
Putting it to work
Start with the services and destinations that matter.
- 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.
- 02 / Place the gateway
Use a supported router or gateway, or connect a prepared Edge device to power and a reachable LAN. Agree any routing changes needed for outbound traffic.
- 03 / Set the policy
Keep LAN target addresses stable. Configure permitted sources, forwarding mappings, outgoing routes and address-family handling.
- 04 / Check both paths
Verify every mapped service and its replies. Check the public source seen by selected destinations, ISP routing for excluded traffic, and tunnel-disconnection behaviour.
This works for an office needing an approved source address, an integrator supporting equipment, or a vendor connecting to a customer-site service. Each deployment needs its own permissions and supported gateway configuration.
Explore equipment and IoT use cases →