lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Sun, 6 Dec 2015 11:05:01 +0100
From:	"Gabriele Beltrame" <>
To:	<>
Subject: Random packet loss using IPsec with AES128-SHA1


I'm running a few Strongswan 5.3.* CentOS (Kernel 3.16.7, 4.2.6, 4.1.*)
instances on AWS to terminate VPNs between each other and/or to other
devices across the Internet.
While investigating some application issues, I've noticed that on every VPNs
I have random packet losses (from 1% to 4% over 100 to 300 requests sent).
This only happens when the two following conditions are met: (a) AES
encryption used, (b) IP packet size shorter than about (150+8+20)Bytes.

In tcpdump I can actually see all packets (requests and replies) being
"sent" from the router, but on destination server (on the same "LAN") they
are not being received... it's just like if the packet is being lost before
it's being actually serialized onto the network by the XEN NIC driver
Pinging form the vpn router itself always works fine though, never losing a
single packet...

Tested with Kernel 3.16.7, 4.2.6 and a AWS Amazon Linux instance (kernel
Strongswan and libreswan shows the same issue, so it's not a Strongswan
Only AES CBS is affected... AES GCM is not affected, furthermore if I use
the Strongswan's kernel-libipsec plugin there is no packet loss.

To recap:
	a. it's not an instance type/size issue (I have the same issue on
everything I've tested with)
	b. it's not a Strongswan issue (I have the same
	c. it's not a network/related issue (I can actually see on the
router all packets with tcpdump, they are just not received at the
destination (a host on the same network as the "vpn router")
	d. I only see this occurring with AES128 CBS DH2 (and possibly other
key sizes as well)... AES GCM is not affected, as well as 3DES and NULL
	e. Strongswan developers cannot reproduce the issue on their lab
(Strongswan issue #1220), so possibly there could be something wrong within
the Xen NIC driver
	f. ICMP packets bigger than around 178bytes (150+8+20) seem to not
be affected

Has somebody an idea about where the issue might be and how to
fix/workaround it (I cannot use 3DES and/or AES GCM everywhere and the
Strongswan's kernel-libipsec plugin taxes the CPU a lot more than the kernel


This email has been checked for viruses by Avast antivirus software.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists