[strongSwan] Windows 7 seems to drop connection when rekeying main mode SA's
Hans-Kristian Bakke
hkbakke at gmail.com
Thu Jan 12 19:38:13 CET 2012
I have found the problem. It is now working like it should work
without any interrupts caused by rekeying.
This configuration does not work:
config setup
charonstart=yes
plutostart=no
conn %default
keyexchange=ikev2
auth=esp
authby=pubkey
mobike=yes
left=%defaultroute
leftauth=pubkey
leftcert=vpn-serverCert.pem
leftfirewall=no
rightauth=pubkey
type=tunnel
dpdaction=clear
dpddelay=300s
reauth=no
conn rw-win-7
leftsubnet=0.0.0.0/0
right=%any
rightsourceip=10.0.1.0/24
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Roadwarriors, CN=*"
auto=add
ike=aes256-sha384-modp1024!
esp=aes256-sha1!
conn rw-uranus
leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
right=%any
rightsourceip=10.0.1.2
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Backup server,
CN=uranus.marsboer.net"
auto=add
ike=aes256-aesxcbc-ecp521!
esp=aes256gcm16!
conn rw-europa
leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
right=%any
rightsourceip=10.0.1.4
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=VPN fileserver,
CN=europa.marsboer.net"
auto=add
ike=aes256-aesxcbc-ecp521!
esp=aes256gcm16!
while this one does:
config setup
charonstart=yes
plutostart=no
conn %default
keyexchange=ikev2
auth=esp
authby=pubkey
mobike=yes
left=%defaultroute
leftauth=pubkey
leftcert=vpn-serverCert.pem
leftfirewall=no
rightauth=pubkey
type=tunnel
dpdaction=clear
dpddelay=300s
reauth=no
ike=aes256-sha384-modp1024,aes256-aesxcbc-ecp521!
esp=aes256-sha1,aes256gcm16!
conn rw-win-7
leftsubnet=0.0.0.0/0
right=%any
rightsourceip=10.0.1.0/24
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Roadwarriors, CN=*"
auto=add
conn rw-uranus
leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
right=%any
rightsourceip=10.0.1.2
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=Backup server, CN=uranus.m
auto=add
conn rw-europa
leftsubnet=10.10.10.0/24,10.0.1.0/24,10.10.99.0/24,10.0.2.0/24
right=%any
rightsourceip=10.0.1.4
rightid="C=NO, ST=Oppland, O=marsboer.net, OU=VPN fileserver, CN=europa.
auto=add
The only change is that instead of having the ike and esp parameters
defined individually by connection, I use the same proposals for all
connections, making sure the Windows 7 friendly one are first
(modp1024 has to be proposed first).
Now, what is the difference you could ask? Normally both of these
configuration should give a working result. If I only had one win-7
connection like mine it would also work.
The problem was caused by what seems to be a limitation in StrongSwans
handling of ike and esp algorithm handling on multiple connections
with identical left...right candidates. In my case %defaultroute and
%any.
Because only the left and right values are used in the IKE proposal
phase all my connections look identical to Strongswan. It is therefore
no guarantee that it selects the correct ike and esp parameters that
Windows 7 needs to work correctly. It could just as well use the
parameters from one of the other two.
By including all my needed ike and esp parameters in the correct order
in the %default connection, and hence in all connections, I ensure
that a valid proposal is used even though it selects the wrong
connection candidate.
This doesn't really fix the problem, but it is a functioning workaround.
I don't know if this is only a programatically limitation in the
candidate selection of strongswan or if it's a limitation of the ipsec
standard in general, but it is really confusing since two seemingly
fully valid, and for the purpose functionally identical
configurations, gives respectively a working and a non-working setup.
I am probably not the only one that have identical left and right
parameters in multiple connections using different ike and esp
parameters, so this may be something to look into at some point in the
future or at least document in some way on your excellent
documentation wiki.
Otherwise, thank you for a excellent product, currently leading the
way in open source IPSec implementations IMHO.
Best regards,
Hans-Kristian Bakke
More information about the Users
mailing list