Skip to main content

External VPN gateways: FortiGate and other IKEv2

Applies to: SimpleTwo 0.9.x · Checked: 26.10.2026

If the organisation already runs a VPN gateway of its own — a FortiGate, or any other that accepts an IKEv2 dial-up — SimpleTwo Connect reaches it itself, beside the tunnels to SimpleTwo's gateways. The device keeps one VPN: SimpleTwo's routing rules decide what goes into the tunnel to your gateway, what to SimpleTwo's gateways and what goes direct. FortiClient is not needed, and the gateway and its RADIUS need no changes: people sign in to the gateway with their own directory login and password, as they do in FortiClient.

1. How it works​

  • The gateway authenticates with a pre-shared key (PSK) or with its certificate, the person with EAP-MSCHAPv2 and their own login and password. The gateway then checks those the way it does for FortiClient: through RADIUS (NPS, for one), LDAP or local users. Which way the gateway is checked is chosen in the console (§4). The certificate is the stronger: every device the gateway is allowed to holds the pre-shared key, and nobody can pose as the gateway with a certificate. The gateway is checked before the app sends the password.
  • The password comes from the sign-in to SimpleTwo. When a person signs in with a password, the app keeps that password on the device only: in the keychain on iOS and macOS, in the session's encrypted storage on Android, under the current user's DPAPI on Windows. It goes with the session (sign-out, revocation, an expired session). It never reaches the server or the tunnel's configuration: the app hands it to the tunnel engine by a separate call.
  • If the app never saw a password — the person signed in through the browser (single sign-on) or with a passkey — the Connect screen shows a "Password for the corporate network" card. The password is typed once and kept the same way.
  • The coordinator keeps the pre-shared key and the gateway's parameters. A client receives them with its session's parameters, and only when that gateway is allowed to it. The console never shows the key back once saved. For a gateway checked by its certificate, no key goes to the devices.
  • The tunnel comes up with the first connection into the corporate network, not when the VPN is switched on. The client checks the gateway is alive every 15 seconds. After a drop it reconnects with a growing pause, from 2 seconds to a minute. A refused password is not tried again on the client's own — not after a while, not when the tunnel restarts: the next attempt is with the password the person enters on the card. So after a password change in the directory, a device holding the old one does not run up the failed-login count. The client tries again by itself only when the gateway's parameters change in the console (the pre-shared key corrected, say) or the app starts anew — one attempt.
  • While the gateway is unreachable, its networks are blocked, not sent past the tunnel to the internet.

2. What the gateway needs​

ParameterWhat it must be
ProtocolIKEv2. The client does not support IKEv1 or XAuth
Tunnel typedial-up (dynamic), accepting any client identity
Gateway authenticationa pre-shared key (PSK), at least 8 characters, or the gateway's certificate (an RSA or RFC 7427 signature). The certificate must name the "Server" address in its Subject Alternative Name — a *.example.com wildcard will do, an IP address needs an IP SAN — and chain to the CA given in the console or to one the device's system trusts
Person's authenticationEAP, method MSCHAPv2. If the gateway asks for the Identity first (eap-identity send-request), the client answers with the login; another EAP method it refuses, asking for MSCHAPv2. The client cannot answer a second factor (a code, a push): this tunnel must not ask for one
Client addressassigned from a pool through mode-config. Without an address the tunnel does not come up
Phase 1 (IKE)AES-GCM-256 or -128 or ChaCha20-Poly1305 with a SHA-256/384/512 PRF; or AES-CBC-256 with HMAC-SHA-256. DH groups: 31 (Curve25519), 19, 20, 14 — the client starts with 31 and moves to the one the gateway names
Phase 2 (ESP)AES-GCM-256 or -128, ChaCha20-Poly1305, or AES-CBC-256 with HMAC-SHA-256. PFS off: the client rekeys ESP without a new DH group
Traffic selectors0.0.0.0/0 — what actually enters the tunnel is decided by SimpleTwo's rules
Ports from outsideUDP 500 and 4500. For IPsec over TCP, the TCP port set in the console (4500 by default)
Firewall policyfrom the tunnel into the networks listed in the SimpleTwo gateway group (§4)

The login's form. The client sends the login as the person typed it at the sign-in to SimpleTwo — usually user@domain. Make sure on the first connection that the RADIUS policy accepts that form.

3. A FortiGate example​

A tunnel of its own for SimpleTwo is easier to troubleshoot than one shared with FortiClient. Below is a sketch for FortiOS 7.x checking people through RADIUS. Replace the interface names, the pool and the networks with yours, and check the parameter names against your FortiOS version's documentation.

config user radius
    edit "nps"
        set server "10.20.0.10"
        set secret "<RADIUS secret>"
        set auth-type ms_chap_v2
    next
end
config user group
    edit "s2-vpn"
        set member "nps"
    next
end
config vpn ipsec phase1-interface
    edit "s2-dialup"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set ipv4-start-ip 10.212.134.10
        set ipv4-end-ip 10.212.134.250
        set ipv4-netmask 255.255.255.0
        set ipv4-dns-server1 10.20.0.53
        set proposal aes256gcm-prfsha256 aes256-sha256
        set dhgrp 19 14
        set eap enable
        set eap-identity send-request
        set authusrgrp "s2-vpn"
        set psksecret "<pre-shared key>"
        set dpd on-idle
    next
end
config vpn ipsec phase2-interface
    edit "s2-dialup"
        set phase1name "s2-dialup"
        set proposal aes256gcm aes256-sha256
        set pfs disable
    next
