Restoring Managed VPN DNS after Android Network Handover

Thank you for joining on short notice. Evan and Meera are here from Android Networking, Joon represents Enterprise Support, and Clara owns System Validation. We have seventeen reports from managed Kestrel phones running maintenance build E24. Users leave office Wi-Fi, switch to mobile data, and find that internal business applications stop opening new sessions. The VPN icon remains visible, and public websites still work in the personal profile. We need a reliable recovery instruction for administrators today and a technical plan that preserves the managed profile's network policy. Please do not describe the whole internet connection as broken; the reports point to a narrower failure.

The affected administrators manage three separate fleets, all using the same enterprise VPN client but different gateways. Existing chat messages sometimes continue arriving, while a newly opened inventory application times out. Several users recovered by restarting the phone, but that interrupts their work and erases the transient state we need. One administrator asked us to disable always-on VPN temporarily. I have not recommended that because their lockdown policy intentionally blocks managed traffic outside the tunnel. Support needs an approved alternative, with a clear warning if it briefly interrupts managed sessions. We also need to know what evidence to collect before recovery.

I reviewed six bug reports. The tunnel is established on the mobile network, and its byte counters continue increasing. A connection to an internal test server by numerical address succeeds, while resolving that server's name fails. That separates tunnel transport from name resolution. It does not prove a resolver defect yet, because the enterprise DNS server might reject queries after an address change. We should compare where the query is sent, which network identifier it carries, and whether the gateway receives it. The VPN icon only tells us that the tunnel interface exists; it cannot certify that every service above it is healthy.

The suspicious event is a resolver configuration callback arriving after the old Wi-Fi network has been removed. E24 added an optimization that avoids rebuilding an unchanged DNS server list. The server addresses remain identical across the handover, but the resolver context includes more than those addresses. It also carries the VPN's underlying network association. If that association remains tied to the removed Wi-Fi network, queries can fail even though the new tunnel route works. I can see a skipped update in the logs, but I need a trace with network identifiers to distinguish a stale context from a gateway-side rejection.

Validation has reproduced the symptom on two devices, but only when Wi-Fi disappears abruptly. A manual switch with both networks available has passed so far. We used a managed profile with lockdown enabled and split DNS, where internal names use the enterprise resolver. I want to keep that configuration fixed for the first experiment. Testing every VPN mode immediately would make the result difficult to interpret. Once we understand the failure, we can expand to full-tunnel and personal-profile controls. The first question is whether a query reaches the VPN gateway after the handover, not whether a browser happens to load a cached page.

Let us define the evidence request before we ask customers for another capture. We should not collect internal hostnames or credentials when a controlled test name will answer the question. Joon, can the administrators provide a dedicated diagnostic hostname and gateway-side query count? Evan and Meera, explain the minimum device metadata needed to correlate the transition. Clara, please separate fresh lookups from existing connections in the test script. The customer impact is serious, but a broad packet dump would create extra handling work without necessarily telling us which context the resolver used.

Two administrators can create a diagnostic name today and return only whether its query reached the gateway. The third fleet cannot change DNS until Monday, so we should not hold the whole investigation for that environment. I can ask for the handover time, build identifier, VPN client version, managed-profile status, and a short system trace around the failure. We will replace actual network names with consistent labels before sharing. The labels must preserve which old network became unavailable and which new network took over; otherwise redaction would remove exactly the relationship we are trying to inspect.

The minimum trace needs network creation and removal, VPN underlying-network changes, resolver configuration generations, and query outcome codes. We do not need query content. In the lab I can add a synthetic lookup identifier to correlate device and gateway counts. If the query fails before transmission with an unavailable-network result, that supports a stale resolver context. If the gateway receives it and rejects it, we must investigate policy or server state instead. A successful numerical-address connection is a useful control, but it must target the same internal endpoint through the same managed profile rather than a public service.

