Where your managed VPN's internet breakout actually exits
Internet included says nothing about where public traffic exits, who filters it or what survives a failure. Trace the path, then write both failure cases.
You cannot say who filters a branch's public traffic until the proposal shows where that traffic leaves the provider's network. Internet access bundled into a managed VPN is a second service, riding a path with its own gateways, its own translation and its own escalation queue. Most contracts describe the private side in detail and leave the public side to a sentence. The checks below turn that sentence into a diagram you can defend.
Trace one public destination per site
Pick a branch host and follow one public destination, noting the last address that belongs to the provider and the first that belongs to the internet. The hop between those two addresses is the breakout, and it frequently sits nowhere near the site that sent the packet. Mark the device that performs the transition, because that device holds the filter deciding what leaves. Repeat the trace from a second site and compare exit addresses, since two branches that look identical on the invoice can leave through different gateways in different cities.
Note the source address the destination actually sees as well, because translation may happen at a hop you never drew. Write the observed answers next to the diagrammed ones, and the gap between them is where the first incident will come from. A provider engineer who cannot supply the exit address for a given site has already told you something useful about the design.
Three breakout arrangements and what each concentrates
A central exit you operate pulls public traffic to a gateway of your own, which hands you the filtering policy and the logs while concentrating every site's load on one circuit. A provider-run exit moves policy and logs across the contract boundary, which simplifies operations and removes your visibility in the same stroke. A per-site exit keeps public traffic local and multiplies the number of policy surfaces that must stay identical.
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
Ask which of the three the provider actually offers before treating the list as a menu, and ask whether a site can move between them without a new circuit. The migration answer separates what is contractual from what is merely technical. Record who owns source translation as well, because that decides what a partner must allowlist. Shared gateways also mean shared capacity and, on occasion, shared reputation, which changes how partners treat your addresses. Capacity deserves its own question too, because a shared gateway is serving other customers at the same moment.
Filtering, translation and encryption are separate owners
A route establishes reachability and says nothing about inspection, so treat the two as different questions with different owners. For every advertised default, name the device that filters, the device that authenticates, the device that translates and the device that inspects, then name who administers each. Provider route separation does not state where encryption terminates, and a private service can end its tunnel at one boundary while the public breakout ends at another. Ask whether translation happens at the provider edge, at a shared gateway or at your own exit, and whether session logs exist and for how long. Count the owners in the answers, because a contract that names one party for four jobs usually leaves three of them undocumented.
A broad default route imported into the private routing context deserves the same scrutiny, since an import is a deliberate agreement rather than a harmless convenience. RFC 4364 section 11 walks through several internet-access arrangements for BGP/MPLS VPNs and treats route exchange between the VPN context and the provider's default forwarding context as exactly that kind of agreement. Ask what prevents public traffic from taking a private path by accident, and get the answer next to the route policy rather than in a slide.
Two failure cases to agree before signing
Write two tests into the contract: lose the internet exit, and lose one private attachment. For each, list the internal resources, the local internet services and the management paths that must keep working. Then list the fallback that must stay blocked, because a path around the central controls is worse than a clean outage. Give both tests to the provider and ask for their expected result in writing, including detection and notification.
Run the same probes from a pilot site and compare them with that written answer. Where the two disagree, the contract is describing a different network from the one you bought. Two commands cover the common cases: one shows the path a public destination takes, the other shows the address it sees.
traceroute -n 203.0.113.10
curl -s https://example.net/ipAttach availability commitments to the segment you measured rather than to the service name. A local circuit, a provider backbone and a shared gateway carry separate obligations and separate escalation teams. The letters L2VPN, L3VPN and MPLS describe a forwarding mechanism, not an end-to-end guarantee.
Evidence beats the adjectives in the proposal
Words like redundant, secure and resilient describe an intention rather than a design. Ask for the device list, the exit locations, the translation scheme and the notification path instead. A provider that can produce those four items has a design; one that cannot has a slide. Keep the answers in the service documentation rather than an email thread, and revisit them at every contract change.
Breakout arrangements move quietly as providers consolidate gateways, so a diagram from three years ago is a liability. When a partner reports an unfamiliar source address, you should be able to say within minutes whether it came from your design or from a change nobody announced. That ability, rather than the adjectives, is what survives the first outage.