[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