Hello Simon, I'm not really sure should I post it here, report a new bug, or report a bug to strongswan project directly. I can reproduce this buffer overflow with 100% probability. It is a resource independent and strongswan fail as on t1.micro or at any instance with more resources. Buffer overflow depends on a connections number (few hundreds - from 150 up to almost 400 - it depends on time between connections ). Some other resources usage: * CPU load less than 50% on t1.micro and less than 10% on t1.lagre - https://www.dropbox.com/s/kqox2t2u86ws49c/Screenshot%202016-02-27%2018.51.01.png?dl=0 (green) * a lot of free memory - https://www.dropbox.com/s/vzah4itqmrioksn/Screenshot%202016-02-27%2018.50.45.png?dl=0 * about 1100 sockets are used - https://www.dropbox.com/s/vkqf4ziuz19m20f/Screenshot%202016-02-27%2018.50.18.png?dl=0 * write peak 90kB/sec (/var/log) - https://www.dropbox.com/s/6kyt81lh4wnmh5h/Screenshot%202016-02-27%2018.50.30.png?dl=0 ipsec statusall before fail: xd@test-vpn-01:~$ sudo ipsec statusall | head -4 Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64): uptime: 83 seconds, since Feb 27 18:02:36 2016 malloc: sbrk 4870144, mmap 0, used 4382032, free 488112 worker threads: 507 of 512 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 876 xd@test-vpn-01:~$ sudo ipsec statusall | head -4 Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64): uptime: 85 seconds, since Feb 27 18:02:36 2016 malloc: sbrk 4927488, mmap 0, used 4428240, free 499248 worker threads: 507 of 512 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 889 xd@test-vpn-01:~$ sudo ipsec statusall | head -4 Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64): uptime: 86 seconds, since Feb 27 18:02:36 2016 malloc: sbrk 4980736, mmap 0, used 4488352, free 492384 worker threads: 506 of 512 idle, 5/0/1/0 working, job queue: 0/0/0/0, scheduled: 897 xd@test-vpn-01:~$ sudo ipsec statusall | head -4 xd@test-vpn-01:~$ sudo ipsec statusall | head -4 # cat log.txt | grep -B 20 -A 20 'overflow' 216[CFG] received RADIUS Access-Accept from server '127.0.0.1' 216[CFG] scheduling RADIUS Interim-Updates every 15s 216[IKE] RADIUS authentication of 'loadtest-197' successful 216[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established 216[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ] 216[NET] sending packet: from 172.31.59.95[500] to 172.31.62.150[500] (76 bytes) 217[NET] received packet: from 172.31.62.150[500] to 172.31.59.95[500] (92 bytes) 217[ENC] parsed IKE_AUTH request 5 [ AUTH ] 217[IKE] authentication of 'loadtest-197' with EAP successful 217[IKE] authentication of 'CN=srv, OU=load-test, O=strongSwan' (myself) with EAP 217[IKE] IKE_SA ikev2-with-eap-loadtest[248] established between 172.31.59.95[CN=srv, OU=load-test, O=strongSwan]...172.31.62.150[loadtest-197] 217[IKE] scheduling reauthentication in 3403s 217[IKE] maximum IKE_SA lifetime 3583s 217[IKE] peer requested virtual IP %any 217[CFG] assigning new lease to 'loadtest-197' 217[IKE] assigning virtual IP 10.0.0.231 to peer 'loadtest-197' 217[IKE] CHILD_SA ikev2-with-eap-loadtest{231} established with SPIs c8213004_i cd74929b_o and TS 172.31.59.95/32 === 10.0.0.231/32 217[CFG] sending RADIUS Accounting-Request to server '127.0.0.1' 217[CFG] received RADIUS Accounting-Response from server '127.0.0.1' 217[ENC] generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) ] 217[NET] sending packet: from 172.31.59.95[500] to 1*** buffer overflow detected ***: /usr/lib/ipsec/charon terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f81b0aa038f] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f81b0b37c9c] /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f81b0b36b60] /lib/x86_64-linux-gnu/libc.so.6(+0x10abe7)[0x7f81b0b37be7] /usr/lib/ipsec/libradius.so.0(+0x2fcf)[0x7f81ab867fcf] /usr/lib/ipsec/libradius.so.0(+0x3660)[0x7f81ab868660] /usr/lib/ipsec/plugins/libstrongswan-eap-radius.so(+0x4af1)[0x7f81aba70af1] /usr/lib/ipsec/plugins/libstrongswan-eap-radius.so(+0x4dc5)[0x7f81aba70dc5] /usr/lib/ipsec/libstrongswan.so.0(+0x2858e)[0x7f81b14b258e] /usr/lib/ipsec/libstrongswan.so.0(+0x28df2)[0x7f81b14b2df2] /usr/lib/ipsec/libstrongswan.so.0(+0x2bc14)[0x7f81b14b5c14] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f81b0dfa182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f81b0b2747d] ======= Memory map: ======== 7f8064000000-7f8064050000 rw-p 00000000 00:00 0 7f8064050000-7f8068000000 ---p 00000000 00:00 0 7f806c000000-7f806c042000 rw-p 00000000 00:00 0 7f806c042000-7f8070000000 ---p 00000000 00:00 0 7f8070000000-7f8070038000 rw-p 00000000 00:00 0 After full update the bug still exist: # lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04 # ipsec --version Linux strongSwan U5.1.2/K3.13.0-79-generic Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil, Switzerland See 'ipsec --copyright' for copyright information. # apt-cache policy libc-bin libc-bin: Installed: 2.19-0ubuntu6.7 Candidate: 2.19-0ubuntu6.7 Version table: *** 2.19-0ubuntu6.7 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 2.19-0ubuntu6 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages # apt-cache policy strongswan strongswan: Installed: 5.1.2-0ubuntu2.4 Candidate: 5.1.2-0ubuntu2.4 Version table: *** 5.1.2-0ubuntu2.4 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 5.1.2-0ubuntu2 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages # uname -a Linux test-vpn-01 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Best regards, Ruslan.