[strongSwan] Continuous loss/retransmission using IPv6 in IPv4 tunnel.
Adam Bishop
Adam.Bishop at jisc.ac.uk
Mon Oct 23 21:24:46 CEST 2017
I have a road warrior deployment, which works perfectly for IPv4 on all (Windows, Linux, OS X) clients. The tunnel is dual stacked, and hands out a private, nat'd v4 address and a public v6 address.
IPv6 traffic though experiences massive loss coming from somewhere. I've tested with iperf in the clear, reaching ~750mbit between a client and the strongSwan server with negligible loss, so I'm reasonably confident it's not the network at fault.
Dumping traffic from the strongSwan side shows TCP retransmits accounting for ~75% of the traffic. I can share this packet capture off-list if desired. I've restricted the MSS to 1300 bytes, so the loss shouldn't be down to MTU.
I'm not really sure how to diagnose this further - I don't think it's a client issue because it occurs on clients of more than one platform OS X (Native) and Linux (strongSwan).
swanctl.conf follows at the end of this message. The system is running CentOS 7, with strongSwan 5.6.1 built directly from Git yesterday morning (5.3.3 also affected).
Regards,
Adam Bishop
gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460
jisc.ac.uk
pools {
dns_pool4 {
addrs = 10.0.0.0/24
dns = <v4dnsaddr1,v4dnsaddr2>
}
dns_pool6 {
addrs = 2001::/112
dns = <v6dnsaddr1,v6dnsaddr2>
}
}
connections {
TENANT-DNS {
version = 2
local_addrs = publicv4,publicv6
remote_addrs = %any # default
local_port = 500 # default
remote_port = 500 # default
proposals = aes128-sha256-modp1024-prfsha256,aes256-sha256-modp1024-prfsha256,aes128-sha256-modp2048-prfsha256,aes256-sha256-modp2048-prfsha256,aes128-sha256-modp3072-prfsha256,aes256-sha256-modp3072-prfsha256,aes128-sha256-modp4096-prfsha256,aes256-sha256-modp40$
pull = yes # default
encap = no # default
mobike = yes # default
dpd_delay = 10s
fragmentation = yes # default
send_certreq = no
send_cert = always # default
keyingtries = 3
unique = no # default
reauth_time = 0s # default
rekey_time = 1h
# Corresponds to a unique pool entry after connections {}
pools = dns_pool4,dns_pool6
local {
cacerts = ca.pem
certs = server.pem
auth = pubkey
id = my.ike.id
}
remote {
id = %any
# Causes segfault on 5.3.3, do not enable until debugged
#cert_policy = 1.3.6.1.5.5.7.3.2
auth = eap-radius
}
children {
child {
esp_proposals = aes128-sha256-modp1024,aes256-sha256-modp1024,aes128-sha256-modp2048,aes256-sha256-modp2048,aes128-sha256-modp3072,aes256-sha256-modp3072,aes128-sha256-modp4096,aes256-sha256-modp4096,aes128-sha256-modp6144,aes256-sha256-modp6144,aes128-sh$
# Update these with the desired split subnets
local_ts = <~8 IPv4 and ~5 IPv6 subnets go here>
remote_ts = dynamic
rekey_time = 1h # default
# Trigger a rekey after 1GiB of data has been encrypted
rekey_bytes = 1073741824
# updown =
mode = tunnel
interface = ens192
replay_window = 32
}
}
}
}
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
More information about the Users
mailing list