“VPN not working” describes the outcome, but it does not show where the process stopped. A useful problem report separates download, import, permission, connection, and post-connection behavior. That lets the person reviewing the issue focus on the right stage without asking you to repeat the same tests.

The goal is not to collect everything. It is to record a small set of facts while the issue is happening, without sharing a profile file, credentials, session information, or other private access material.

Start with the stage, not the conclusion

First identify the last step that worked:

  1. The profile file downloaded.
  2. The compatible client opened the file or accepted Upload File.
  3. The profile was imported or saved.
  4. The operating system allowed the VPN configuration.
  5. The client attempted to connect.
  6. The client showed an active connection.
  7. Internet access and expected services worked after connection.

A report such as “Import succeeded, but Connect returns to disconnected after ten seconds” is much more useful than “The VPN is broken.” It narrows the problem to a specific transition.

If you are unsure, say that. “I cannot tell whether import completed” is still useful because it identifies the first thing that needs confirmation.

Record device and client details

Include the basics:

Avoid guessing the version. Use the version shown by the device or client. Small software differences can change permission screens, status wording, and background behavior.

Do not assume that because the same profile works on one device, every other device has the same client capabilities or operating-system behavior.

Record the network context

Network conditions matter. Note:

Do not alter router, firewall, or organization network settings merely to create a comparison. A simple test on another network you are allowed to use is enough when such a test is appropriate.

Copy exact status wording

Write down the exact client status or error text, including punctuation when practical. Do not replace it with your interpretation.

For example:

The second sentence assumes a cause that may not be correct. Exact wording preserves evidence.

Also record whether the message appears during import, when you press Connect, or after the client has shown an active connection. The same words can mean different things at different stages.

Build a simple timeline

A short timeline often reveals the trigger:

You do not need a long diary. Three or four lines are usually enough.

Example:

Monday morning: connected successfully on home Wi-Fi.
Monday evening: operating system updated.
Tuesday morning: profile still imports, but Connect returns to disconnected.
Tuesday afternoon: same result on mobile data.

That record is clearer than trying several unrelated changes and reporting only the final state.

Use screenshots carefully

A screenshot can preserve a status message or permission prompt, but review it before sharing. Crop or obscure unrelated information such as:

Do not include the profile file itself in a screenshot. Do not open sensitive profile content just to prove that a file exists.

A screenshot of the client status area is often enough. Pair it with text describing the stage and time because an image alone may not show what happened immediately before it.

What never to share

Do not send:

A legitimate diagnostic can usually start with metadata: device, version, stage, status wording, network type, and timeline. If a formal process requires more, follow that process and confirm the recipient and channel first.

A reusable problem-report template

Copy this structure into your notes:

Device:
Operating system/version:
VPN client/version:
Personal or managed device:
Assigned profile: current/uncertain
Network used:
Ordinary internet before VPN: yes/no
Last successful stage:
Exact status or error wording:
Approximate date/time:
Last known successful connection:
Recent changes:
Result on another allowed network or device:
Screenshot reviewed for private information: yes/no

This template avoids asking you to expose the profile's contents.

Why controlled tests matter

Change one variable at a time. For example, keep the same device, client, and profile while testing a second allowed network. Or keep the same network and profile while comparing an authorized second device.

If you import several copies, change clients, change networks, and alter device settings in one pass, the final result does not show which change mattered. Controlled tests produce a shorter and safer problem report.

Stop when the evidence is sufficient. More tests are not automatically better, especially on managed devices or restricted networks.

The short version

A useful VPN problem report identifies the exact stage, device, operating system, client, network, status wording, timing, and recent changes. Preserve evidence before changing several things. Share only the minimum necessary information, and keep profile files, credentials, tokens, and other private access material out of the report.

Frequently asked questions

What is the most important detail to record?
The last stage that worked and the exact stage that failed. “Imported but did not connect” is more actionable than “not working.”

Should I attach my VPN profile file?
Not as a routine first step. Start with device, client, stage, network, and exact status. Use only an explicitly authorized process if additional material is required.

Are screenshots useful?
Yes, when they show the relevant prompt or status and have been reviewed to hide unrelated private information.

Should I try many fixes before asking for help?
No. A few controlled checks are more useful than many simultaneous changes.

Why include the approximate date and time?
It helps correlate the issue with software changes, profile lifecycle events, network changes, and service records without exposing credentials.