A worked example
The worker has valid credentials. Its changing IP is the problem.
An integration worker calls a provider API. The provider accepts requests only from approved public source addresses. Moving the worker between an office connection and a cloud server can therefore break the integration even though the application itself has not changed.
The requirement is a recognised outgoing source. It does not require publishing the worker or accepting connections from the internet.
Resource plan: the integration worker
| Resource | Owner | Responsibility |
|---|---|---|
| Worker | Integration team | Runs the actual API request and verifies the response. |
| Exit and source address | Workspace administrator | Confirms delivery, traffic scope and address terms. |
| Provider allowlist | Provider account owner | Adds the verified source and manages changes. |
| API credentials | Application owner | Maintains separate application authentication. |
Two valid ways to meet the requirement
Choose an exit service or an address assignment.
With Outbound
Use a provisioned exit with an agreed stable or dedicated source. The current profile model changes the eligible default internet route; review other applications on the worker and the organisation-wide profile scope.
Explore the exit service →With Public IPs
Use an address assigned to the device or gateway. Supported routing modes can use that address for selected outgoing destinations or broader internet routing. Incoming access remains a separate firewall decision.
Explore address delivery →Do not add a second product if the first already provides the required source and traffic scope. The example below follows the Outbound option.
Without the Fibmesh exit
- Your deviceStarts the request
- Existing ISPOrdinary public source
- Internet serviceSees the ISP-side source
Traffic takes the ordinary internet route. The service sees the public source provided by the existing connection, which can change when you change networks.
An internet connection remains necessary in every scenario.
A new exit over the connection you already have
- Your devicePrivate tunnel identity
- WireGuard over your ISPEncrypted tunnel to Fibmesh
- Fibmesh exitPublic outgoing source
- Internet serviceSees the exit source
The supported full-tunnel profile directs eligible internet traffic to the Fibmesh exit. A stable or dedicated source requires an agreed allocation; ordinary exit routing does not promise either.
The tunnel ends at Fibmesh. HTTPS continues to protect an HTTPS session between the application and its destination.
From configuration to an accepted request
Make the change with the provider, not just the network.
- Confirm whether the provider needs IPv4, accepts IPv6, and allows the proposed address and region. Do not assume that a dedicated IP bypasses its security or account policies.
- Obtain the actual provisioned exit source. A profile name, requested region or enabled state is insufficient.
- Have the provider owner update the allowlist during an agreed window. Keep an appropriate rollback rule until verification is complete.
- Enable the supported profile with the organisation’s routing owner. Run a controlled request from the real integration worker.
- Verify the source the provider observed, the application response and any other traffic affected by the full-tunnel route.
A generic IP-check page on a different laptop is not evidence for the worker. Record the deployment, profile, observed source and test time without storing API secrets or customer payloads.
When a request still fails
The source check is one boundary, not the whole application.
The provider sees the old source.
Check the actual workload, its address family, provisioned exit and effective route. Confirm policy application rather than relying on the profile record. IPv4 and IPv6 may behave differently.
The source is accepted, but the API rejects the call.
Check credentials, permissions, provider policies and the application response. A source-IP allowlist does not establish application authorisation.
The integration is temporarily suspended.
Disabling an Outbound profile changes its intended routing state; it does not establish retention or release of the source address. Confirm reservation and billing terms before relying on the same address later.
The source address is being retired.
Coordinate replacement and removal with every provider that refers to it. Test the replacement before withdrawing the old rule where possible. Verify the ordinary route after disabling the exit.
Acceptance criteria
Three results worth recording.
- Observed identity
The real provider sees the agreed outgoing source.
- Working application
The authenticated API call succeeds, and other affected traffic behaves as intended.
- Safe recovery
The team knows how to restore routing and update allowlists without assuming an address is retained.
This is a worked planning example, not a customer case study or a released installation procedure.
Prepare the deployment and recovery checks →