Retired VPN Clients: Identify the Gateway Protocol First

Installers for VPN clients that went end-of-life years ago still run, still ask for a profile, and then finish a login that never passes a packet. The machine is current and the credentials are right, yet the gateway is the same appliance the company bought a decade ago. Replacing the client is the correct move, but only once you know which protocol that gateway publishes. The four retired clients in this corner do not speak the same one.

Why the brand name does not tell you the protocol

One appliance family can terminate several remote-access protocols, and the marketing name on the box says nothing about which one your account uses. Cisco gear has carried IPsec with XAuth and SSL VPN through AnyConnect at the same time; SonicWall boxes offer Global VPN Client over IPsec and NetExtender over SSL VPN; Juniper deployments can expose Network Connect or the newer Pulse protocol. Installing whichever successor looks most modern is guesswork. The wrong guess either fails to connect or authenticates into a session that carries no traffic.

A portal page loading in a browser proves that a web service answers, not that a particular client will negotiate with it. Treat those as two separate facts.

Ask the gateway what it speaks

The cheapest way to narrow the options is to read what the endpoint returns, then name a protocol explicitly when you try a client. Neither step changes anything on the server.

curl -sS -I https://vpn.example.com/ | head -n 5
openconnect --protocol=anyconnect vpn.example.com

Response headers and the login path show whether an SSL VPN portal lives at that address, which points at AnyConnect, NetExtender or Pulse rather than at an IPsec client. openconnect puts the protocol choice on the command line, so a failure names a protocol instead of a product; swap in --protocol=npulse when the deployment is Juniper. Stop at the first prompt that asks for credentials you were not issued, because a working tunnel still needs an approved account. Record the protocol and path in the change ticket for the next machine.

Weigh four candidate replacements

Four routes cover almost every case, and they are not interchangeable. A vendor successor is the supported path when the organization owns the gateway and will license it. OpenConnect is the practical open client, because it speaks AnyConnect, Network Connect and Pulse when you name the protocol instead of letting it guess.

strongSwan handles the IPsec-with-XAuth case for organizations that permit third-party clients, and it sidesteps the abandoned Cisco IPsec code altogether. The Shrew Soft client keeps reading Cisco profile files and runs on some Windows builds, but its last release was 2013. Treat it as a stopgap while a supported path is arranged.

Decide between repair and replacement

Some failures are local: a missing library, a stale virtual adapter, or an installer that needs the vendor's repair option. Those are worth one attempt while the client remains supported, because they cost minutes. The calculation changes when the binary is out of support and the breakage arrived with an operating-system upgrade, since driver signing and kernel-extension rules have moved since these clients were written. A client that connects while the tunnel counter shows zero established sessions is usually past repair, not one reinstall away.

Keep the old client installed only long enough to export its profile, then remove it. Two VPN clients competing for the same routes produce symptoms that look like neither one.

Write the order on the ticket: protocol and approved client from the owner, a supported successor if it installs, one open client tested on a single machine if it does not, and a supported access path if neither works. That sequence keeps the next person from downloading another retired binary.