I have a preliminary timeline from Clara's first device. The mobile tunnel becomes ready at second twelve. At second thirteen, the VPN publishes its new underlying network. At second fourteen, the resolver update is skipped because the server address list is unchanged. Fresh lookups then fail locally, and the gateway count stays flat. Restarting the VPN client rebuilds the resolver and restores name resolution. That is a strong chain of evidence, but we should test the inverse: change the DNS list while preserving the same handover. If the optimization is responsible, forcing a configuration difference should prevent the skipped update and the failure.

I can run that paired comparison, and I will add an identical-server-list control with the optimization disabled. That separates the effect of the code change from an incidental server difference. Each test will issue an uncached internal lookup, attempt a new TLS session, and keep one existing connection active. We will record all three outcomes because users care about application recovery, not only resolver success. I will also repeat the abrupt handover in the opposite direction. A Wi-Fi-to-mobile fix that breaks mobile-to-Wi-Fi would not be acceptable, especially for users moving between a warehouse and an office.

For today's support instruction, would restarting only the VPN client be acceptable? Administrators can trigger it through their management console without disabling lockdown. The operating system should continue blocking managed traffic while the tunnel reconnects, but active calls and file transfers may be interrupted. I need a tested duration range and a way to tell whether recovery succeeded. Please do not give us an instruction that says simply reconnect and try again. The administrator should first collect the short trace, perform one controlled restart, and verify a fresh internal lookup before returning the device to work.

That is the safest temporary option we have observed, provided lockdown remains enforced throughout the restart. We should explicitly verify that managed traffic does not escape to the physical network during the gap. I oppose automatic periodic VPN restarts as a workaround; they would mask the defect and repeatedly interrupt sessions. For the code fix, I favor extending the resolver configuration identity to include the underlying network association and its generation. That makes a meaningful context change trigger an update even if DNS addresses are identical. We should avoid resetting every resolver on the device, which would disturb unrelated personal traffic.

I agree on scope, but adding a generation to the comparison is not enough if callbacks arrive out of order. An old callback could overwrite the newly configured context after a rapid double handover. The update path needs to reject a configuration whose generation is older than the current VPN state. It also needs a defined behavior when the underlying network disappears during configuration. I propose retrying only against the latest valid association, with no fallback to the old network. If no association is available, queries should fail with a clear transient error until a valid update arrives.

Would that leave customers with a longer outage than a broad reset? Field teams will challenge a narrow fix if they see it waiting while a restart recovers immediately. We need to explain the difference between correctness and recovery speed, and put a bound on both. I support avoiding personal-profile disruption, but we cannot leave managed applications indefinitely waiting for a callback that may never arrive. Could the networking service detect a missing configuration acknowledgment and request a fresh snapshot from the current VPN state, without tearing down the tunnel or changing its policy?

Yes. We can use a two-second acknowledgment deadline, then request one fresh snapshot from the active VPN record. The retry will carry the current generation and remain scoped to that VPN's resolver. If the snapshot is unavailable, we keep the transient failure visible rather than silently route queries elsewhere. I would expose counters for stale-update rejection, acknowledgment timeout, snapshot refresh, and successful recovery. Those counters let support distinguish a recovered handover from a persistent failure. We should not promise a universal two-second application recovery, because an application may apply its own retry delay after name resolution becomes healthy.

We will issue a targeted administrator advisory today rather than recommend disabling VPN or rolling back every E24 device. The evidence currently points to a specific managed-profile handover path, and unaffected devices should not lose unrelated maintenance fixes. Joon owns the advisory draft by noon Seoul time. Clara must validate the restart procedure and lockdown behavior before it is sent. Evan and Meera own the scoped resolver fix, with a reviewable candidate by four this afternoon. I will keep the three fleet administrators informed and record which environments have supplied evidence, so we do not generalize from one gateway.

