More than one public address
A block for the services you run.
A routed subnet is a block of public IP addresses delivered to your router. Unlike sharing one gateway IP through port forwarding, it lets different workloads have their own public addresses.
A virtualisation host may run several customer workloads. A small hosting business may need separate public addresses for different services. A lab may need to test real public routing without moving its machines into a data centre.
Routed Subnets is available through a separately scoped, invitation-led managed service. It is outside the app MVP and does not establish self-service subnet provisioning. Fibmesh supplies the agreed public address block and routes it to your gateway. You decide how to distribute the addresses across your infrastructure and which services may receive traffic.
Separate addresses for separate workloads
Route addresses to VMs or containers on infrastructure you own. Keep each workload’s exposure and operating owner explicit.
Bring public identity to your site
Plan several public services behind a supported router, including services that need more than an HTTP publishing link.
Work with a real routed boundary
Evaluate addressing, firewall rules and return paths in a controlled environment before exposing production workloads.
The delivery model
From a public block to the workloads behind your router.
A globally announced covering block brings traffic to Fibmesh.
A smaller assigned subnet is routed to the customer gateway.
Local routes and firewall policy decide which services are reachable.
Replies using the assigned public addresses return through the agreed Fibmesh delivery path.
Delivery uses a supported WireGuard tunnel. Your broadband or cloud connection carries the tunnel; Fibmesh does not replace that connection. Confirm the gateway platform and serving location with Fibmesh before setup. WireGuard is currently the only supported tunnel protocol.
The customer subnet does not need a separate global BGP announcement. For example, Fibmesh could announce a covering /24 and route a /29 from it to your gateway. The more-specific route exists within the delivery network. The customer does not need an ASN or BGP session for this model.
Illustrative delivery path · Actual allocation and usable addresses are agreed during setup.
Start with the right amount of address space
Smaller than a /24. Sized for your setup.
The slash number is the prefix length, also called CIDR notation. A smaller number describes a larger block. IPv4 planning counts addresses; IPv6 planning usually counts the /64 networks you can create.
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.
A full IPv4 /24 contains 256 addresses. Many deployments need a much smaller block. These IPv4 examples explain the scale; confirm the sizes in stock and usable-address rules for your allocation.
/29
8 total addressesFor a few separately addressed services.
/28
16 total addressesRoom for more workloads or separate environments.
/27
32 total addressesFor a larger set of services with clear allocation owners.
Total addresses and usable workload addresses are different counts. A conventional IPv4 subnet, gateway reservation and individually routed host addresses can consume the block differently. The delivery design must state the usable count before an allocation is accepted.
IPv4 and IPv6 subnets are separate allocations. Choose either family, or request both for dual-stack infrastructure. IPv6 supports prefixes from /48 through /64; size the prefix for the number of downstream networks you need.
/64
1 conventional /64 networkA single downstream network.
/56
256 /64 networksRoom to separate sites, tenants or environments.
/48
65,536 /64 networksFor a more extensive addressing plan.
Where the block can work
On your hardware. In a cloud. Across a migration.
Use a routed 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.
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. Routed Subnets availability does not include automatic failover, simultaneous multi-cloud use or preserved sessions.
Plan infrastructure you control →What your setup needs
Your router delivers the addresses to your workloads.
Choose the delivery 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.
Map addresses to workloads
Decide whether addresses belong on hosts, routed downstream networks or a specifically designed translation boundary. Record the address owner and return route.
Set the public boundary
Define allowed source ranges, destination addresses, protocols and ports. Retain host firewalls and application authentication.
Test both directions
Check permitted and denied inbound traffic, replies, MTU and tunnel interruption. A tunnel handshake alone does not establish application reachability.
Prerequisites include eligible internet access, permission to change gateway routing, an agreed address allocation and supported delivery. CGNAT or a changing access address may require tunnel-specific handling; universal compatibility and seamless roaming are not promised.
Traffic sourced from the assigned subnet must follow the agreed return path. Anti-spoofing controls must prevent a customer from sending traffic with another customer’s source addresses. Ordinary internet traffic from the rest of the site remains a separate routing decision.
What needs to be settled before delivery
Know what comes with the block.
- Allocation and location
- Confirm the assigned CIDR, usable addresses, serving location, customer eligibility and whether the allocation is retained when delivery is paused.
- Traffic and cost
- Agree port speed or throughput limits, traffic allowance, metering, overages and allocation charges. No subnet prices or bandwidth guarantees have been announced.
- Reverse DNS
- Establish whether PTR records or delegation are supported, who can change them and how authority is verified. Address allocation alone does not guarantee mail delivery or address reputation.
- Operations and abuse
- Name the customer operator, abuse contact and incident escalation path. Clarify the service boundary, maintenance expectations and what happens when the tunnel is unavailable.
- Pause and release
- Define reservation, pause, resume and release terms. Removing delivery and giving up the block have different consequences for DNS records, allowlists and hosted services.
Within Public IPs
One address or a routed block?
Choose Device IPs for a supported host, or Gateway IPs for a gateway serving LAN devices. Routed Subnets is the option for distributing a block across several resources behind your router.
This is managed subnet delivery, not a promise of transferable address ownership or an independently portable lease. BYOIP, customer BGP, automatic failover and high availability are separate capabilities and are not included in this announcement. Private Networks are optional; workspace identity and service entitlement still apply.
Compare Public IPs options →Separate managed service / Invitation-led setup
Tell us what you would put behind the block.
A useful brief names the workloads, approximate address count, IPv4 or IPv6 requirement, gateway platform, site country and expected traffic. Include any reverse DNS or inbound protocol requirements.
Understand the subnet API and CLI boundary →
Request an IPv4 block, an IPv6 prefix, or both. Include the delivery location, gateway and intended workloads so we can scope the allocation.
Request a subnet →