1

I'm trying to set an ipsec VPN between two peers hosted in AWS but I'm not able to make it work, my environment is the following:

One peer has 10.10.1.100 as private IP and 8.a.b.c as public one, the remote client is reachable from IP 9.d.e.c, I've been told to follow this parameters in the configuration:

Phase 1 settings:

• IKE version: IKEv2

• IKE Authentication Method: Pre-shared Key

• IKE Encryption Algorithm: AES256

• IKE Authentication algorithm: HMAC_SHA256

• IKE Diffie-Hellman Group: Group 2 - 1024-bit

• IKE Phase 1 lifetime: 86400s

• IKE Exchange Mode: Main

Phase 2 settings:

• Encryption algorithm: AES256

• Authentication algorithm: HMAC_SHA256

• Diffie-Hellman Group: Group 2 - 1024-bit

• Phase 2 lifetime: 3600s

So in one of the peers I've set this up in ipsec.conf file

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        charondebug="ike 4, knl 2, cfg 2, net 4, lib 2, chd 4, mgr 4, enc 4"
        # strictcrlpolicy=yes
        # uniqueids = no

# Add connections here.

# Sample VPN connections

conn cet
        authby=secret
        keyexchange=ikev2
        esp=aes256-sha256-modp1024
        ikelifetime=86400s
        ike=aes256-sha256-modp1024
        keylife=3600s
        leftsubnet=10.10.1.0/24
        left=10.10.1.100
        right=9.d.e.c
        rightsubnet=192.168.1.0/24
        mobike=no
        auto=start

And the /etc/ipsec.secrets file looks like this:

#ipsec.secrets - strongSwan IPsec secrets file
54.169.72.161 : PSK "oddRandomCharacters"

But when I attempt to establish the VPN connection this is the output I'm getting:

initiating IKE_SA cet[68] to 9.d.e.f
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 10.10.1.100[500] to 9.d.e.f[500] (900 bytes)
received packet: from 9.d.e.f[500] to 10.10.1.100[500] (336 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
local host is behind NAT, sending keep alives
remote host is behind NAT
authentication of '10.10.1.100' (myself) with pre-shared key
establishing CHILD_SA cet
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 10.10.1.100[4500] to 9.d.e.f[4500] (384 bytes)
received packet: from 9.d.e.f[4500] to 10.10.1.100[4500] (80 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'cet' failed

I'm guessing that I'm missing the phase 2 parameters because, as far as I'm concerned, the phase 1 negotiation is good but when the tunnel attempts to establish it fails. The private key is correct and the configuration parameters are the ones shared before so that shouldn't be the issue, unfortunately I don't have access to the remote peer logs so the /var/log/syslog is all I have:

Aug 27 02:03:11 ap-southeast-2-gw charon: 10[IKE] successfully created shared key MAC
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[IKE] establishing CHILD_SA cet
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[CFG] proposing traffic selectors for us:
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[CFG]  10.10.1.0/24
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[CFG] proposing traffic selectors for other:
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[CFG]  192.168.1.0/24
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[KNL] got SPI cd02b0dc
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
Aug 27 02:03:11 ap-southeast-2-gw charon: 10[NET] sending packet: from 10.10.1.100[4500] to 54.169.72.161[4500] (384 bytes)
Aug 27 02:03:11 ap-southeast-2-gw charon: 05[NET] sending packet: from 10.10.1.100[4500] to 54.169.72.161[4500]
Aug 27 02:03:12 ap-southeast-2-gw charon: 03[NET] received packet: from 54.169.72.161[4500] to 10.10.1.100[4500]
Aug 27 02:03:12 ap-southeast-2-gw charon: 03[NET] waiting for data on sockets
Aug 27 02:03:12 ap-southeast-2-gw charon: 15[NET] received packet: from 54.169.72.161[4500] to 10.10.1.100[4500] (80 bytes)
Aug 27 02:03:12 ap-southeast-2-gw charon: 15[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Aug 27 02:03:12 ap-southeast-2-gw charon: 15[IKE] received AUTHENTICATION_FAILED notify error

Am I missing something?

  • Note that you have compromised your secret, if this is the real contents of your secrets file. You will need to have this changed on the other end. – Michael - sqlbot Aug 27 '17 at 12:45
  • Thanks but is not the real secret, I've changed randomly most of the characters. – nikolaigauss Aug 27 '17 at 13:25
  • That's good to know. – Michael - sqlbot Aug 27 '17 at 13:34
2

AFAIK Ikev2 doesn't support secret as auth method..

Edit: This might not be true in a site-to-site setting. I've only used Strongswan for a roadwarrior setup with Windows 10 clients, and secret or PSK does not work in Windows for Ikev2.

You either need to do mutual EAP method like EAP-TLS on both sides, or EAP on the request side and public key on the server side.

Edit: Could you share the config from the other end?

  • That's odd but it may be a possibility, is secret the same as psk? – nikolaigauss Aug 27 '17 at 13:27
  • 1
    I did a little research and I got this: tools.ietf.org/html/rfc4739 "The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods." So I guess it should work with shared secret. – nikolaigauss Aug 27 '17 at 19:42
  • Unfortunately I can't provide that info because I don't have access to it, this was an exercise from university in which we had to assume that the configuration was ok in the remote end, the only thing we had was the public IP, the subnet behind the remote end and the settings we should use to rise the tunnel. BTW all the infrastructure is mounted on AWS, may be that should help. – nikolaigauss Aug 27 '17 at 21:58
  • Have you tried adding both sides IP addresses to the PSK in ipsec.secret? (Or just remove the address). – Ost99 Aug 27 '17 at 23:13
  • Yes, this is what my /etc/ipsec.secrets file looks like: # ipsec.secrets - strongSwan IPsec secrets file #myIP : PSK "oddRandomCharacters" #myIP peerIP : PSK "oddRandomCharacters" #peerIP myIP0 : PSK "oddRandomCharacters" #%any %any : PSK "oddRandomCharacters" peerIP : PSK "oddRandomCharacters" I've tried all combinations and still no luck. – nikolaigauss Aug 27 '17 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.