OpenVPN Connect Tasker Intent: Profile ID, Not the Name

An automation that connected reliably for months stops working after a client update, while the same profile still connects by hand. That pattern points at the control contract rather than the VPN server. Someone changed which action the app accepts, or which identifier it expects, and the task is still sending the old one. Rebuilding the binding takes less time than re-checking the server.

The contract belongs to one app and one version range

OpenVPN Connect and OpenVPN for Android are different applications, and an intent that names one package does nothing in the other. Before touching the task, confirm which client is installed and which version produced the behaviour you are comparing against. For Connect on Android 3.3.2 and newer, the documented Tasker integration expects a profile ID. Older instructions that prefix a display name with AS or PC describe a previous contract, and copying them into a current task is the usual reason nothing happens.

That version boundary explains most "it used to work" reports. The app did not break the feature; it changed what the feature accepts. Treat the version range as part of the contract you are writing against.

Where the identifier comes from

Open the intended profile inside Connect and copy its Profile ID from the profile's own details. Use that value rather than a name you recognise from the list, because the name is a label and the identifier is what the app matches against. The connect fields in Tasker's Send Intent action look like the block below, with only the identifier replaced. Keep the personal or work-profile app instance consistent too.

Action: net.openvpn.openvpn.CONNECT
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_ID:'PROFILE_ID'
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

A work-profile copy with the same package name and a different stored profile will accept the intent and find no matching profile, which looks like a broken task rather than a scope mistake. If the profile is reimported or replaced, treat the identifier as suspect and check it again. Reimporting commonly produces a new profile entry even when the display name is unchanged. Check the identifier before you change anything else.

Leave unrelated fields empty as documented. Category, MIME type and data fields that the guide does not ask for can change how Android resolves the intent, and an intent that resolves differently may launch the app without starting your profile.

What the action does, and what it leaves to you

Sending the connect intent asks the app to start a profile. It does not bypass whatever authorization that profile requires. Connect may still show a prompt, which is why the documented autonomous case assumes no further authorization or saved connectivity credentials. The temptation is to remove that boundary by embedding passwords or private-key secrets in a shared Tasker export.

Do not do that. A task export is a text file that people copy into chat threads, and secrets placed there are disclosed the moment it is shared. Use the app's own saved connectivity credentials if the profile needs them, and let MFA prompts remain prompts. Anything that avoids the prompt by storing the answer has moved the secret rather than solved the problem.

The disconnect side has its own documented action, and it is not a trick played on the client:

Action: net.openvpn.openvpn.DISCONNECT
Extra: net.openvpn.openvpn.STOP:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

Connecting to a deliberately nonexistent profile to force a disconnect is the kind of workaround that appears in old threads and then fails silently after an update. Use the explicit action.

Check the state before the next step runs

A successful intent launch proves the request was delivered, not that a tunnel exists. If the task then opens an internal application, that step needs a readiness condition with a bounded timeout. An immediate action after the send will eventually fire against a prompt.

$ adb shell cmd package resolve-activity --brief net.openvpn.openvpn
net.openvpn.openvpn/net.openvpn.unified.MainActivity
$ adb shell dumpsys activity activities | grep -i openvpn

The resolve query confirms the package and activity you are targeting exist on that device, which rules out a typo in the class field. The activity dump shows what is actually in the foreground after your task runs, and it is the cheapest way to see whether the app opened a prompt instead of connecting. Run both after a failed task rather than guessing which field is wrong. A mismatch in the class name produces an immediate error, while a missing profile produces no visible error at all.

Decide ownership of disconnection before you ship the task. A shortcut that tears down a tunnel another work task depends on will generate a support ticket that looks nothing like its cause. Keeping two automations that both control the same client produces a race you cannot debug from the logs, so delete the obsolete action once the new one works.