Wi-Fi join triggers the iPhone VPN: build it action first

Two failures look identical from the outside: a VPN action that cannot complete, and an automation that never ran. Building the connection first and the trigger second separates them in about a minute. It also attaches the automation to something already proven, which removes half the variables before permissions enter the conversation. That order costs nothing and saves the confusion that follows a trigger firing silently.

First build the action, on its own

Create a shortcut with a name you will recognise later, then add the Set VPN action and point it at the saved configuration the phone already has. Choose Connect explicitly rather than a toggle, because a toggle depends on the current state and produces a different result on the second run. Then run the shortcut by hand and complete whatever authentication the profile normally asks for. Do that once with the phone unlocked, so the first run is not also a test of lock behaviour.

If the configuration does not appear in the action at all, stop here and read the provider's own instructions. Some clients do not expose their connection to Shortcuts, and no amount of automation will create that exposure. Check the app's own documentation for a Shortcuts section before assuming the action is broken.

Prove the action before trusting the trigger

Run the shortcut from the app, watch the VPN indicator appear, and open a private resource that only works through the tunnel. A green indicator with a failing service is a routing problem, not an automation problem, and it needs fixing before a trigger sits on top of it. Close the app and reopen it to make sure the service answer came through the tunnel rather than from a cache.

Run it a second time immediately. If the second run disconnects instead of connecting, the action is a toggle in disguise and the automation will produce exactly that behaviour every time the network changes.

Then attach the Wi-Fi automation

Add a personal automation with a Wi-Fi trigger, select the network, and choose to run immediately rather than asking first. Point it at the shortcut you just proved. Turn on the option that allows it to run while the phone is locked only after deciding that this is acceptable for a connection that may need a person.

Walk out of range and back in with the phone in your hand for the first test. Watch whether the automation fires at all before watching what the VPN does.

What an automation still cannot do

It cannot supply a human for an interactive challenge. If the profile opens a web sign-in or asks for a one-time code, the automation stops there, and placing a password or code in a text action to work around it moves a secret into a place with weaker protection.

It also cannot guarantee that nothing leaves the phone before the tunnel is ready. Joining a network and finishing a VPN connection are separate events, so a strict no-traffic-before-tunnel requirement belongs in the connection's own enforcement policy, not in the timing of a shortcut.

When the native On Demand option fits better

For a standing rule such as connect on cellular and stay off on a named network, the app or a managed profile may offer On Demand conditions that the system evaluates continuously. Two mechanisms asking for opposite things produce a tunnel that flaps, so pick one owner.

Be careful with trusted-network exceptions. A network name is a label, and any access point can carry it; decide deliberately what happens on cellular and on unknown networks instead of inheriting a profile that disconnects whenever nothing matches.