Conceptual scenario
Work through an integration whose provider checks the public source address of every request. See which traffic needs the assigned outgoing address and how to verify it.
Explore products ↗A worked planning example, not a customer case study or a released installation procedure.
The working situation
An integration worker calls a provider API. Moving the worker between an office connection and a cloud server can break the integration when the provider accepts requests only from approved public sources.
Full-tunnel profile
The provider-facing worker
Coordinate provider rules before changing or retiring the assigned source.
The provider’s view is the evidence that matters.
This job needs a recognised outgoing source. It does not require publishing the worker or accepting new connections from the internet.
Keep these owners in the same change window. Scroll sideways to compare all columns. With a keyboard, focus the table region and use the arrow keys.
| 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 ways to meet the requirement
A stable-source requirement does not require both products. Choose the supported delivery that covers the worker’s job, then verify its effect on other traffic.
Follow the Outbound option
The existing internet connection carries the tunnel. Compare the ordinary source with the exit source; this explanation changes no settings.
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.
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
The network operator and provider account owner need the same evidence and a recovery plan. Record the deployment, profile, observed source and test time without storing API secrets or customer payloads.
Confirm whether it needs IPv4, accepts IPv6, and allows the proposed address and region. A dedicated IP does not bypass the provider’s security or account policies.
Confirm the actual exit and source address. A profile name, requested region or enabled state is insufficient; verify address-family support and effective native policy on the worker.
Have the provider owner add the verified source. Keep an appropriate rollback rule until verification is complete and agree how to test a source that should be denied without disrupting production.
Enable the supported profile with the organisation’s routing owner. Make a controlled, authenticated call from the integration worker, testing IPv4 and IPv6 separately where applicable. Agree explicit handling for an unsupported family.
Verify the source the provider observed, the successful application response and a request that should be denied. Check other traffic affected by the full-tunnel route. Test the supported rollback and ordinary route restoration before retiring the old rule.
When a request still fails
The source check is one boundary in the application’s path. Keep routing evidence, provider policy and application authentication distinct when diagnosing the result.
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.
Check credentials, permissions, provider policies and the application response. A source-IP allowlist does not establish application authorisation.
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.
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
Keep the provider’s observed source, application result and recovery record together. A requested routing change alone cannot establish any of them.
The real provider sees the agreed outgoing source.
Record IPv4 and IPv6 results separately and check that a source outside the allowlist is denied as intended.
The authenticated API call succeeds, and other affected traffic behaves as intended.
Keep the actual worker, provider response and traffic-scope checks in the evidence record.
The team knows how to restore routing and update allowlists without assuming an address is retained.
Verify rollback, replacement-source acceptance and removal of obsolete provider rules. Confirm address and billing terms separately.
Prepare the deployment
Use the product guide for the supported routing and recovery checks.
