Fibmesh Public IPs / How it works
Separate the allocation, its delivery, the traffic it carries and the rules for incoming access. Each choice answers a different question.
Follow the decisions Public addressing 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 / Keep the choices independent
A public allocation is separate from a device’s identity and the private addresses it uses inside Networks. A private Networks network is optional; account identity and entitlement are still required.
A single target or a separately allocated block. Choose the address families your clients and destinations need.
Route the address directly to a supported endpoint, or forward permitted traffic through a gateway to LAN equipment.
Choose incoming access, selected outgoing traffic or full tunnel. Give replies their own correct return path.
Keep new incoming connections closed until you explicitly permit the required callers, protocols and ports.
Dual-stack gives a supported target IPv4 and IPv6. IPv6-only needs compatible clients and destinations; it does not automatically include an IPv4 address or translation.
Allocate IPv4 and IPv6 blocks separately. IPv6 prefixes range from /48 through /64. Route the block to your infrastructure, then assign addresses or downstream subnets to workloads.
Explore Routed Subnets →02 / Delivery paths
Your ISP transports the outside of the encrypted tunnel. The assigned public address identifies the traffic inside it. ISP NAT and public-address translation are separate questions.
203.0.113.24203.0.113.24Packets retain the assigned public destination all the way to the supported endpoint. No destination NAT is required there. A fully routed address can still have a firewall.
Direct delivery to a device →203.0.113.2410.20.0.10The gateway translates permitted traffic to an explicit private target. LAN-side source NAT can preserve the equipment’s existing configuration, but the target may see the gateway’s address instead of the original client’s.
Forwarding through a gateway →WireGuard is currently the only supported tunnel. Confirm a Fibmesh-supported client or gateway; generic WireGuard capability does not establish support. The ISP may use NAT or CGNAT, provided the outbound WireGuard UDP tunnel can be established and maintained. Compatibility is confirmed for the deployment. Manual WireGuard profiles are Compatibility Mode, rather than full managed functionality.
Documentation addresses illustrate the paths. Inbound-only delivery can leave ordinary new outgoing traffic on the ISP, while service replies return through Fibmesh. NAT alone does not choose that return route.
03 / Traffic policy
Incoming access and outgoing routing are independent. Start with a preset, then verify the actual paths at the supported endpoint or routed gateway.
Explore a traffic preset Illustration · no settings are changed
| Preset | New incoming connections | New outgoing connections | Traffic left on the ISP |
|---|---|---|---|
| Inbound access | Permitted by incoming rules; replies return through Fibmesh. | Ordinary new outgoing traffic keeps its existing route. | Unrelated outgoing connections. |
| Selected outbound | Blocked by default; enable incoming access separately. Replies to initiated connections remain allowed. | Agreed destinations use Fibmesh and the assigned source address. | Destinations outside the selection. |
| Full tunnel | Still controlled by independent incoming rules. | Eligible internet traffic uses Fibmesh, with explicit IPv4 and IPv6 policy. | Documented local and platform exceptions; any deliberately bypassed family must be labelled. |
Selected destinations are agreed IP addresses and CIDR ranges. Select the assigned public source as well as the route: choosing the tunnel path alone is insufficient. Domain or application selectors require separate client support; this guide does not establish those controls as implemented.
Host a service and call a partner API from the same address with inbound plus selected outbound. Blocking new incoming connections must still allow replies to connections you started.
Joining the LAN does not redirect its outgoing traffic. Quick Connect forwards selected incoming traffic to a configured target, or through per-port mappings on supported software. New outgoing connections must actually traverse the gateway through routing changes or a protected downstream network. A one-port connector does not isolate the LAN or provide independent recovery when the ISP fails. Edge hardware remains a development/pilot deployment option; confirm the supported software and address-family behaviour for your gateway.
The explorer is an illustration. Its native controls change no settings. Confirm available client or gateway controls during assisted setup.
04 / Incoming boundary
Full tunnel does not open incoming access. An outgoing allowlist does not publish a service.
Understand the firewall boundary →05 / Families & failure
“Full tunnel” describes the intended traffic policy. Confirm what the supported platform can enforce for both address families and during tunnel loss.
06 / Domains & applications
Point a domain you control to the assigned IPv4 address with an A record, or to its IPv6 address with an AAAA record. The application or a reverse proxy you operate supplies HTTPS and its certificate.
files.studio.exampleA record →203.0.113.24DNS names the destination. Your service owns its listener, authentication and TLS.
A Public IP does not automatically create a Fibmesh subdomain, provide a certificate or choose applications by hostname. A DNS record also does not select a non-standard service port.
Choose Public IPs for an address with supported TCP or UDP services. For one HTTPS link to a web app, consider Publish.
Compare a public link with a Public IP →07 / Before handover
A tunnel handshake is not an application test. Check what can connect, what cannot, which source appears and what happens when delivery stops.
Reach the actual application from a permitted external caller. Confirm a denied caller cannot reach it.
Test selected and unselected destinations. Check the source address each destination actually sees.
Test IPv4 and IPv6 separately. Confirm any unsupported family is blocked, translated by a supported service or clearly labelled as an ISP bypass.
Check gateway return routing and MTU with a larger transfer. Interrupt the tunnel, verify the agreed block or fallback, then test recovery.
Next / Your traffic requirements
Tell us the target, address families, callers and outgoing destinations. We’ll confirm the supported deployment, serving location and traffic policy during assisted setup.