Walk the four screens that hold an iPhone VPN config
Four screens hold pieces of one iPhone VPN setup, and no single one holds all of it. Walk them in order and write a record that survives the next handover.
Four places hold pieces of an iPhone VPN setup, and none of them holds the whole thing. The app knows the service it sells, the system knows which configuration the user authorised, the management profile knows what was pushed, and a supported export knows what the vendor is willing to show. Reading them in that order produces a record you can hand to a colleague; reading one and guessing at the rest produces a ticket that gets reopened. The order matters because each screen can only answer part of the question.
Screen one: the app that owns the service
Open the app and note what it calls the connection, which account or subscription it belongs to, and any endpoint, region or protocol it displays. Keep the region separate from the hostname, because a chosen location is not the address the phone dialled. Write down what the screen shows rather than what the marketing page claims.
If the app shows no endpoint at all, that absence is a finding in itself. A service can hide the gateway behind its own API and never expose a hostname to the user.
Screen two: the system entry
Settings, General, VPN and Device Management lists every configuration the system knows about. The VPN row names the active configuration and the type label the system assigns, which is often vaguer than the protocol doing the work. Further down, the profile section lists anything installed by file or by management. Open each entry instead of trusting the row label, because the detail screen is where the server and the identity live.
A downloaded file sitting in the Files app and an installed profile are two different objects, and only the installed one is doing anything.
Screen three: the management payload
When work or school supplied the setup, the payload is the authority and the phone is a copy of it. Read the profile for the identity, the server, any proxy or DNS payload, and the certificate or trust material distributed alongside. A trust payload and a private key are separate objects, and neither one tells you which credential the running session used. Ask the profile owner for that association instead of inferring it from what is installed.
Do not delete the profile to see whether a field becomes editable. Deleting removes the settings and whatever came bundled with them.
Screen four: a supported export
Screenshots answer most questions and fail on the ones that matter. When the detail is genuinely needed, ask the provider which diagnostic export covers that question and whether the file carries account identifiers, tokens or internal names.
Read the file before it leaves the phone. A configuration record that leaks a token is worse than no record at all.
The record you end up with
A usable record names the owning app, the installed profile, the management owner, the implementation type when it is documented, the traffic scope and where the credentials came from. Add a connection result only if somebody observed one through the supported workflow. Leave out anything you cannot point at a screen for.
| Field | Where it comes from | What it settles |
|---|---|---|
| Implementation | App plus system row | Which component owns the tunnel |
| Identity | Profile payload | Who the gateway authenticates |
| Scope | Payload and app display | Which traffic enters the tunnel |
| Credential source | Profile owner | What has to be reissued |
Keep the record next to the device in the inventory. When the phone is replaced, it says what must be issued again rather than restored from a backup.