Give each workload an address.
Route public addresses to VMs or containers on infrastructure you own. Keep the exposure and operating owner of each workload explicit.
Fibmesh Public IPs / Routed Subnets
A public subnet. Delivered to your infrastructure.
Separate public addresses for the workloads behind your router. Bring the infrastructure; agree the block, supported delivery and service terms through an invitation-led managed setup.
Follow the delivery path Managed subnet guide · Confirm platform and deployment support during assisted setup.Available · Invitation-led managed service. Routed Subnets is arranged separately from the app’s device and gateway setup. Allocation, delivery and service terms are agreed for your infrastructure.
01 / More than one public address
A block for the
services you run.
A routed subnet delivers a block of public IP addresses to your router. Different workloads can have their own addresses, instead of sharing ports on one gateway IP.
Run several public services.
Give different services their own public identities behind a supported router, including protocols that need more than an HTTP publishing link.
Test a real routed boundary.
Evaluate addressing, firewall rules and return paths in a controlled environment before exposing production workloads.
Routed Subnets is available through a separately arranged, invitation-led managed service. It is separate from the app’s device and gateway setup. This does not establish self-service subnet provisioning. You decide how to distribute the agreed addresses and which services may receive traffic; allocation is scoped with Fibmesh.
02 / Aggregate → tunnel → router
One public route.
Your block behind it.
Fibmesh brings internet traffic to its network, then routes the smaller customer subnet to your supported gateway. Your router takes it to the workloads.
- A / Internet routingFibmesh covering aggregate
A globally announced covering block brings traffic to Fibmesh.
Example: covering /24 - B / Customer deliverySupported WireGuard tunnel
A smaller assigned subnet is routed through the delivery network to your gateway.
Example: customer /29 - C / Your infrastructureRouter → workloads
Downstream routes and firewall policy decide which services are reachable.
Your address & service plan
Replies sourced from the assigned subnet return through the agreed Fibmesh delivery path.
The aggregate is announced.
The customer subnet does not need its own global more-specific announcement. Fibmesh can announce a covering /24 and route a /29 from it to your gateway. You do not need a customer ASN or BGP session for this model.
Your access connection stays essential.
Your broadband or cloud connection carries the tunnel. Confirm the gateway platform and serving location with Fibmesh. WireGuard is currently the only supported tunnel protocol; generic WireGuard support alone does not establish compatibility.
03 / Size the address plan
Count addresses.
Or count networks.
The slash number is the prefix length, or CIDR notation. A smaller number means a larger block. IPv4 and IPv6 use different planning units.
Total IPv4 addresses8
A /29 contains 8 total addresses. The usable workload count depends on gateway reservations and how the block is routed; it is not automatically 8.
IPv4 and IPv6 are separate allocations. In IPv6, a /56 contains 256 conventional /64 networks; a /48 contains 65,536. A smaller prefix number means a larger block.
Start smaller than a /24.
- /29
- 8 total addressesA few separately addressed services
- /28
- 16 total addressesMore workloads or separate environments
- /27
- 32 total addressesA larger set of services
- /24
- 256 total addressesA full IPv4 /24 for scale comparison
/48 through /64.
- /64
- 1 /64 networkOne conventional downstream LAN
- /56
- 256 /64 networksSeparate tenants or environments
- /48
- 65,536 /64 networksA more extensive addressing plan
IPv4 and IPv6 are separate allocations. Request either family, or both for dual-stack infrastructure. For IPv6, plan the number of downstream /64 networks you need; the network count is not a device count.
04 / Place the delivery
Your hardware.
An agreed location.
Use the block behind a supported router in an office, lab, colocated environment or cloud. Keep workload addresses independent of the access ISP while the allocation is reserved. Existing internet access remains required.
Planned / Floating delivery orchestration
Plan infrastructure you control →A delivery move needs a new routing decision.
A floating-subnet workflow could move delivery between gateways or clouds while retaining the block. That orchestration remains planned. A new target needs route ownership, source validation and a verified return path.
Available routed delivery does not include automatic failover, simultaneous multi-cloud use or preserved application sessions.
05 / The customer side
Your router.
Your public boundary.
You control downstream routing, firewall policy and service authentication. The public addresses need a complete path in both directions.
- 01
Choose a supported target.
Identify a router or Linux gateway you administer. It needs Fibmesh-supported WireGuard software, forwarding, route control and a way to recover local access.
- 02
Map the downstream addresses.
Decide whether addresses belong on hosts, routed downstream networks or a specifically designed translation boundary. Record each address owner and the route back through your router.
- 03
Define the public boundary.
Allow only the required source ranges, destination addresses, protocols and ports. Retain host firewalls and application authentication. Anti-spoofing must prevent traffic using another customer’s source addresses.
- 04
Verify the complete path.
Test permitted and denied inbound traffic, replies, MTU, tunnel interruption and recovery. A WireGuard handshake alone does not establish application reachability.
Prerequisites include eligible internet access, permission to change gateway routing, an agreed allocation and supported delivery. CGNAT or a changing access address may need tunnel-specific handling; universal compatibility and seamless roaming are not promised.
06 / Settle the service terms
Know what comes
with the block.
Allocation is one part of the service. Record the operating and commercial responsibilities before delivery.
- 01Allocation & location
- Confirm the assigned CIDR, usable workload count, serving location, customer eligibility and available inventory. Agree whether the allocation is retained while delivery is paused.
- 02Traffic & charges
- Agree port speed or throughput limits, traffic allowance, metering, overages and allocation charges. No public subnet prices or bandwidth guarantees have been announced.
- 03PTR & reverse DNS
- Establish whether PTR records or reverse DNS delegation are supported, who may change them and how that authority is verified. Address allocation does not guarantee mail deliverability or address reputation.
- 04Operations & abuse
- Name the customer operator, abuse contact and incident escalation path. Agree the service boundary, maintenance expectations and what happens when the tunnel is unavailable.
- 05Pause & release
- Define reservation, pause, resume and release terms. Withdrawing delivery and giving up the block have different consequences. Plan changes to DNS records, allowlists and hosted services before release.
07 / Within Public IPs
One address.
Or a routed block.
Choose the delivery scope around what will own the addresses. A private Networks network is optional; workspace identity and service entitlement still apply.
Device IPs
Give a supported host a public address for its own incoming or outgoing connections.
Explore Device IPs →Gateway IPs
Use an address on a gateway serving LAN devices, with explicit forwarding or outgoing policy.
Explore Gateway IPs →Routed Subnets
Distribute a public block across workloads or downstream networks behind your router.
This managed serviceThis is managed subnet delivery. It does not grant transferable address ownership or an independently portable lease. BYOIP, customer BGP, automatic failover and high availability are separate capabilities outside this service scope.
Compare Public IPs options →Next / Invitation-led managed setup
Bring the workload plan.
Scope the public block.
Tell us the workloads, approximate address count, IPv4 or IPv6 requirements, gateway platform, delivery location and site country. Include expected traffic, reverse DNS and incoming protocol requirements so we can assess the allocation and delivery together.