One host / several reasons
More than a way in.
A destination for a service
Accept file transfers, application calls or other supported traffic on a server you operate. Clients connect to the assigned public address and the port you permit.
A source an allowlist recognises
Send selected connections to a partner API or business system from the assigned address. Incoming access can remain blocked.
An identity across access networks
Keep the reserved address separate from office broadband, home Wi-Fi or a mobile hotspot. Connection changes may require the tunnel and application sessions to reconnect.
Choose the job, then the platform
Different devices need different kinds of reachability.
- Servers and cloud VMs
- Public application endpoints, file transfer and partner connections. Direct assignment keeps the routed address on the supported host.
- Laptops and workstations
- A consistent outgoing source for approved systems, or a deliberately exposed development service. Keep everyday traffic on the ISP if only selected destinations need Fibmesh.
- Mobile phones
- Evaluate outgoing identity on supported clients. Background operation and VPN behaviour depend on the OS; mobile public service hosting is not part of the v1 ingress scope.
- IoT and embedded devices
- Join directly where a supported agent can run. Otherwise use a gateway to reach the equipment’s existing address.
Direct delivery
A routed address, without address translation at the endpoint.
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 devicePublic address on this host
Destination at the device203.0.113.24:443 — no destination NAT
The assigned public destination stays the same inside the tunnel and at the endpoint. The application must listen on that address or an appropriate interface; a localhost-only listener is not automatically reachable.
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.
Fibmesh carries the assigned public IP through an encrypted WireGuard tunnel to the supported device. The access ISP may use NAT for the outer tunnel; that is separate from whether the assigned public address is translated.
Choose dual-stack or IPv6-only delivery. Select incoming rules and outgoing routing independently. The application still needs a listener, correct source-address selection, host firewall rules and its own authentication.
Understand direct delivery and routing choices →Example: a partner’s SFTP connection
For a supported SFTP server on TCP port 22, allow the partner’s agreed source range and retain SSH authentication and file permissions. Ordinary outgoing traffic can stay on the ISP; an optional selected-outbound rule can send partner API calls through the same assigned public address. This is a configuration example, separate from the full-tunnel customer deployments below.
From customer deployments
Keep the server. Change how people reach it.
Restaurant operations
More than one location. One billing system.
Separate billing servers had left a restaurant business managing each location on its own. The business wanted a shared system and a clearer view of transactions.
Billing was consolidated onto one server at one restaurant. A Fibmesh Public IP made that server reachable from the other location, so both could use the same application while the server stayed on the business’s premises.
Software on customer premises
The ERP stays on site. Its address comes from Fibmesh.
An ERP provider installed its software on Windows servers at customer sites. Making each installation reachable meant working around the local ISP’s static-IP options and availability.
Fibmesh ran directly on those servers and supplied their public addresses over the existing internet connections. The software stayed on customer hardware, with an address supplied independently of the site’s broadband provider.
How these deployments were configured Both used Public IPs with full-tunnel routing on the application host. The diagrams show access to the applications; the hosts’ eligible outgoing internet traffic also used Fibmesh. This does not describe the routing of every device at each site.
While you use it
Keep the reservation. Change the connection.
The public IP is an address, not proof of a user’s identity. A remote caller still needs permission to use the service. Your Fibmesh device ID and private network addresses remain separate from this public allocation.
Pausing an assignment retains its address reservation while delivery is withdrawn. Resuming uses that reservation; releasing it gives up the address. Update DNS records and external allowlists before release. A serving-region change needs a separate address review.
The encrypted tunnel protects traffic between the endpoint and Fibmesh. Continue to use application encryption for the rest of the journey. IP allowlisting complements authentication; it does not replace it, including for bank-approved corporate access.
Before your first connection
A listener, a rule and a return path.
For incoming access, the app must listen on the assigned address or an appropriate interface; an app bound only to localhost needs a deliberate forwarding setup. Permit only the required protocol, port and sources. For outgoing identity, confirm the destination sees the assigned address.
Follow the setup and verification guide →Your first device
Bring the device and the destination.
Tell us its operating system, whether you need incoming or outgoing access, and the address family your clients require. We’ll confirm release availability, platform support and deployment prerequisites.
Request access →