end
config firewall policy
    edit 0
        set name "s2-dialup-to-corp"
        set srcintf "s2-dialup"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "<corporate networks>"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

The gateway checked by its certificate. In phase 1, instead of psksecret:

config vpn ipsec phase1-interface
    edit "s2-dialup"
        set authmethod signature
        set certificate "<gateway certificate>"
    next
end

The certificate carries the gateway's public name in its SAN and is loaded into the FortiGate with its chain: the FortiGate sends the chain itself. In the SimpleTwo console choose "Certificate" and leave "Gateway identity" empty: the FortiGate presents the name from its certificate, and the client checks the certificate against the "Server". A certificate from a public CA (as a website has) is checked with nothing to set up; for a CA of your own, paste its root certificate into the console.

For IPsec over TCP (networks that let no UDP out), enable the TCP transport for this tunnel on the FortiGate and set the same port in the SimpleTwo console.

4. The coordinator console​

Everything is on the Secure Access tab.

  1. Gateway groups. Create a corporate group of its own for the external gateway and fill in "Served CIDRs" and "Served domains" with the networks and names behind it; internal names with no DNS can go into the "Host map". The group must serve something and must not contain SimpleTwo gateways — otherwise the console refuses: one network, one road.

  2. External gateways (IPsec). Add the gateway:

    FieldWhat to enter
    Namehow the console calls it; the console issues the id itself
    Gateway groupthe group from step 1
    Serverthe gateway's public name or address — no scheme, path or port
    Portempty: 500 over UDP, 4500 over TCP
    TransportUDP; TCP (IPsec over TCP) for networks that let no UDP out
    How the app checks the gateway"Pre-shared key (PSK)" or "Certificate" — as the gateway is set up
    Pre-shared keyin the PSK mode: the same as on the gateway. On an update, an empty field keeps the key
    Gateway CAin the certificate mode: the root certificate (PEM) of the CA that issued the gateway's certificate. Empty: a CA the device's system trusts (a public one)
    Gateway identityoptional. When set, the gateway must present exactly this (on a FortiGate, phase 1's localid), and in the certificate mode its certificate must name it too. Empty: the certificate must name the "Server"
    DNS serverscorporate DNS servers inside the served networks: the group's "Served domains" are resolved through them, inside the tunnel. Empty: the DNS the gateway hands out through mode-config resolves them
    do not offerthe gateway stays in the console and is offered to nobody

  3. Groups → profile. In the row of the directory group that needs access (or the row for everyone), tick the group from step 1 under "Allowed gateway groups". A person who has only this gateway gets it too.

Changes reach a client with its next session: on a reconnect or on the session's scheduled renewal.

5. What people see​

In the "Active locations" card on the Connect screen each external gateway has its own row, "Corporate network · gateway name", with its state: "Opens with the first connection", "Connecting…", "Connected" (with the address the gateway assigned under it), "Password needed", "The password was not accepted", or "Not connected" — with the gateway's error under the row. With "Password needed" and "The password was not accepted", "Password for the corporate network" appears above the card; once a password is entered the client tries again at once.

6. Limits​

  • TCP and UDP pass through the tunnel; ping (ICMP) does not.
  • Only IKEv2: the gateway by a PSK or its certificate, the person by EAP-MSCHAPv2. No sign-in of the person by certificate, no IKEv1 or XAuth, no second factor.
  • In the PSK mode every device the gateway is allowed to knows the pre-shared key — as with FortiClient and a shared key. The person is checked by their own password. In the certificate mode no key is on the devices.
  • Changing the pre-shared key: on the gateway and in the console at once. Clients receive the new key with their next session, and until then their tunnels to the gateway show "The password was not accepted".

7. When it does not connect​

The error text is shown in the app under the tunnel's row.

What is shownWhyWhat to do
"Password needed"no password is kept: a sign-in through the browser or with a passkeyenter the password on the card
"The password was not accepted"the gateway refused the sign-in: the directory password changed; RADIUS refused (the login's form, the policy, a second factor); or the pre-shared key or the gateway identity do not match — the app cannot tell these apartfirst, a new password on the card. If that is refused too: a refusal in the NPS log (event 6273) means RADIUS; no record means checking the PSK and the "Gateway identity"
NO_PROPOSAL_CHOSENthe phase 1 or phase 2 algorithms do not overlap with the client'scompare with §2
"it wants DH group N, and this client offers …"the gateway needs a DH group the client does not haveenable one of §2's groups on the gateway
"the server proves itself with a certificate …, not the PSK"the gateway signs with its certificate and the console says pre-shared keychoose "Certificate" in the console
"the server's certificate was not accepted: … server sent no certificate"the console says certificate and the gateway is checked by a pre-shared keychoose "Pre-shared key (PSK)", or set the gateway to authmethod signature
"the server's certificate was not accepted: … not trusted"the certificate's chain reaches neither the CA in the console nor one the system trustspaste the root certificate of the gateway's CA into the console
"the server's certificate was not accepted: … does not name …"the certificate does not carry the "Server" name (or the "Gateway identity"): an IP address in "Server", sayput the name from the certificate in "Server", or reissue the certificate
"the gateway assigned no inner address"the gateway has no mode-config poolenable mode-config with an address pool
the tunnel works and drops at the first rekeyPFS is on in phase 2turn PFS off for this tunnel
the gateway does not answerUDP 500/4500 are blocked on the waythe TCP transport, in the console and on the gateway
names do not resolveno DNS for the "Served domains"fill in "DNS servers", or hand out DNS through mode-config
an address opens but nothing answersthe network is not in "Served CIDRs", or the gateway's policy does not let it throughadd the network to the group and to the policy

Next​