Match the Linux VPN client to the old appliance's protocol

Four protocol families cover almost every appliance still sitting in a rack, and each one fails differently on Linux. The far end's published ports and configured proposals decide your package, not the distribution you happen to run. Installing whatever a forum post mentions and then editing until something connects is how an afternoon disappears. Read the appliance, install second, verify third.

Record what the far end publishes

Write down the protocol, the ports and the authentication the appliance expects before you open a package manager. Four families cover most old equipment, and the table below is the whole decision in one screen.

The manual and the appliance's own firewall rules are more trustworthy than the protocol name on its login page. A device advertising IPsec may only speak IKEv1, and a firmware release nobody applied may be what eventually adds IKEv2. Confirm the data path as well as the setup port, because that is where old equipment and modern networks disagree. Getting this step wrong means debugging your client against a feature the other end never had.

PPTP: prove GRE before you edit pppd

PPTP on Linux is not a daemon you start but a pppd invocation, and the connection parameters live in a named peer file that pppd reads when it is called. Distributions still package it, though the protocol's known weaknesses make it unsuitable for anything sensitive, so keep it strictly for an appliance that offers nothing else. Watch for GRE while the client negotiates, using a short capture rather than a guess. The failure that wastes the most time is not authentication but the missing data path.

pppd call branch-office
tcpdump -ni any proto gre -c 5

If setup completes and the link never carries traffic, suspect the GRE path before touching credentials. Cloud security groups need an explicit rule for protocol 47, and some networks block it outright without a visible error. Test from the network you will actually use, not from a lab that permits everything.

L2TP/IPsec: one matching proposal beats ten attempts

Read the daemon log rather than the desktop dialog, because the dialog collapses several distinct failures into a single message. A NO_PROPOSAL_CHOSEN error belongs to phase one: the client offered an encryption, hash or Diffie-Hellman group the server will not accept. Enumerate what the appliance supports and write one proposal that matches it, since random combinations mostly produce the same error more slowly. On a desktop the practical client is the NetworkManager L2TP plugin with strongSwan or Libreswan underneath.

A proposal string that means one thing to a desktop plugin can mean something else to the daemon it hands the work to, so keep the syntax appropriate to the layer you are editing. If the appliance also demands a tunnel secret, that is a separate stage from the IPsec key. Confirm which one the interface is asking for before typing anything into it.

IKEv1 aggressive with XAuth, and the portal case

A FortiGate-style endpoint usually wants aggressive mode with XAuth and a configured-mode address, which a graphical plugin may not expose at all. The native daemon handles it, and the block below is the shape of that configuration rather than a complete file. Check the vendor's current documentation for the proposal values.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Older strongSwan releases used xauth=client where version 5 uses leftauth2=xauth, so a copied snippet can fail on syntax alone. For a TLS portal, openconnect speaking the AnyConnect protocol handles Cisco and most rebrands, and it needs a TUN device plus the privileges to configure it. Pass the portal address exactly as the browser shows it, including any path the appliance expects, then check the assigned address before testing anything behind it. Pre-creating the interface removes one class of surprise during setup.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Connect, then verify in a fixed order

Run exactly one VPN manager at a time, because a NetworkManager profile and a hand-started daemon will fight over routes and DNS. Bring the profile down before testing a manual connection, and confirm no stale tunnel interface survives. Then verify in this order: tunnel address, route to the single internal host you need, name resolution, and finally an actual request. A green icon proves authentication and nothing else.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

If a step fails, stop there instead of testing the next one, since a DNS failure downstream of a broken route teaches you nothing. Save a copy of the working profile before experimenting, because a deleted connection file is easy to lose and tedious to reconstruct. Keep the proposal values in the same note as the appliance model and firmware version, since that note is the difference between a migration and an archaeology project when the box is replaced.