IPsec Modern IKEv2 Road-Warrior Configuration

IPsec Road-Warrior Configuration: Android 12+ (native), Windows 7+ (native), iOS/iPadOS 9+ (native), macOS 11+ (native), BB10 (native), Android strongSwan app, PlayBook, Dtek mobile devices.

Note: this page is being updated to the swanctl UCI-based configuration, and is viable for 24.10 Wireless Freedom and above. For previous version of non-UCI configuration and foundation docs, see this Wiki's previous version from history at THIS revision.

The basic context of the so-called “road warrior” configuration:

1. Your OpenWrt router is the firewalled IPsec host or gateway that receives requests to connect from mobile IPsec users
2. IPsec users have a dynamically assigned (private) IP outside your private net which changes frequently.
3. IPsec users frequently move around roaming across different networks.
4. IPsec users require access to both internal and external resources (full tunnel support) through a “gateway”.

This is an IPsec IKEv2 setup that recreates the usual client-server VPN setup. IKEv2 is built-in to any modern OS. It is supported in Android as well using the Strongswan app. We'll use route based filtering with an xfrm interface to easily distinguish the VPN traffic.

A note about terminology. IPsec is not a client-server protocol, and it is not a VPN protocol either. Hence, it is incorrect to talk about IPsec servers or IPsec clients. However, on this page, we talk about IPsec-based VPN servers and clients indicating the IPsec gateway or IPsec users respectively.

Examples would be a phone or laptop that wants to VPN into a private home network. Note that Strongswan's IKEv2 with MOBIKE lets you leave VPN up ALL the time on a phone with near-zero battery drain or perceptible performance hit. The benefits of this cannot be overstated for the road warrior.

