Half-managed VPN: the label does not say who is on call

At eight in the morning a connection fails, and the first question is who is supposed to fix it. The phrase half-managed VPN does not answer that, because it labels a commercial arrangement rather than a division of work. Two providers can use the same phrase with opposite allocations: one maintains the customer-side appliance, the other only watches its own gateway. Until the tasks are written down, the label is a guess dressed up as a description.

Start from the connection that failed

Name the endpoint that stopped answering, the time, and what the user was doing when it broke. Then list the components in that path: the laptop, the local circuit, the customer-side gateway, the provider gateway, and the resource behind it. Each one either has an owner in the agreement or has a gap. Sorting them takes ten minutes and decides the next three hours.

A symptom shared across users points at a shared component, while one that follows a single laptop points at the client. That distinction puts the ticket in the right queue before anyone opens a configuration.

Settle the two endpoints before the settings

Decide who owns the customer-side gateway and who owns the far endpoint. Once those two are settled, each side knows what it can inspect and what it has to ask for. Everything else in the arrangement gets easier from there.

A provider can monitor its own gateway while the customer stays responsible for a local ISP circuit, a directory service or the destination application. A customer-owned appliance can still sit under a provider maintenance agreement, which is why ownership and who maintains the box are two different questions. Write both answers down for each endpoint, because the second one is where renewals usually disagree.

Shared objects need exactly one owner

Identities, credentials, protected prefixes, proposals and the return-routing agreement are shared objects, and shared objects rot fastest. If both parties can change one, both will, and each change looks locally correct while the agreed flow breaks. Give every object one owner and one change process, and require the other side to be told before a change lands. The alternative is a change log that reads like two people repairing different halves of the same machine.

The classic failure is a selector change on one side and a NAT change on the other in the same week. Neither engineer did anything wrong, and the tunnel still stopped carrying the application.

Who takes the first report

Decide in advance who is paged first, what each side is cleared to read, and the point at which the case changes hands. Supply the endpoint, the attempt time and the permitted flow so both sides can correlate the same event.

A narrow state summary is usually more useful than an unredacted configuration, and it does not leak secrets. Monitoring belongs to whoever owns the component rather than to whoever owns the logo, so ask which party sees the tunnel state, which sees the application, and who is woken by each alert. Put the out-of-hours route beside every alert, because a dashboard nobody is on call for is documentation.

Define change authority with the same care. A provider editing a selector while the customer edits NAT makes both local configurations look plausible and the tunnel still fails.

What the label never tells you

Put software upkeep, credential rotation, approved backups of the configuration and the recovery path into the actual agreement. A shared-responsibility model such as the model AWS publishes shows how far the split can move between services, and it is an example rather than a definition of your supplier's terms. Inferring any of it from the phrase half-managed is how a renewal conversation discovers a gap.

The scope should name the normal operator and the escalation path for every dependency. Whatever the quote calls the service, that list is what it means in practice.