FortiGate IPsec on Linux: Which Client Actually Connects

Your Windows colleague imports a FortiGate wizard profile and is online in a minute. You install the same vendor package on Ubuntu, look for an IPsec tab, and find a client that only knows how to open an SSL VPN portal. The conclusion that follows is usually wrong twice: the gateway is not rejecting you, and the Linux build is not broken. Fortinet ships that client with SSL VPN support only, so a mobile IPsec profile has no place to live and has to be rebuilt somewhere that speaks IKEv1.

That rebuild is mechanical once you stop treating the vendor client as the reference implementation.

First, decide which protocol you were actually given

FortiGate devices publish both SSL VPN and IPsec, and the handover email rarely says which one you were granted. A portal URL plus a browser-style login page means SSL VPN, and on Linux the answer there is openfortivpn, not the field mapping below. A group identifier plus a pre-shared key means mobile IPsec, which is what vpnc and strongSwan handle.

Getting this wrong is the single most common reason a Linux attempt dies before the first phase completes: the client is offering IKEv1 to an HTTPS portal or vice versa. Ask the administrator for the protocol name in writing before you install anything.

Four credentials travel in four different fields

The word password appears twice in most handovers and means two different things. The pre-shared key authenticates the peer itself, and it is a machine secret that the administrator reads out of the gateway configuration. Your account password is a separate credential that proves which human is behind that peer.

The other two values are easier to miss. The group identifier is the string the wizard wrote into the IPsec group object, and 0 is a legitimate value rather than an empty field. The proposal covers encryption, hashing and a Diffie-Hellman group for each phase, plus the PFS setting, and every item in it has to agree with the gateway. When a connection fails at phase 1, one of those four is nearly always the culprit, so write them down separately instead of dropping them into one dialog.

What each vpnc field has to contain

Install the client together with the editor front end, then create a VPNC connection:

sudo apt install vpnc network-manager-vpnc network-manager-vpnc-gnome

Set the gateway to the FortiGate public address, and set the group name to exactly the identifier from the gateway, including a bare zero. Group password takes the pre-shared key, while user name and password take your account, with any token appended as the gateway expects. In the advanced dialog, pick the Diffie-Hellman group the proposal names, match PFS to the same group, enable NAT traversal when the client sits behind a home router, and leave dead peer detection in step with the gateway.

The group name is the field that gets skipped, because it looks optional and the default of zero resembles a placeholder. Send it as blank and the client transmits a different identifier than the one the gateway validates. If the profile still fails, compare the advanced values against the working Windows client rather than against a forum post for a different site.

The same profile written for strongSwan

strongSwan is the better long-term container for these values, since the configuration is a text file you can review and keep:

conn office-fw
    keyexchange=ikev1
    aggressive=yes
    left=%any
    leftauth=psk
    leftauth2=xauth
    xauth_identity=YOUR_USER
    right=GATEWAY_ADDRESS
    rightauth=psk
    rightsubnet=OFFICE_SUBNET
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!

Read the proposal lines before the block, because the trailing exclamation mark changes their meaning: it pins that single proposal and removes the alternatives the client would otherwise offer. A gateway configured for one transform pair will reject a client that opens with a list, so the pin is what turns a negotiation into a match. Take the exact algorithm names from the working gateway profile, and replace the placeholders with your own values.

The two authentication lines are not redundant. The PSK proves the peer, the XAuth block proves the user, and dropping either one leaves a phase that the gateway will not finish.

Read the failure before you change another field

Work backwards from the symptom instead of re-randomising the dialog. An IKE SA that comes up with no assigned address means the user authentication exchange failed or never ran, so check the account and the token handling. A phase 1 that never completes points at the proposal, the group identifier or aggressive mode, and each of those is compared against the gateway, not against the Windows client alone.

A tunnel that establishes and then dies every few minutes is a dead peer detection disagreement between the two ends; match the gateway timer rather than disabling keepalives everywhere. An established tunnel where office hosts stay unreachable usually means the pushed subnet never landed in the local routing table, which a third-party client may not do on its own.

Hand the working values back to the gateway owner when you finish: protocol, group identifier, pre-shared key, proposal, PFS and the DPD decision. The next Linux machine then takes minutes instead of an evening, and nobody has to rediscover that the group name was zero.