• Supported version of OpenWrt (opkg will complain about kernel version if not).
• You probably want to have 16MB flash for strongswan to fit in. And 64MB ram to run it properly.
• package: strongswan-swanctl (use opkg install strongswan-swanctl to install)
• package: strongswan-charon and many (not all!!) charon plugins packaged as strongswan-mod-* (Tip: do not install all of them, also don't try to install strongswan-full, it includes the legacy ipsec.conf stuff)
• (optional) OpenSSL CLI (package: openssl-util) (to make the .p12 or PKCS#12 package you distribute to clients directly from the OpenWrt shell)

Depending on the build and the ciphers that you will chose to use, you may also need to install:

• package: kmod-crypto-sha256
• package: kmod-crypto-gcm (more info)
• package: kmod-crypto-ccm

First of all, in case you had other strongswan packages installed, we will disable the old ipsec service:

/etc/init.d/ipsec stop;/etc/init.d/ipsec disable

For testing, you will want to run logread in a scrolling window as follows:

logread && logread -f | grep ipsec

And stop swanctl temporarily

/etc/init.d/swanctl stop

Note after openssl-util packages are installed: You may want to disable LUCI's (actually uhttp's) https redirection by commenting out the two list listen_https lines in /etc/config/uhttpd file.

In this setup, the IKEv2 daemon will assign the router IP as DNS and WINS server to be used by remote clients. For example, here we use servers available on the private LAN, but you can use public ones as well if you like, even for debug-only purposes. If the server runs on the same device you are configuring this strongswan instance, make sure that DNS server is configured to serve local DNS queries, as requests from virtual clients will appear as originating from inside the router. The default DNS server in OpenWrt, dnsmasq, has such an option: make sure it's enabled.

VPN clients will get ip addresses in the 10.0.2.0/24 range and be assigned the vpn firewall zone

config interface 'vpn'
	option ifid '357'
	option tunlink 'wan'
	option mtu '1438'
	option zone 'vpn'
	option proto 'xfrm'

config interface 'vpn_vip'
	option proto 'static'
	option ipaddr '10.0.2.1/24'
	option device '@vpn'

config zone
	option name 'vpn'
	list network 'vpn'
	list network 'vpn_vip'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config 'forwarding'
    option 'src' 'lan'
    option 'dest' 'vpn'
 
config 'forwarding'
    option 'src' 'vpn'
    option 'dest' 'lan'
 
# drop the next section if you don't want your vpn clients to reach the internet 
config 'forwarding'
    option 'src' 'vpn'
    option 'dest' 'wan'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option src 'wan'
	option name 'Allow-IPSec-NAT-T'
	option proto 'udp'
	option dest_port '4500'
	option target 'ACCEPT'

config rule
	option src 'wan'
	option name 'Allow-IPSEC-AH'
	option proto 'ah'
	option target 'ACCEPT'

config ipsec
	list 'interface' 'wan'
	option 'zone' 'vpn'
	option 'debug' '1'

# pubkey
config 'remote' 'rw_pubkey'
    option 'enabled' '1'
    option 'local_identifier' 'myvpnserver.dyndns.org'
    option 'gateway' 'any'
    option 'authentication_method' 'pubkey'
    option 'local_cert' 'serverCert.pem'
    option 'local_key' 'serverKey.pem'
    list 'remote_ca_certs' 'caCert.pem'
    option 'rekeytime' '4h'
    option 'keyingtries' '0'
    option 'mobike' '1'
    option 'send_cert' 'always'
    option 'send_certreq' 'yes'
    option 'fragmentation' '1'
    list   'crypto_proposal' 'ike_proposal'
    list   'tunnel' 'rw_child'
    list   'pools' 'primaryipv4'

# eap-tls
# this needs a minimal patch to /etc/init.d/swanctl (see below)
# config 'remote' 'rw_eap'
#    option 'enabled' '1'
#    option 'local_identifier' 'myvpnserver.dyndns.org'
#    option 'gateway' 'any'
#    option 'authentication_method' 'eap-tls'
#    option 'local_cert' 'serverCert.pem'
#    option 'local_key' 'serverKey.pem'
#    list 'remote_ca_certs' 'caCert.pem'
#    option 'rekeytime' '4h'
#    option 'keyingtries' '0'
#    option 'mobike' '1'
#    option 'send_cert' 'always'
#    option 'send_certreq' 'yes'
#    option 'fragmentation' '1'
#    list   'crypto_proposal' 'ike_proposal'
#    list   'tunnel' 'rw_child'
#    list   'pools' 'primaryipv4'


config 'crypto_proposal' 'ike_proposal'
    option 'encryption_algorithm' 'aes256gcm'
    option 'dh_group' 'modp2048'
    option 'prf_algorithm' 'prfsha256'

config 'tunnel' 'rw_child'
    # if we only want client to use vpn for /our/ lan network:
    # list   'local_subnet' '10.0.1.1/24'
    # or access everything through vpn
    list   'local_subnet' '0.0.0.0/0'
    option 'if_id' '357'
    option 'rekeytime' '1h'
    option 'startaction' 'none'
    option 'closeaction' 'none'
    list   'crypto_proposal' 'esp_proposal'
 
config 'crypto_proposal' 'esp_proposal'
    option 'encryption_algorithm' 'aes256gcm'
    # no hash_algorithm with allowed with AEAD
    option 'dh_group' 'modp2048'

# use this for legacy remote peers, and others who need older algorithms                            
config 'crypto_proposal' 'esp_proposal_legacy'                  
    option 'encryption_algorithm' 'aes256'
    option 'hash_algorithm' 'sha256'
    option 'dh_group' 'modp2048'
      
config pools 'primaryipv4'
	option addrs '10.0.2.2-10.0.2.64'
        list dns '10.0.1.1'

The init script for swanctl is missing support for eap-tls, but the modification needed is minimal:

         local local_auth_method="$auth_method"
         [ "$auth_method" = "eap-mschapv2" ] && local_auth_method="pubkey"
+        [ "$auth_method" = "eap-tls" ] && local_auth_method="pubkey"

         [ "$auth_method" = eap-mschapv2 ] && swanctl_xappend3 "eap_id = $eap_id"      
+        [ "$auth_method" = eap-tls ] && swanctl_xappend3 "eap_id = $eap_id"           
         swanctl_xappend2 "}"     

+        elif [ "$auth_method" = eap-tls ]; then             
+                :  # empty command                             
        else                                                     
                fatal "AuthenticationMode $auth_mode not supported"

Certificates (including (.pem) key files). Make them and put them in corresponding directories according to the “making of certificate/key files” section below. If you are migrating from ipsec config, move the files in swanctl directory: /etc/ipsec.d/cacerts/* → /etc/swanctl/x509ca/* ; /etc/ipsec.d/private/* → /etc/swanctl/private/* ; /etc/ipsec.d/certs/* → /etc/swanctl/x509/*

Start swanctl:

/etc/init.d/swanctl start
 
/etc/init.d/swanctl status

if the last line did not say running, something is wrong. check logs.

We can also check the current status of swanctl:

swanctl --list-conns

You will need the certs/keys no matter what kind of config (ipsec/swanctl) you are using.

To make keys, run this script and follow on-screen instructions. It is intended to be run on the OpenWrt router, but you can also manually run the first half on Linux/WSL and move the needed key and certs into the router thereafter.

Existing CACert would be retained for new server/client certs. Remove/rename client* if you want to regenerate clientCert for another user.

#!/bin/sh
cd ~
COUNTRYNAME="US"
CANAME="xxxxca"
ORGNAME="yyy"
SERVERDOMAINNAME="myvpnserver.dyndns.org"
CLIENTNAMES="myvpnclient" # or more " … myvpnclient2 muvpnclient3"
SHAREDSAN="myVpnClients" # iOS clients need to match a common SAN
 
echo "Building certificates for [ $SERVERDOMAINNAME ] and client [ $CLIENTNAME (aka $SHAREDSAN) ] "
 
if [ -f "caKey.pem" ] ; then
  echo "caKey exists, using existing caKey for signing serverCert and clientCert...."
elif [ -f "ca.p12" ] ; then
  echo "CA keys bundle exists, accessing existing protected caKey for signing serverCert and clientCert...."
  openssl pkcs12 -in ca.p12 -nocerts -out caKey.pem
else
  echo "generating a new cakey for [ $CANAME ]"
  ipsec pki --gen --outform pem > caKey.pem
fi
echo "generating caCert for [ $CANAME ]..."
ipsec pki --self --lifetime 3652 --in caKey.pem --dn "C=$COUNTRYNAME, O=$ORGNAME, CN=$CANAME" --ca --outform pem > caCert.pem
openssl x509 -inform PEM -outform DER -in caCert.pem -out caCert.crt
echo "Now building CA keys bundle, choose a secure password known by IPsec Administrator ONLY"
openssl pkcs12 -export -inkey caKey.pem -in caCert.pem -name "$CANAME" -certfile caCert.pem -caname "$CANAME" -out ca.p12
 
echo "generating server certificates for [ $SERVERDOMAINNAME ]... "
ipsec pki --gen --outform pem > serverKey_$SERVERDOMAINNAME.pem
ipsec pki --pub --in serverKey_$SERVERDOMAINNAME.pem | ipsec pki --issue --lifetime 3652 --cacert caCert.pem --cakey caKey.pem --dn "C=$COUNTRYNAME, O=$ORGNAME, CN=$SERVERDOMAINNAME" --san="$SERVERDOMAINNAME" --flag serverAuth --flag ikeIntermediate --outform pem > serverCert_$SERVERDOMAINNAME.pem
#openssl x509 -inform PEM -outform DER -in serverCert_$SERVERDOMAINNAME.pem -out serverCert_$SERVERDOMAINNAME.crt
 
for CLIENTNAME in $CLIENTNAMES; do
  if [ -f "clientCert_$CLIENTNAME.pem" ] ; then
    echo "clientCert for [ $CLIENTNAME ] exists, not generating new clientCert."
    continue
  fi
  echo "generating clientCert for [ $CLIENTNAME (aka $SHAREDSAN) ]..."
  ipsec pki --gen --outform pem > clientKey_$CLIENTNAME.pem
  ipsec pki --pub --in clientKey_$CLIENTNAME.pem | ipsec pki --issue --lifetime 3652 --cacert caCert.pem --cakey caKey.pem --dn "C=$COUNTRYNAME, O=$ORGNAME, CN=$CLIENTNAME" --san="$CLIENTNAME" --san="$SHAREDSAN" --outform pem > clientCert_$CLIENTNAME.pem
  openssl x509 -inform PEM -outform DER -in clientCert_$CLIENTNAME.pem -out clientCert_$CLIENTNAME.crt
  echo "Now building Client keys bundle for [ $CLIENTNAME ], choose a secure password known by that Client ONLY (this password will only be required to install certificate and key, not for IPsec authentication)"
  openssl pkcs12 -export -inkey clientKey_$CLIENTNAME.pem -in clientCert_$CLIENTNAME.pem -name "$CLIENTNAME" -certfile caCert.pem -caname "$CANAME" -out client_$CLIENTNAME.p12
  rm clientKey_$CLIENTNAME.pem
  openssl x509 -inform PEM -outform DER -in clientCert_$CLIENTNAME.pem -out clientCert_$CLIENTNAME.crt
done
rm caKey.pem

cp caCert.pem /etc/swanctl/x509ca/
echo "copy ca.p12 /somewhere/safe/on/your/pc (includes caCert and caKey, needed to generate more certs for more clients)"
cp serverCert*.pem /etc/swanctl/x509/
cp serverKey*.pem /etc/swanctl/private/ # keep on your router only, delete and regenerate a fresh one if router gets compromised
rm serverKey*.pem
cp clientCert*.pem /etc/swanctl/x509/
echo "copy client_*.p12 /somewhere/safe/on/your/clients"
echo "copy caCert.crt and clientCert_*.crt to /somewhere/safe/on/your/clients for Android clients"

Now install client.p12 on the clients. Note that caCert has been included already in the client.p12 if you used the above commands. If the client platform requires you to install the CA certificate separately, extract that cert from client.p12 or use the caCert.crt file, then install it.

Using an ACME issued certificate (like Let's Encrypt an others) to authenticate the local IPsec server peer is straightforward.

You still need a self-signed CA to issue your clients peer certificates, but this way won't need to install its CA cert in the clients. A benefit from this is that e.g. Windows users can configure a native VPN connection without Administrator privileges.

Obtain a key+certificate, i.e. certbot certonly --standalone -d myvpnserver.dyndns.com The domain name must match the id in /etc/config/ipsec.

The Let's encrypt root certificate is also required.

ln -s /etc/swanctl/privatye/serverKey.pem privkey.pem
ln -s /etc/swanctl/x509/serverCertChain.pem chain.pem
ln -s /etc/swanctl/x509/serverCert.pem cert.pem
cd /etc/swanctl/x509ca/; wget https://letsencrypt.org/certs/isrgrootx1.pem

For testing, the original author of this page used a Blackberry Z10 with NATIVE Ikev2 support (LOVE your Blackberry), an Android phone with the strongSwan app, Windows 7 and 10+ machines using native IKEv2, and a Blackberry DTek running Android with DTek. We have also tested newer (12+) Android versions (for now, tested on 12 and 13) with the system's native IPSec VPN capability which works as expected.

Hint: you can easily email client certs .p12 bundles (and caCert.crt, if needed) to the mobile device users.

Windows natively supports IKEv2 since Windows 7.

By default, Windows uses an old ciphersuite which is not secure and is no more allowed by strongswan defaults. Read here to learn how to edit the Windows registry in order to enable aes256-sha1-modp2048 for IKE. Other ciphers, including more robust ESP proposals and PFS, are available via Set-VpnConnectionIPsecConfiguration PowerShell cmdlet.

It is not recommended to add back the legacy ciphersuite in ipsec.conf to allow Windows clients to connect with default settings. Use the above registry or PowerShell tweaks to match the bare minimum proposals in the provided above ipsec.conf example.

You will need administrative rights to set up this kind of VPN connection. Only traditional desktop editions are supported.

In windows, import your client and CA certificates into Local Machine storage, not Current User. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into Local Machine and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in “Trusted Root Certification Authorities\Certificates” store and the client cert in “My\Certificates” store.

Follow these instructions to set up the Windows VPN connection for using Machine Certificates: https://supportforums.cisco.com/docs/DOC-24022

Please note: this Machine Certificates setup uses Device certificate/key installed in Local Machine keystore and it is not based on EAP. Windows does not support EAP with Device certificate/key from Local Machine keystore for native VPN client.

You don't need administrative rights to set up this kind of VPN connection, but you still need to be an admin in order to import the CA cert only. Modern WinRT-based editions are also supported (including WP8+ mobile editions).

In Windows, import your client and CA certificate into Current User, not Local Machine. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into Current User and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in “Trusted Root Certification Authorities\Certificates” store and the client cert in “My\Certificates” store. Now you need to import this CA as Local Machine, you can do it by using the standalone CA cert from the bove steps or export it from the Current User CA store after p12 import is done.

Create a new VPN connection from the wizard, choose IKEv2 as the type, and select “Certificate” for the authentication method. Connect, and pick your “myvpnclient” cert when prompted. Please note, split-tunneling is enabled by default in Windows 10+ (just google for “disable Split Tunneling Windows” or read here: https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnection?view=win10-ps#examples. The following PowerShell-command will set the chiper suite to match the configuration above (esp_proposal_windows):

Set-VpnConnectionIPsecConfiguration -ConnectionName "myvpnserver" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod GCMAES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -PassThru

Please note: this EAP-TLS setup uses User certificate/key installed in Current User keystore. Windows does not support EAP (including EAP-TLS) with Device certificate/key from Local Machine keystore for native VPN client.

Possible, but untested with this wiki setup. Please test and document.

Possible and tested, but not recommended without the outer TLS-protected PEAP or TTLS tunnel.

A CA certificated has to be installed prior for a VPN set up. Download you caCert.crt file to your phone (via email, net-drive, IM or something) and goto your phone's “settings” app. Search for “credential storage” / “install certificate” and select “CA certificate”. Choose the file (caCert.crt) you just downloaded to your phone and install it.

Starting with Android 11 a native IKEv2 implementation is available. For some reason, it didn't work until Android 12.

Android 12 IKEv2 works just fine but it doesn't allow using HMAC-SHA1 for the CHILD_SA. This wouldn't be an issue unless you explicitly excluded - for whatever reasons - greater integrity algorithms.

For authentication, Android 12 only supports “IKEv2/IPsec RSA” (which is pure “IKEv2 Certificate” PUBKEY authentication), “IKEv2/IPsec PSK” (which is not supported on this page because it's hard to keep secure), and “IKEv2/IPsec MSCHAPv2” (which is EAP-MSCHAPv2). It does not support EAP-TLS, nor any second authentication round.

You need to install the p12 private cert package from the import certificate wizard (Settings → Security → Cryptography and credentials → Install certificate > User certificate for apps and VPN. Give that credentials bundle a name you can easily distinguish from any other installed certs. You don't need to install the CA cert separately as it is included in the p12 bundle. After install, you can check into Settings → Security → Cryptography and credentials → User credentials → myvpnclient, you will see it includes an user certificate, an user private key and the CA certificate.

Then you can go into Settings → Network → VPN → + and choose:

1. Name: give a name to your VPN
2. Type: IKEv2/IPsec RSA
3. Server address: myvpnserver.dyndns.org
4. IPsec identifier: myvpnclient
5. IPsec user certificate: pick the one you previously imported, it contains both a private key and a user certificate with a matching public key
6. IPsec CA certificate: pick the one you previously imported, it also contains the CA certificate with the public key
7. IPsec server certificate: leave as default “(received from server)”

Possible, but untested with this wiki setup. Please test and document. Old revision of this wiki had a tested setup.

Possible, but not recommended as it is not manageable with decent security for roadwarriors scenario.

If you get a ciphersuite proposal error in your log (eg. “… unacceptable, requesting …”, “NO_PROPOSAL_CHOSEN”, “no acceptable proposal found”), you need to override the default ciphersuites proposal in your StrongSwan VPN Profile with something your router supports.

To do that, click Edit on the Profile, and scroll to the bottom to Advanced settings. At the bottom, you will find a section called Algorithms.

If the error relates to IKE_SA, edit IKEv2 Algorithms, downgrade to aes256-aes128-sha256-sha1-modp3072-modp2048 or whatever crypto algorithms your router and strongswan version supports for IKE.
If the error relates to CHILD_SA, edit IPsec/ESP Algorithms, downgrade to aes128-aes256-sha256-modp3072-modp2048,aes128-aes256-sha256 or aes128-aes256-sha256-sha1-modp3072-modp2048-modp1024,aes128-aes256-sha256-sha1 or whatever crypto algorithms your router supports for ESP.
Save, and then try to connect again. Please, avoid using weak or broken algorithms, and also avoid using too strong ESP algorithms your router doesn't handle with good performance.

In Android, go to “Settings > Security” to import certificates.

If you can see both client certificate and CA certificate in the Trusted Credentials - User, you can use “IKEv2 Certificate” or “IKEv2 Certificate + EAP”

In the Strongswan client, specify “IKEv2 Certificate” (“+ EAP” if you enabled second round auth) as the type of VPN, pick “myvpnclient” for the certificate you just imported, and eventually specify the username/password combo you added to /etc/ipsec.secrets (or the secrets section of /etc/swanctl/swanctl.conf if you are using swanctl config) for second round auth. Keep an eye on the log file (see above) during the initial login to spot any issues.

If you can only see CA certificate in Android certificate storage, strongswan client app would probably be unable to pick up your client certificate too. But you can still use IKEv2 + MSCHAPv2 aka “IKEv2 EAP (Username/Password)”, simply input username/password as you've set in ipsec.secrets (or the secrets section of /etc/swanctl/swanctl.conf if you are using swanctl config) and server hostname, then you should be up and running.

Beginning with iOS 9, IKEv2 connections are natively supported.

Versions of iOS prior to iOS 9 only support IKEv1. This setup is not recommended. For versions of iOS prior to iOS 9, or to enable a double authentication round you will need to use a third-party app. Cisco's Anyconnect may work but has not been tested.

If you encounter the “no matching peer config found” error (in the strongswan machine's log), please check “Local ID” on the iOS client side is matcheing one of the SANs of the client certificate (e.g. the SHAREDSAN).

You must install the CA certificate (caCert.crt) and the personal certificate (client.p12) onto the device, such as by accessing through iCloud drive or an email attachment. You do not need to set the CA certificate to be trusted for websites. You'll need to do it one at a time. And make sure they are marked green as “Verified”. Install the CA certificate again if one is still “unverified” although you've done both.

It follows some sample iOS configurations, from Settings→VPN→Add Configuration.

Type: IKEv2
Description: <your choice>
Server: <domain name of VPN server: myvpnserver.dyndns.org>
Remote ID: <same as Server>
Local ID: <SHAREDSAN as in client certificate SAN as well as the remote_identifier in ipsec in IOS-related connection settings: myVpnClients>
User Authentication: **None**
Use Cerificiate: enabled
Certificate: select the certificate imported from client.p12

Possible, but untested with this wiki setup. Please test and document. Old revision of this wiki had a tested setup.

Possible, but untested with this wiki setup. Please test and document. Old revision of this wiki had a tested setup.

BlackBerry allows you to specify Perfect Forward Secrecy. You will want/need this. This should be standard. If you have problems with preferred ciphersuites being too strong, try relaxing them in ipsec file this way:

config 'crypto_proposal' 'esp_proposal'
    option 'encryption_algorithm' 'aes256'
    option 'hash_algorithm' 'sha256'
    option 'dh_group' 'modp1024'

What this does is specify what cipher suites is preferred, including the unsecure MODP1024 for Diffie-Hellman Group which is no more part of default strongswan acceptable proposals. Avoid using the above weak and broken ciphersuite preference whenever possible. You can read about these settings in the strongswan IKEv2 cipher suite documentation.

Import your certificates into the Berry first, then add a VPN profile with the following settings:

• Your gateway type will be “Generic IKEv2 VPN Server”,
• Authentication Type = PKI,
• Authentication ID Type= Identity Certificate Distinguished Name
• Client Certificate = The name of your client cert (“myvpnclient” in the above example)
• Gateway Auth Type = PKI
• Gateway Auth ID Type = Identify Certificate Distinguished Name
• Gateway CA Certificate = your server Certificate name (“xxxx” in the above example)
• Perfect Forward Secrecy = On (VERY IMPORTANT)
• Automatically determine IP = ON
• Automatically determine DNS = ON
• Automatically determine algorithm = ON

The rest can be left to defaults.

If you receive an Authentication Error you can try to use distinguished name (DN) of your server's certificate instead of the FQDN for the local_identifier property. It is C=US, O=yyy, CN=myvpnserver.dyndns.org in the example above, but you can find out yours using the command below and looking for the Subject field

openssl x509 -in /etc/ipsec.d/certs/serverCert.pem -text -noout