Pi VPN server: start from the phone app, not the recipe

Most Pi VPN builds start with the server recipe and end with a phone that cannot connect. The order is backwards. A phone client implements a specific protocol with a specific authentication exchange, and the server has to match that exchange rather than the other way round. Deciding the app first turns an afternoon of debugging into a short checklist.

The order that saves the rebuild

Write down the phone's operating system and the exact VPN application before installing anything on the Pi. That pair determines which protocol is even possible. A client app does not become a different client because a profile happens to contain a familiar field.

A shared secret in a profile, or a port number that looks familiar, does not convert one protocol into another. The exchange either matches what the app implements or it fails at a stage that gives you very little to read. There is no diagnostic that says "wrong protocol" in plain words. You get a timeout, a certificate error or a silent retry loop, all of which look like a server problem.

Once the app is fixed, the server choice narrows and the rest of the build has a target.

What the phone app actually implements

A published client listing describes an application, not a service. The OpenVPN Connect app for Android expects an OpenVPN server; it does not provide the server side. Nor does it become an IPsec or L2TP client when a profile looks similar.

That distinction matters most when following an older guide. Recipes written for a protocol the current app dropped will still install cleanly on the Pi and still fail on the phone, which reads like a configuration error rather than a protocol mismatch.

Check the app's current documentation for the profile formats it imports before committing to a server package. Five minutes of reading beats a rebuild.

The four-part agreement

Record four things and keep them together: the phone OS and app release, the server implementation on the Pi, the authentication and trust policy, and the external endpoint. Every one of the four can invalidate the other three.

An app upgrade, a change of server package or a new certificate authority all break the agreement, and the failure looks identical from the phone each time. Having the four written down is what lets you identify which part moved.

Credentials have separate jobs

Decide whether the profile uses client certificates, a username and password, or a supported combination, and make both ends agree. The server's identity and the trusted CA material also have to match what the client will accept.

The CA's public certificate and its signing private key are different objects. Only the public part belongs in a phone profile. Putting the signing key on a phone hands out the ability to mint identities, which is the opposite of what a CA is for. Treat that file as the most sensitive object in the whole build.

Use the service's supported export and import workflow rather than assembling a profile by hand. Hand-built profiles tend to carry desktop-only directives that the mobile app ignores or rejects.

Above all, do not replace certificate validation with "accept any server" to make a legacy example connect. That converts a compatibility problem into an authentication bypass, and it usually survives into production because it works.

Reachability is a separate contract

The phone has to reach the server's external endpoint through the real upstream arrangement. Home-router translation, filtering and carrier NAT all sit between the two. A dynamic DNS name only gives the endpoint a stable name; it does not create an inbound path.

Then define what the client may reach once connected: private prefixes or a full internet exit, their forwarding and reply paths, DNS behaviour, and whether IPv6 is in scope. A successful login proves none of those.

Accept the intended phone and profile directly, including a check that an unauthorised resource stays unreachable and that revocation actually removes access. Success with a desktop client validates that desktop client, not the phone in your hand. The OpenVPN Connect listing is a concrete example of a client application that expects a matching service.