<div dir="ltr"><div>Hi Tobias,<br></div>      I tried doing a make uninstall and and did a apt-get remove strongswan on the system. Then I rebuild strongswan again, but I got the same result I did a packet capture and still the KE payload DH group is 0. This is what I see in the logs now. I am running strongswan on Kali 2.0<br><br><br><br><br>charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.0.0-kali1-amd64, x86_64)<br>charon: 00[CFG] loaded load-tester address pool <a href="http://2.2.2.20/24">2.2.2.20/24</a> on eth1<br>charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'<br>charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'<br>charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'<br>charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'<br>charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'<br>charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'<br>charon: 00[CFG] expanding file expression '/var/lib/strongswan/ipsec.secrets.inc' failed<br>charon: 00[LIB] loaded plugins: charon aes agent gcm openssl des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr load-tester kernel-netlink resolve socket-default stroke updown xauth-generic<br>charon: 00[JOB] spawning 16 worker threads<br>charon: 07[CFG] assigning new lease to 'ext-2'<br>charon: 07[CFG] installed load-tester IP 2.2.2.20 on eth1<br>charon: 07[IKE] initiating IKE_SA load-test[1] to 2.2.2.1<br>charon: 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]<br>charon: 07[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288 bytes)<br>charon: 11[CFG] assigning new lease to 'ext-3'<br>charon: 11[CFG] installed load-tester IP 2.2.2.21 on eth1<br>charon: 11[IKE] initiating IKE_SA load-test[2] to 2.2.2.1<br>charon: 11[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]<br>charon: 11[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288 bytes)<br>charon: 08[IKE] retransmit 1 of request with message ID 0<br>charon: 08[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288 bytes)<br>charon: 09[IKE] retransmit 1 of request with message ID 0<br>charon: 09[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288 bytes)<br>charon: 10[IKE] retransmit 2 of request with message ID 0<br>charon: 10[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288 bytes)<br>charon: 12[IKE] retransmit 2 of request with message ID 0<br>charon: 12[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288 bytes)<br>charon: 13[IKE] retransmit 3 of request with message ID 0<br> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 6:31 AM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michael,<br>
<br>
I think the reason why no DH group is set in the KE payload and you get<br>
a segmentation fault is that you are mixing an old crypto plugin with a<br>
newer build of the daemon/libraries.<br>
<br>
The 5.3.1 release added a new method to the diffie_hellman_t interface.<br>
 It was added at the position where the get_dh_group() getter was in<br>
previous releases:<br>
<br>
  get_my_public_value()<br>
 +set_private_value()<br>
  get_dh_group()<br>
  destroy()<br>
<br>
Which means that get_dh_group() is now at the position destroy() was<br>
previously.  So any code built against the current version of the<br>
diffie_hellman.h header file that calls get_dh_group() for a DH<br>
implementation provided by a plugin built against the previous header<br>
file will actually call destroy() instead.  Since there won't be a<br>
return value the DH group is basically undefined and at the same time<br>
the DH object is destroyed, causing a segmentation fault when the object<br>
is accessed later on (in your case when the DH object is accessed in<br>
ike_init_t.migrate()).<br>
<br>
When upgrading from sources it is recommended to call `make uninstall`<br>
in the _original_ build directory (i.e. where you called `make install`<br>
previously), which will remove binaries but leave configuration files<br>
alone.  So keep that build directory around.  If you don't want or can<br>
do that at least use the same ./configure options (the options used for<br>
a previous build can be seen at the top of the config.log file in the<br>
build directory).  Of course, you can also remove the binaries manually<br>
before running `make install` for the new build.  Their location depends<br>
on the configured --prefix and other options to specify installation<br>
paths.  By default plugins are installed in `/usr/local/lib/ipsec/plugins`.<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div><br></div>