The advisory will describe the symptom precisely: fresh internal name lookups fail after an abrupt network handover while the managed VPN remains connected. It will tell administrators to collect the short trace, restart the client once under existing lockdown policy, and verify the diagnostic hostname plus a new application session. We will state that active sessions may be interrupted and schedule recovery outside critical work where possible. If one restart fails, the instruction will escalate with the capture rather than repeat indefinitely. I will avoid asking users to edit DNS settings, disable protection, or supply internal credentials.

I will validate the recovery procedure by eleven thirty, then start the candidate matrix after the four-o'clock build arrives. Coverage includes abrupt and graceful handovers in both directions, rapid double handovers, tunnel reconnect, profile pause and resume, and delayed callbacks. Each case requires a fresh internal lookup, a new session, and proof that managed queries stay within the permitted path. Personal-profile lookups must remain unaffected. We will run fifty transitions per direction on each of two device configurations. Any policy escape is an immediate failure; recovery latency and application retry behavior will be reported separately.

I will own the state-transition review and tests that deliver callbacks in a deliberately wrong order. The candidate must ignore an older generation, apply the current snapshot once, and avoid a retry loop when no physical network is available. I will also test the acknowledgment deadline without real-time sleeps by controlling the test clock. That keeps the unit tests repeatable. The patch description will identify exactly which configuration fields participate in equality and why. We should not replace one incomplete comparison with another undocumented shortcut that breaks when a new VPN capability is added.

I will own the implementation and diagnostic counters. Before four, I will attach the candidate identifier, the unchanged-server-list comparison, and a trace showing the latest VPN generation reaching the resolver. The review will include a failure case where the network disappears during configuration and a recovery case where the acknowledgment is lost. I will not add an automatic tunnel restart to the patch. If the targeted refresh cannot recover a valid active VPN, the counters should show that limitation and trigger further investigation. That gives us a testable boundary rather than a broad reset that happens to make the symptom disappear.

The technical review is Monday, October nineteenth, at ten in the morning Seoul time. Clara will publish the lab results by nine, including failures and unfinished cases. If the candidate passes, we will offer an administrator-approved trial to a small group from the two fleets that can provide diagnostic names. We will not declare the field issue resolved from lab success alone. Closure requires successful handovers in those trial environments and no policy regression. The third fleet remains explicitly unverified until its Monday DNS change is available. I will keep that distinction in the status report.

For the trial, I will ask administrators to record the number of network transitions, not just the number of phones. A device that stays at a desk all day offers little evidence about this defect. We can collect aggregate success counts and recovery counters without internal hostnames. I will also ask whether users had to reopen an application after resolver recovery, because that determines the support wording. If the platform recovers but one application retains a failed session, we should track that separately rather than dismiss the user's continued outage or claim the platform patch failed outright.

I will present resolver recovery time from the valid network update to the first successful uncached lookup. Application recovery time will start at the same event but end at a newly established session. Reporting both avoids confusing the platform's response with an application's backoff timer. For the negative tests, I will capture packet counts on the physical interface and the VPN path to verify lockdown. Any unexpected destination will be investigated before trial approval. I will also include the baseline E24 behavior so reviewers can see that the test reproduces the original failure under identical conditions.

One final clarification: identical DNS addresses do not mean identical resolver state. I will add that principle and the generation-ordering rule to the networking design note, using the handover sequence from our trace. The note will explain how stale callbacks are rejected and why a missing acknowledgment requests a snapshot rather than a tunnel teardown. Future optimizations can still avoid redundant work, but they must compare the full state that affects routing. I will review that note with the VPN integration owner before Monday, so the change becomes a maintained contract instead of knowledge held by the people in this call.

The immediate instruction, patch owners, and review date are agreed. Joon will wait for Clara's recovery validation before sending the advisory, and I will coordinate customer updates through the existing enterprise cases. We will describe what we have observed and what remains unverified, with the next update due this afternoon at five Seoul time. If new evidence shows queries reaching the gateway during failure, we will reopen the server-side hypothesis instead of forcing every report into the stale-context explanation. Thank you; the priority is to restore managed work while keeping the customer's intended network boundary intact.