OpenConnect on macOS: package, release tarball or git clone

Three paths get you an OpenConnect client on a Mac, and they leave different things on the disk. A Homebrew formula installs a compiled binary plus the network script that configures routes and DNS. A release tarball gives you source with a generated build system. A git checkout gives you source without one. Choosing the wrong one is why people meet a missing configure a few minutes into a tutorial.

Two different machines under the same name

The packaged path is a single command, and it is the right default for anyone whose job is connecting rather than developing.

brew install openconnect

What that installs matters more than the command. You get the client binary, and you also get a vpnc-script that the client calls to program the interface, the routes and the resolver. The two work as a pair: the binary terminates the TLS session and hands the resulting interface to the script, which is the part that knows how this operating system wants its network changed.

That split explains a whole class of confusing reports. A client that connects, reports success and then sends traffic down the wrong path is usually a script problem, not a tunnel problem, and reinstalling the formula fixes it only because the script gets reinstalled too. Check the formula's current macOS and CPU architecture support before you plan around it; a Mac that runs a shell perfectly well may still have no current package built for it.

What the source route really does

A release archive arrives with a generated build system, so the familiar ./configure exists from the start. A git checkout does not, because the generated files are build products rather than things the project stores. That is the entire reason ./autogen.sh appears in the instructions for checkouts and not for release archives.

./autogen.sh
./configure
make
make install

Each line does something specific, and knowing which one failed saves a lot of guessing. The autogen step runs the autotools to produce configure. The configure step probes for the compiler, libraries and headers the client needs, then writes the makefiles that reflect what it found. The make step compiles. The install step copies the results somewhere on your path.

That last line is where advice usually goes wrong. Installation is not proof that the build worked, and running it in an arbitrary download folder with elevated privileges is a good way to scatter files you will not remember later. If configure fails on a missing library, the useful output is the first error it printed, not the last twenty lines of the log.

The session and the network configuration are separate

This distinction decides whether a connection actually carries traffic. Establishing the TLS session gives you an interface on the client side. Applying routes, addresses and DNS resolvers is a second step performed through the network script, and a build that produced a binary without the script has half a client.

The same separation explains why two machines with identical clients behave differently: the script consults the system's network configuration, and that configuration includes whatever else has claimed a route. When a split tunnel sends traffic somewhere unexpected, the tunnel is doing its job and the routing decision is the thing to examine.

So when you debug, ask which layer failed. A session that never establishes is protocol, certificate or credentials. A session that establishes and forwards nothing is the interface and the script. An installed client that works from one network and not another is reachability, which no amount of rebuilding changes.

Know which binary you are running

A hand-installed build and a packaged binary can coexist happily, and the one that runs depends on your path rather than your intentions. Find out before you report a version number to anyone.

which -a openconnect
openconnect --version
brew list --versions openconnect

The first command lists every copy your shell can see, in the order it would try them. The second tells you which one answered. When those disagree with what you expect, you are running a build from an old experiment, and no configuration change will move it.

Installing a client is not gateway approval

A working binary does not make a deployment compatible. Confirm the gateway's protocol, its authentication flow and any managed-device requirement with the people who own it, because those are policy and application-layer facts that a build cannot supply.

The project's build instructions cover the autotools sequence and the network script requirement in more detail, and they are the reference to follow rather than a blog post that predates your macOS release. If the goal is simply to connect, take the package, keep the script, and leave the compiler out of it.