0

I'm configuring site-to-site ipsec tunnel, being given very few details about the remote host. On my server I'm using strongswan with the following ipsec.conf:

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ike
        authby=secret

conn testconn
        type=tunnel
        left=xx.xx.xx.xx
        leftsubnet=192.168.26.0/24
        leftfirewall=yes
        right=xx.xx.xx.xx
        rightsubnet=192.168.0.0/16
        auto=add
        #ike = 3des-sha1-modp1024!
        #esp = aes256-sha1,aes192-sha1,aes128-sha1!

Running ipsec statusall provides this output:

Connections:
    testconn:  xx.xx.xx.xx...xx.xx.xx.xx  IKEv1/2
    testconn:   local:  [xx.xx.xx.xx] uses pre-shared key authentication
    testconn:   remote: [xx.xx.xx.xx] uses pre-shared key authentication
    testconn:   child:  192.168.26.0/24 === 192.168.0.0/16 TUNNEL
Security Associations (1 up, 0 connecting):
    testconn[40]: ESTABLISHED 38 seconds ago, xx.xx.xx.xx[xx.xx.xx.xx]...xx.xx.xx.xx[xx.xx.xx.xx]
    testconn[40]: IKEv1 SPIs: dcefb2530519ff71_i cb8bca41ca831f41_r*, pre-shared key reauthentication in 53 minutes
    testconn[40]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024

Yet, hosts from my subnet are unable to reach hosts from the other one. In the syslog this comes up:

received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
charon: 16[CFG] configured proposals: ESP:AES_CBC_128/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
charon: 16[IKE] received 3600s lifetime, configured 1200s
charon: 16[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN

But I'm quite confused as I can't understand exactly what's wrong. Advices will be appreciated.

1 Answer 1

1

IKE (the control channel) and ESP (data channels) have independent cipher configurations. Your status output shows that the IKE connection itself is active, but the two sides cannot agree on the ESP parameters and no data channel is established.

In your case the remote peer wants to use PFS (Perfect Forward Secrecy) using 1536-bit Diffie-Hellman, but this isn't enabled in the default strongSwan proposal. (Even if DH were enabled by default, this is an uncommon size and slightly to the weak end... although the 1024-bit DH that your peer uses for IKE is even worse.) You want:

esp=aes256-sha1-modp1536

(strongSwan has references for IKEv1 and IKEv2.)

Additionally, IKEv1 requires both sides to agree on the "key lifetime" (rekey interval) – your system offers 30min but the remote peer wants 60min. Use lifetime=60m to fix this.

2
  • 1
    strongSwan actually just replies with whatever lifetime the client proposed and ignores it. So the configuration of it doesn't have to match. strongSwan always uses its own configuration to schedule rekeyings.
    – ecdsa
    Mar 14, 2019 at 17:09
  • Ah, so the message is just informational? I'm probably remembering having had troubles with some other IPsec implementation instead... Mar 14, 2019 at 17:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .