The vendor’s form has one box: “Your public IP address.” Your team works from home, mobile connections and customer sites, so there is no single office connection to enter.
For remote teams, IP allowlisting can use an agreed stable exit: approved devices route their traffic through it, and the provider checks that outgoing source address. Confirm exclusivity if the address must represent your organization, then verify the route at the provider. Keep individual logins and multi-factor authentication; the shared source address does not identify the person using it.
How source-IP allowlisting works
An IP allowlist compares the source address of an incoming connection with a list of permitted addresses. Depending on the service, the restriction may sit at a firewall, an API gateway or the application itself. A request from an address outside the list is rejected at that point.
It is a useful extra restriction. It also has a fairly narrow job.
The source IP does not identify the person at the keyboard. Several people can share an exit. A compromised laptop can still connect through an approved route. Someone who has access to that route may also have stolen credentials.
Keep application authentication, individual accounts and appropriate multi-factor authentication. The allowlist makes fewer origins eligible to try; the application still decides who can do what. NIST’s zero trust guidance makes the same distinction: network location alone does not confer trust.
Permitted source path
- Authorized deviceUse the supported, agreed outgoing route.
- Agreed exitPresent the source address in the provider’s allowlist.
- Provider serviceSource restriction passes; application login is still required.
Unapproved source path
- Other connectionUse a source outside the agreed list.
- Provider allowlistReject that source when the configured rule applies.Restricted boundary
Conceptual allowlist, assuming the receiving provider enforces it. The approved exit supplies the observed source; it does not identify the person or replace application credentials. Verify both address families and the actual workload’s path.
Check address retention and exclusivity
For a distributed team, the arrangement looks like this: an authorized device connects through an agreed exit, and the provider sees that exit’s public address. A switch from home broadband to mobile data changes the device’s underlying internet connection. It should not require a new provider allowlist entry, provided the approved exit is still being used and the service retains the agreed address.
Two details deserve a written answer before you depend on it:
- Address retention: will the address remain assigned while the service is active? What happens if the profile is disabled, replaced or the subscription ends?
- Exclusivity: is the address dedicated to your organization, or shared with other customers?
A shared address may be stable, but it is a weak choice when the provider expects your allowlist entry to restrict access to your organization. Stability solves the maintenance problem. Exclusivity narrows who else can present the same source address. Neither replaces authentication.
Plan the routing before adding the IP
Write down the target service, the people who need it and the address family it accepts. If the service has both IPv4 and IPv6, test both. An IPv4 allowlist entry says nothing about a request that arrives over IPv6.
Then check the scope of the routing change. Fibmesh Outbound currently uses a full-tunnel internet-routing profile, which requests routing of all internet traffic through the exit. One enabled profile is selected per organization. It is not a released “send only this vendor portal through the exit” rule; destination-specific routing is planned. Changing the active profile affects the organization’s policy, so coordinate it with everyone who depends on it and verify behavior on the supported clients.
If a supported Public IPs deployment better fits your routing requirements, compare that arrangement before choosing Outbound. You do not need to buy both simply because both can provide a recognized outgoing address.
Compare Public IPs and Outbound →Test allowed, denied and recovery paths
Start with one non-critical target and one authorized test device. Arrange the supported exit and address, add it to the provider’s allowlist, then make a real request to the target. An “enabled” profile or a saved assignment is not a successful connection test.
Check the source IP as observed by the provider. A public “what is my IP?” page is a helpful first check, but it does not prove that every application or address family follows the same path. Keep a recovery method available before tightening the provider’s rules.
Next, test the rejection case from an unapproved connection. Confirm that the intended restriction is doing the work. Record the owner of the provider allowlist, the owner of the Fibmesh configuration and the process for changing either one. These are often different people.
Finally, try the ordinary events that will otherwise become Monday-morning tickets: changing broadband connections, restarting the device and turning the profile off. Check the behavior against the supported client and service terms rather than assuming automatic recovery or fail-closed routing.
Keep the exception list small
The temptation is to add every home IP that causes a problem. After a few months, the allowlist stops describing an approved access path and starts describing the team’s travel history.
Give each addition an owner and a reason. Remove access when the work ends, both at the application and at the network layer. For contractors, individual application accounts are still essential even when everyone uses the same approved exit.
A stable outbound IP is most useful when it turns a moving collection of connections into one arrangement you can explain and maintain. The test is simple: the right people can reach the target, the wrong origins are rejected, and someone knows how to recover when the path breaks.
Explore Fibmesh Outbound →
