[strongSwan] ipsec.conf working vs swanctl.conf not working

[Marco Berizzi]

Hi Tobias,

> The other end sends that notify back because it couldn't authenticate
> the initiator, so check the log there.

Unfortunately I have no access to the other ipsec peer.
I have also tried with another customer and I'm getting
the same behavior.

Here are the two outputs:

(non working)
[IKE] initiating Main Mode IKE_SA cbt[494] to 31.169.105.210
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (180 bytes)

Why only 180 bytes?

[NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 bytes)
[ENC] parsed INFORMATIONAL_V1 request 0 [ N(NO_PROP) ]
[IKE] received NO_PROPOSAL_CHOSEN error notify


(working)
initiating Main Mode IKE_SA cbt[499] to 31.169.105.210
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (248 bytes)

this time strongswan send a 248 bytes ike packet?

received packet: from 31.169.105.210[500] to 205.223.229.254[500] (140 bytes)
parsed ID_PROT response 0 [ SA V V V ]
received unknown vendor ID: 4f:45:68:79:4c:64:41:43:65:63:66:61
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (244 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (228 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received unknown vendor ID: 49:4b:45:76:32
IKE_SA cbt[499] established between 205.223.229.254[205.223.229.254]...31.169.105.210[31.169.105.210]
scheduling reauthentication in 85571s
maximum IKE_SA lifetime 86111s
generating QUICK_MODE request 4227161388 [ HASH SA No ID ID ]
sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (204 bytes)
received packet: from 31.169.105.210[500] to 205.223.229.254[500] (156 bytes)
parsed QUICK_MODE response 4227161388 [ HASH SA No ID ID ]
CHILD_SA cbt{788} established with SPIs c2384552_i b807ce0a_o and TS 10.28.131.200/29 === 192.168.170.128/28
generating QUICK_MODE request 4227161388 [ HASH ]
connection 'cbt' established successfully

These are the two config. I'm not able to catch the
configuration bug:

connections {

   cbt {
      local_addrs  = 205.223.229.254
      remote_addrs = 31.169.105.210

      local {
         auth = psk
         id = 205.223.229.254
      }
      remote {
         auth = psk
         id = 31.169.105.210
      }
      children {
         cbt-networks {
            local_ts  = 10.28.131.200/29
            remote_ts = 192.168.170.128/28

            start_action = trap
            esp_proposals = 3des-sha1
            rekey_time = 3600
            # rekey_bytes = 4608000000
         }
      }
      version = 1
      # mobike = no
      proposals = 3des-sha1-modp1024
      reauth_time = 24h
      keyingtries = 0
      send_cert = never
      send_certreq = no
      # encap = yes
      # unique = never
   }
}

secrets {

   ike-cbt {
      id = 31.169.105.210
      secret = 0sblabla
   }
}


conn cbt
        left=205.223.229.254
        right=31.169.105.210
        leftsubnet=10.28.131.200/29
        rightsubnet=192.168.170.128/28
        authby=secret
        auto=route
        esp=3des-sha1
        compress=no
        leftid=205.223.229.254
        rightid=31.169.105.210
        keyingtries=%forever
        lifetime=1h
        ikelifetime=86400
        ike=3des-sha1-modp1024