How do I configure StrongSwan to act as a IKEv1 client?

Question

A customer of our development business has provided access to their IPSec VPN providing the necessary credentials (anonymized):

• Gateway: example.fake
• Group: MYGROUP
• User: MYUSER
• Password: MYPASSWORD
• PSK: MYPSK

They have also provided the parameters configured on their side:

Phase 1

• Authentication: SHA1
• Encryption: AES 256
• SA Life: 1 hour
• Key Group: Diffie Helman group 2
• NAT Traversal & DPD are enabled
• Keep-alive interval: 20 seconds

Phase 2

• Type: ESP
• Authentication: SHA1
• Encryption: AES 256
• Force key expiration: 1 hour

The connection type is IKEv1 and they have configured access through the VPN tunnel only on a specific IP 1.2.3.4 because that is the only machine we have to reach.

Goal and attempt

I am trying to figure out how to configure StrongSwan to connect to their VPN. I need this working on a VPS with Ubuntu Server 16.04.

I have tried to follow a bunch of guides but some were for older versions of StrongSwan so they didn't work. Finally I have edited /etc/ipsec.conf with the following attempted configuration:

config setup

conn myconn
    authby=xauthpsk
    dpdaction=restart
    esp=aes256-sha1
    ike=aes256-sha1-dh2
    ikelifetime=1h
    keyexchange=ikev1
    leftauth=psk
    leftauth2=xauth
    leftgroups=MYGROUP
    leftid=@MYUSER
    right=example.fake
    rightsubnet=1.2.3.4/32

I have created /etc/ipsec.secrets:

: PSK "MYPSK"
MYUSER: XAUTH "MYPASSWORD"

Desired end state and error message

The desired end state is that our machine connects to the customer's VPN and we can reach that single IP 1.2.3.4. The rest of the traffic should be split and not go through the VPN.

Despite the fact that myconn is defined in /etc/ipsec.conf, this error message comes up when trying to connect:

# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.3.5 IPsec [starter]...
# ipsec up myconn
no config named 'myconn'

Log files

These lines are added to /var/log/syslog after running ipsec restart:

Jun  5 16:45:01 server charon: 00[DMN] signal of type SIGINT received. Shutting down
Jun  5 16:45:03 server charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.8.0-53-generic, x86_64)
Jun  5 16:45:03 server charon: 00[CFG] disabling load-tester plugin, not configured
Jun  5 16:45:03 server charon: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
Jun  5 16:45:03 server charon: 00[CFG] dnscert plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] ipseckey plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] attr-sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun  5 16:45:03 server charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jun  5 16:45:03 server charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jun  5 16:45:03 server charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jun  5 16:45:03 server charon: 00[CFG]   loaded RSA private key from '/etc/ipsec.d/private/myKey.der'
Jun  5 16:45:03 server charon: 00[CFG] sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] opening triplet file /etc/ipsec.d/triplets.dat failed: No such file or directory
Jun  5 16:45:03 server charon: 00[CFG] eap-simaka-sql database URI missing
Jun  5 16:45:03 server charon: 00[CFG] loaded 0 RADIUS server configurations
Jun  5 16:45:03 server charon: 00[CFG] no threshold configured for systime-fix, disabled
Jun  5 16:45:03 server charon: 00[CFG] coupling file path unspecified
Jun  5 16:45:03 server charon: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity
Jun  5 16:45:03 server charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jun  5 16:45:03 server charon: 00[JOB] spawning 16 worker threads

These are added after running ipsec up myconn:

Jun  5 16:45:21 server charon: 15[CFG] received stroke: initiate 'myconn'
Jun  5 16:45:21 server charon: 15[CFG] no config named 'myconn'

They look consistent with the aforementioned error message.

Question

Why does ipsec up myconn say that there is no such configuration? It is my first time trying to deal with an IPSec VPN... does the configuration I tried to write make any sense?

What do I have to change to get it working?

Update after adding auto=add

As suggested in the comments I have added auto=add to my configuration. I now get this:

# ipsec up myconn
initiating Main Mode IKE_SA myconn[1] to <IP of example.fake>
configuration uses unsupported authentication
tried to check-in and delete nonexisting IKE_SA
establishing connection 'myconn' failed

These lines are appended to the log file:

Jun  5 17:07:19 server charon: 12[CFG] received stroke: initiate 'myconn'
Jun  5 17:07:19 server charon: 14[IKE] initiating Main Mode IKE_SA myconn[2] to <IP of example.fake>
Jun  5 17:07:19 server charon: 14[CFG] configuration uses unsupported authentication
Jun  5 17:07:19 server charon: 14[MGR] tried to check-in and delete nonexisting IKE_SA

Update after removing esp=, ike= and keyexchange=

After removing the three lines mentioned above the connection attempt goes like this, for three times (the snippet shows only the first one, the other are identical):

