A destination for a service.
Accept file transfers, application calls or other supported traffic on your server. Clients use the assigned public address and the port you permit.
Fibmesh Public IPs / Device IPs
Keep the device.
Give it a public IP.
A destination for your service, a recognised source for selected outgoing traffic, or both. Bring the supported host and choose the connections it needs.
Find your device’s role Device 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 / Start with the job
One host.
Three reasons to allocate.
The public address belongs to the assignment. Decide what it should do before choosing the traffic policy.
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 address beyond one connection.
Keep the reservation separate from office broadband, home Wi-Fi or a mobile hotspot. Moving between eligible access networks can require the tunnel and application sessions to reconnect.
02 / Platform register
Choose the job.
Then the platform.
A supported host can receive the address directly. Platform support determines which workflows it can run; a public IP does not give every device the same hosting capabilities.
- Servers & cloud VMs
- Host the service.
Public application endpoints, file transfer and partner connections. Direct delivery places the routed public address on the supported host.
- Laptops & workstations
- Choose the traffic.
Use a consistent outgoing source for approved systems, or deliberately expose a development service. Everyday traffic can keep the ISP route when only selected destinations need Fibmesh.
- Mobile phones
- Evaluate outgoing identity.
Supported clients depend on the operating system’s background and VPN behaviour. Mobile public service hosting is outside the v1 ingress scope.
- IoT & embedded devices
- Check the agent first.
Join directly where a supported agent can run. Otherwise, use a supported gateway to reach the equipment’s existing address.
03 / Direct delivery
The public destination
reaches the host.
The assigned address stays intact at the endpoint. Follow an incoming connection, its reply and 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 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.
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 transport
Fibmesh carries the assigned public IP through an encrypted WireGuard tunnel. WireGuard is currently the only supported tunnel. Your access ISP may use NAT for the outer connection; that is separate from the assigned public address, which has no destination NAT at the endpoint.
The deployment
Supported deployments can use dual-stack or IPv6-only delivery. Choose incoming rules and outgoing routing independently. The app still needs a listener, correct source-address selection, host firewall rules and its own authentication.
Configuration exampleA partner’s SFTP connection
For a supported SFTP server on TCP port 22, allow the partner’s agreed source range. 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 example uses a different traffic choice from the full-tunnel customer deployments below.
04 / From customer deployments
Keep the server.
Change how people reach it.
A shared billing application and software on customer premises. In both deployments, the application stayed on hardware the business already operated.
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.
Another location↔Fibmesh public address↔Shared billing server
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.
Application users↔Fibmesh public address↔Customer-site ERP server
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.
These examples describe past deployments. Confirm which Windows client and setup are currently supported.
05 / Reservation lifecycle
Keep the reservation.
Change the connection.
Pausing delivery and giving up an address are different decisions. Plan the dependencies before changing the assignment.
- 01 / Pause
Withdraw delivery.
The address reservation remains yours while delivery is paused.
- 02 / Resume
Use the reservation.
Resume delivery using that reserved address. Verify the service and traffic path again.
- 03 / Release
Give up the address.
Update DNS records and external allowlists before release. A serving-region change needs a separate address review.
An address is not authentication.
Remote callers still need permission to use the service. Your Fibmesh device identity and Networks private addresses remain separate from this public allocation; a private Networks network is optional.
Keep application encryption.
Tunnel encryption ends at the Fibmesh peer. Protect the rest of the journey with application encryption. IP allowlisting complements authentication, including for bank-approved corporate access.
06 / Before the first connection
A listener, a rule
and a return path.
A tunnel handshake is only the start. Verify both the connections you permit and the traffic you intend to leave on its existing path.
- 01
Listener
Listen on the assigned address or an appropriate interface. An app bound only to localhost needs a deliberate forwarding setup.
- 02
Incoming rule
Permit only the required protocol, port and caller sources. Keep the host firewall and application authentication in place.
- 03
Return path
Send replies to incoming connections back through Fibmesh. Verify the actual application from an external, permitted client.
- 04
Outgoing source
For selected outgoing traffic, confirm the destination observes the assigned public address. Check source-address selection as well as the route.
Next / Your first device
Bring the device.
Name the destination.
Tell us the 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.