vpnc Against Check Point or Nortel: Why It Hangs

The symptom is easy to misread: vpnc starts, asks for the group password, then sits at a negotiation step until it reports no response from the target. Nothing in the output mentions the gateway product, and the account works from a browser, so the obvious conclusion is a wrong password or a blocked port. In most of these cases the gateway is not an IPsec peer at all, so the exchange never gets far enough to test credentials. That pattern is worth testing before anything else in the profile changes.

Identify the product before editing another profile field.

The Failure Looks Like Bad Credentials

vpnc begins by sending IKE to UDP 500 and, if NAT traversal is offered, UDP 4500. A gateway that terminates SSL instead of IPsec answers neither, so the client retries and eventually gives up with a generic error. If the same account works through a browser portal that loads a small helper application, that is a strong hint the tunnel is SSL-based and the client is asking the wrong question.

A failed attempt here says nothing about the user account, because no credential was ever presented to the gateway.

Check Which Protocol the Gateway Offers

Two minutes of probing separates an IPsec peer from an SSL portal. Run these from the same network the client will use, and read which ports answer rather than which ones appear in a document. Keep the result, because those same ports decide which client the gateway owner should support. Probe from the client network rather than from a host beside the gateway.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

An open 443 with a redirect to a login page and silence on 500 and 4500 points at an SSL VPN. Open 500 and 4500 with a certificate served on 443 suggests an IPsec gateway that also runs a web front end, which is the case vpnc was built for.

Check Point's SSL Network Extender and Nortel's Aventail client both live in the second category, and neither accepts an IKEv1 group secret.

What vpnc's Profile Can and Cannot Express

Under the hood vpnc runs IKEv1 against a group pre-shared key, then sends the individual user's credentials through XAuth. Everything in its configuration file belongs to that exchange: gateway, group name, group secret, user name and user password. Those fields describe one protocol, and no combination of them can make the client speak another.

That is why widening the cipher list or disabling certificate checks never fixes this class of failure. Those changes weaken a negotiation that the gateway is not listening for.

Choosing the Client That Matches the Gateway

For a Check Point gateway, use the SNX package built for that gateway release, which the vendor publishes alongside its remote-access documentation. Older SNX builds frequently fail on current distributions because they expect 32-bit libraries that are no longer installed, and patching an abandoned package is usually worse than running the supported client on a supported platform.

Aventail clients left support long ago. Where such a gateway is still in service, the realistic choices are the browser portal if the organisation enables it, or the vendor's supported client on a supported operating system.

Ask the gateway owner for the product and version, the client they support on Linux, and whether an IPsec profile exists at all. If one does, request the group identifier and group secret as separate items, because they are not the user password and a mixed-up pair is the other common cause of a failed tunnel. When a connection finally succeeds, record which protocol was negotiated so the next person starts from a fact instead of repeating the same guess.