Jun  5 17:18:44 server charon: 06[CFG] received stroke: initiate 'myconn'
Jun  5 17:18:45 server charon: 04[IKE] initiating IKE_SA myconn[1] to <IP of example.fake>
Jun  5 17:18:45 server charon: 04[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Jun  5 17:18:45 server charon: 04[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:49 server charon: 03[IKE] retransmit 1 of request with message ID 0
Jun  5 17:18:49 server charon: 03[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:56 server charon: 15[IKE] retransmit 2 of request with message ID 0
Jun  5 17:18:56 server charon: 15[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:09 server charon: 01[IKE] retransmit 3 of request with message ID 0
Jun  5 17:19:09 server charon: 01[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:32 server charon: 16[IKE] retransmit 4 of request with message ID 0
Jun  5 17:19:32 server charon: 16[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:20:14 server charon: 05[IKE] retransmit 5 of request with message ID 0
Jun  5 17:20:14 server charon: 05[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:21:30 server charon: 13[IKE] giving up after 5 retransmits
Jun  5 17:21:30 server charon: 13[IKE] peer not responding, trying again (2/3)

Update: Working config for ShrewSoft VPN

The connection to the customer's VPN has been tested on a desktop machine at the office, using ShrewSoft VPN, however this is not suitable for using it on the development VPS. Said program exported the following configuration:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
b:auth-mutual-psk:****REMOVED****
n:phase1-dhgroup:2
n:phase1-keylen:0
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:0
n:phase2-pfsgroup:-1
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:1
s:network-host:example.fake
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk-xauth
s:ident-client-type:keyid
s:ident-client-data:MYGROUP
s:ident-server-type:any
s:phase1-exchange:aggressive
s:phase1-cipher:auto
s:phase1-hash:auto
s:phase2-transform:auto
s:phase2-hmac:auto
s:ipcomp-transform:disabled
s:policy-level:auto

Does this suggest any changes that should be done to the ipsec.conf file to get this working with StrongSwan?

Answer 1

Perhaps this is a late response, but here are some pointers on issues I've caught looking (but not tried/tested):

• authby is deprecated, and you're using leftauth. Explicitly setting both leftauth/rightauth and leftauth2/rightauth2 would help. In my experiences (and looking at the C code on github) for IKEv1, there are only a limited number if/else check, and when left and right does not match (other than any), you'll get 'unsupported authentication' message
• Oddly (and I've not looked at the C code to verify this) there are claims that you must have a on each sides of the ':' in your secrets files (i.e. 'MYUSERS : XAUTH "MYPASSWORD"', on yours, you did not have a space in MYUSER:)
• Depending on your distros, some encryption methods may not be supported (i.e. 3DES) - watch the charon log for plugins to see what is loaded.
• Whomever said to remove 'keyexchange' missed out your question that you'd want IKEv1. For IKEv1, you have to explicitly set keyexchange=ikev1 ; default is 'ike' which is both IKEv1 and IKEv2 on server side, not client side (meaning, as a VPN server, I will accept both v1 and v2 of my clients). In your case, your roll is a client, so you'd have to be explicit.
• I do not agree about removal of esp= and ike= since you've prestated on your OP explicitly what your Phase1 (is it dh2 or aes256-sha1-modp2048?) and Phase2 are; If you can get a hold of 'ike-scan' tool for your distro, use that instead. It'll even give you any hints about whether your endpoint supports IKEv2. Usually, what I discover from 'ike-scan' is whether the endpoint supports 3DES or not, since on some distro, they no longer distribute with 3DES as part of the binary.
• I've noticed that for your Shrewsoft config, you've set agressive=yes, which you might also want to try on ipsec.conf once you get phase2 working.
• Assuming your 'left' is the client side, and 'right' is the remote gateway, you have set 'leftid' instead of 'rightid' - basically, rightid must match your .secrets file, unless you're intentionally wanting the gateway to authenticate to you?

Some other tips:

• Set your charon log on 'NET' and 'CFG' (pick and choose) to be of higher log level depending on what you're debugging (with log level set high enough, you should not even need tcpdump)
• As mentioned above, it's quite critical that both left and right auth/auth2 matches (even if your left is client side) to make sure you don't get 'configuration sues unsupported...' errors (setting your 'cfg' in charon log won't help here, I had to look at the C code)
• As somebody have mentioned, make sure to at least have 'auto=add' - a giveaway is when you do '$ipsec statusall' you won't see your 'conn' if it wasn't added

In any case, some missing information which had to be deduced indirectly based on configs and other logs which you may have wished to provide earlier to avoid back-and-forth on comments:

• Phase 1: PSK (preshared)
• Phase 2: xauth-radius

I'm not too sure what your remote VPN server is using, but above is with an assumption that it's radius-based, make sure to correctly set your xauth-plugins based on it.

Lastly, follow the Strongswan's 'ipsec.conf' documentation throughly on what are supported on IKEv1. Also, if your endpoint is NTLM based, remember that NTLM passwords are MD4 encoded (just search for something in sense of piping UTF16 string into openssl as MD4).