Choose by traffic scope
A provider may ask you to allowlist the address your requests come from. Both products can help, but first decide how much traffic should follow that address and whether anything must be reachable from outside.
| Requirement | Public IPs | Outbound |
|---|---|---|
| Selected providers should see a known source; other traffic stays on the ISP | Selected-outbound routing is the relevant option | Current profiles use full tunnel, not per-destination selection |
| Eligible internet traffic should use a chosen exit | Full-tunnel delivery can be assessed | Core product purpose |
| Internet clients need to reach a service | Inbound access with explicit firewall rules | Does not publish an incoming service |
| LAN clients need a shared outgoing identity | Gateway IP delivery and routing can be assessed | Confirm the supported gateway/platform scope |
| Workloads need separate public addresses | Device assignments or Routed Subnets | Not a substitute for a routed public block |
| The address must stay on a provider allowlist | Confirm allocation and reservation terms | Confirm stable allocation and retention terms |
Public IPs: select the destinations
- Device or LAN clientCalls a selected destination
- Device or gatewayMatches the approved destination route
- Fibmesh deliveryUses the assigned public source
- Selected serviceFor example, an allowlisted API
Policy: Other destinations stay on the existing ISP. Incoming public access has separate firewall controls.
Return path: Replies to these connections return through Fibmesh. An inbound-access configuration also needs its incoming replies routed back through Fibmesh.
For example, an office integration calls an API from its assigned public address while ordinary browsing stays on the existing ISP. If that office also needs incoming access to a server, configure its inbound rules separately. Requests arriving through Fibmesh must have a working return path through Fibmesh.
Inspect all Public IP traffic presets →Outbound: choose the internet exit
- Your endpointStarts an internet connection
- WireGuard tunnelEligible internet traffic uses the profile
- Fibmesh exitStable source where allocation is confirmed
- External serviceSees the outgoing source address
Policy: One organisation profile is active at a time in the current model. Platform and local-network exceptions need checking.
Return path: Replies return through the exit and tunnel. This does not create an incoming public service on your device.
For example, a supported laptop uses the chosen exit as its internet path. Where a stable allocation is confirmed, an external service sees that recognised source even as the laptop’s local connection changes. This does not promise uninterrupted sessions during a handover.
The current model has one active organisation profile, with full-tunnel routing. Check IPv4/IPv6 handling, DNS, local-network access, platform exceptions and behaviour when the tunnel is unavailable.
Understand Outbound profiles →Three questions settle most choices
- Does anyone need to initiate a connection to you? Use a Public IP and firewall rules, or consider Publish for a selected web app. Contact Fibmesh to arrange a supported deployment.
- Should only particular destinations change route? Start with Public IPs selected outbound.
- Is the whole eligible internet path the requirement? Start with Outbound and confirm whether you need a stable allocation.
Check these before relying on an allowlist
Confirm the actual assigned source address from the intended application path, not just the dashboard. Check the provider’s IPv4 or IPv6 support and register the right address family. Agree who updates the allowlist if an allocation changes, and keep application credentials in place. Disable or release a configuration only after understanding address retention and recovery.
An IPv6-only full-tunnel setup also needs an explicit IPv4 policy: block, supported translation, or deliberate bypass. It should never imply protection of traffic that is left outside the tunnel.