0

I successfully created a site to site VPN connection (named SAVE) with StrongSwan and it appears working fine.

What bothers me is that the output of ipsec statusall in the Security Association section keeps displaying a CONNECTING entry and I don' tknow how to interpret that part.

See below for the ipsec statusall output and setup. From LOG i just see a flow of INFORMATIONAL requests and response (ENC group).

Is this normal or how should I interpret this?

Thank you!

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-184-generic, x86_64):
  uptime: 3 minutes, since Jul 29 12:20:13 2020
  malloc: sbrk 2568192, mmap 0, used 378432, free 2189760
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown
Listening IP addresses:
  xx.xx.xx.xx
Connections:
        SAVE:  xx.xx.xx.xx...yy.yy.yy.yy  IKEv2
        SAVE:   local:  [xx.xx.xx.xx] uses pre-shared key authentication
        SAVE:   remote: [yy.yy.yy.yy] uses pre-shared key authentication
        SAVE:   child:  zz.zz.zz.0/24 === ww.ww.ww.ww/32 TUNNEL
Security Associations (1 up, 1 connecting):
        SAVE[2]: ESTABLISHED 2 minutes ago, xx.xx.xx.xx[xx.xx.xx.xx]...yy.yy.yy.yy[yy.yy.yy.yy]
        SAVE[2]: IKEv2 SPIs: 1e7b35d1f9f1ea9d_i b375373958803f58_r*, pre-shared key reauthentication in 7 hours
        SAVE[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        SAVE{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cf5c6f76_i 5b4506c5_o
        SAVE{2}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 3660 bytes_o (53 pkts, 27s ago), rekeying in 45 minutes
        SAVE{2}:   zz.zz.zz.zz/24 === ww.ww.ww.ww/32
        SAVE[1]: CONNECTING, xx.xx.xx.xx[xx.xx.xx.xx]...yy.yy.yy.yy[yy.yy.yy.yy]
        SAVE[1]: IKEv2 SPIs: 9d44621f40d456cd_i* c7f3bb5a8753ee09_r
        SAVE[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        SAVE[1]: Tasks active: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE 
        
        
        
        
conn SAVE
        compress=no
        type=tunnel
        keyingtries=10
        authby=secret
        ike=aes128-sha1-modp1024!
        keyexchange=ikev2
        esp=aes128-sha1
        auto=start
        leftid=xx.xx.xx.xx
        left=xx.xx.xx.xx
        leftsourceip=zz.zz.zz.1
        leftsubnet=zz.zz.zz.0/24
        leftfirewall=no
        rightid=yy.yy.yy.yy
        right=yy.yy.yy.yy
        rightsubnet=ww.ww.ww.ww/32
        keylife=3600s
        ikelifetime=28800s
Ascanio Orlandini
  • 33
  • 4
  • 1
    Looks like the connection initiated from your end is not established correctly (check the log for details, or post the complete log here). The established connection was initiated by the peer (you see the `*` behind your host's SPI), apparently both initiated the connection concurrently. Note that you don't want to configure _leftsourceip_ if you don't actually negotiate virtual IP addresses with the peer using config attributes. – ecdsa Jul 29 '20 at 12:14
  • ecdsa, removing leftsourceip fixed the problem! I thought to had to indicate the left source ip because there was no nogotiation expected. Thanks. – Ascanio Orlandini Jul 30 '20 at 10:19

0 Answers0