A branch changes internet providers, and the file server keeps its address. That outcome is normal in a routed site VPN and surprising to anyone who assumes the tunnel's endpoint address is the application's address. The two live in different layers of the design, and only one of them moved. Treating them as one is how a provider migration turns into a renumbering project.

Two address plans that move independently

The inner plan describes the private addresses applications use: the branch server at 10.55.8.20, the headquarters prefix that routes to it, and the return route back. The outer plan describes how two gateways reach each other: peer addresses, listener ports, and the path across the internet.

A provider change touches the outer plan. It does not, by itself, require the inner plan to change.

Keeping the two inventories separate is the practical reason to run an overlay even when the application already encrypts its own traffic. The overlay gives you a stable inner topology that survives outer churn. The application keeps its address, its firewall rules, and its DNS records. Only the transport entries change, and that is a much smaller review.

The outer tunnel carries the inner conversation

In a gateway-to-gateway tunnel, the outer IP header addresses the two gateways. The inner header still names the actual application endpoints. RFC 7296's gateway-to-gateway description treats this as ordinary routing delivering traffic through tunnel endpoints.

That is why the branch server can keep 10.55.8.20 while the gateway's public address changes. The inner packet does not contain the provider's address at all.

The separation is a design property, not an automatic guarantee. If the replacement uplink cannot establish the supported tunnel, or the inner routes are not reinstalled, the application loses its path even though its address is unchanged.

The provider move still has a checklist

The outer checklist has five entries: the peer address or maintained name, the listener and any upstream filtering, translation in the path, the expected peer identity, and the other gateway's allowed settings. Each can fail on its own. Keep a separate recovery path while you change the link that carries administration. Cutting remote access during an uplink cutover is an outage you caused yourself.

After that, check the branch prefix, the route in both directions, the protection policy, and one real application flow. A freshly authenticated tunnel does not fix a route that points at the old private subnet.

Address overlap with another connected site is a separate planning problem. The provider change does not create it, but a migration is usually when it surfaces.

What does not survive: public source and sessions

A stable private server address is not a stable public source. If browsing exits directly through the new provider, websites see the new provider-facing address.

Keeping that address stable needs a deliberate egress design, with its own availability and policy. It does not come free with the tunnel.

Established sessions do not survive a path change either. The tunnel can re-establish within seconds and still break long-lived connections pinned to the old path. Plan the cutover for a window where reconnects are acceptable. Do not claim a migration will be invisible unless the specific clients and their timeouts were tested.

Verify the move with four checks

After the change, verify four things in order: the tunnel is established with the intended peer, the inner route to the branch prefix exists, the policy permits the application flow, and the application answers. Each has its own command.

On a Linux gateway, these three cover the middle of that list:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Keep transport addresses in one inventory and application addresses in another. Update only the entries that actually moved. Renumbering internal dependencies because the tunnel's outer address changed is avoidable work.

Winndannde jowitiiɗe heen